4 ms·

Personally, I haven't heard anything about renewed debates related to Spring vs. JEE in many years. And if you read the Gartner report in question[1], it's not

by dlandis 10y ago

Personally, I haven't heard anything about renewed debates related to Spring vs. JEE in many years. And if you read the Gartner report in question[1], it's not about that at all. Hmm. Maybe I'm just cynical, but when I saw he was part of the company behind Spring I thought maybe this was more of a contrived argument. The truth is, framing a debate as Spring vs JEE perhaps stands to benefit both technologies since in many people's minds they are both complex and bloated. It's just about positioning; yes, Spring is "lightweight" compared to traditional JEE, but so is everything! 1. https://www.gartner.com/doc/reprints?id=1-3N8E378&ct=161205&st=sb https://www.gartner.com/doc/reprints?id=1-3N8E378&ct=161205&...

jacques_chester 10y ago
I don't think Phil wants to get sucked into the argument at all. He just wants to write cool software. I'm just going to leave this one at the doors of the bosses, both at vendors (like Pivotal) and buyers (like MegaGloboCorpotronic Consolidated Inc). Disclosure: I work for Pivotal, on a Cloud Foundry project.
stickfigure 10y ago
"lightweight" compared to traditional JEE, but so is everything! This isn't going to make me popular on HN but: I don't think this is actually the case. Back in the mid 2000s I built EJB services by defining simple interface and implementation classes. I consumed the service by by injecting the interface into my clients. I tested my consumers by mocking the interface. Now I build REST services. I have to define and document a complex dance of verbs, nouns, and payloads. Client code requires stitching together text fragments into URLs and JSON. There's no typechecking across API boundaries and testing requires me to stub out crappy HTTP libraries. Hmmmm. There are good things to say about REST (like transparency and ubiquity), but it's not totally clear to me that the world is better off now than we were back in those Dark Days. Yeah, there was a lot of awful EJB code, but I'm finding no shortage of shitty REST microservice code floating about nowadays.
- jacques_chester 10y ago
  Is this an argument for using something like protobufs?
- rodgerd 10y ago
  I've witnessed a similar journey, having worked on an application 15 years ago that (for various reasons that made sense at the time) used RMI calls between a bunch of presentation logic and a service layer. It was refactored into a J2EE application after 7 years, and is now being refactored into a group of microservices, which causes a number of the longer-lived devs in the team to suggest everything old is new again.
- 16bytes 10y ago
  The way I remember it is if you were single-stack from client to server, yeah, EJBs and others in the J2EE worked pretty well. On the other hand, if you wanted to get of the rails and have clients in multiple stacks and clients who talked to different stacks, then it just all fell apart. Even multiple vendors in the J2EE space could be a problem. Being able to do things simply hid a lot of complexity. It was hard to investigate that complexity when things went wrong. It feels like chaos today, with myriad front-end frameworks and best practices changing every three months, but I would take this over mid-2000's Java tech because it just simply seems like less magic. I can break out Postman and just see what's going on. I agree that there's no golden bullet, and that there's no end of crappy REST definitions. Furthermore, it's mostly not even REST, not in a HATEOAS kind of way. But that's ok, I still feel more productive than I did 15 years ago, and I wouldn't want to go back.
- throwaway136 10y ago
  REST is so passe. The crowd now uses Protobuf with gRPC, retro like 1995.
- pjmlp 10y ago
  I agree with you, the hate on JEE seems to steam from younger developers not burned what came before it. And REST now with tooling like Swagger is catching up with what SOAP already provided out of the box. Kids, there are reasons why those features where there in first place.

by dlandis 10y ago

jacques_chester 10y ago

I don't think Phil wants to get sucked into the argument at all. He just wants to write cool software. I'm just going to leave this one at the doors of the bosses, both at vendors (like Pivotal) and buyers (like MegaGloboCorpotronic Consolidated Inc). Disclosure: I work for Pivotal, on a Cloud Foundry project.

stickfigure 10y ago

"lightweight" compared to traditional JEE, but so is everything! This isn't going to make me popular on HN but: I don't think this is actually the case. Back in the mid 2000s I built EJB services by defining simple interface and implementation classes. I consumed the service by by injecting the interface into my clients. I tested my consumers by mocking the interface. Now I build REST services. I have to define and document a complex dance of verbs, nouns, and payloads. Client code requires stitching together text fragments into URLs and JSON. There's no typechecking across API boundaries and testing requires me to stub out crappy HTTP libraries. Hmmmm. There are good things to say about REST (like transparency and ubiquity), but it's not totally clear to me that the world is better off now than we were back in those Dark Days. Yeah, there was a lot of awful EJB code, but I'm finding no shortage of shitty REST microservice code floating about nowadays.

jacques_chester 10y ago
Is this an argument for using something like protobufs?
rodgerd 10y ago
I've witnessed a similar journey, having worked on an application 15 years ago that (for various reasons that made sense at the time) used RMI calls between a bunch of presentation logic and a service layer. It was refactored into a J2EE application after 7 years, and is now being refactored into a group of microservices, which causes a number of the longer-lived devs in the team to suggest everything old is new again.
16bytes 10y ago
The way I remember it is if you were single-stack from client to server, yeah, EJBs and others in the J2EE worked pretty well. On the other hand, if you wanted to get of the rails and have clients in multiple stacks and clients who talked to different stacks, then it just all fell apart. Even multiple vendors in the J2EE space could be a problem. Being able to do things simply hid a lot of complexity. It was hard to investigate that complexity when things went wrong. It feels like chaos today, with myriad front-end frameworks and best practices changing every three months, but I would take this over mid-2000's Java tech because it just simply seems like less magic. I can break out Postman and just see what's going on. I agree that there's no golden bullet, and that there's no end of crappy REST definitions. Furthermore, it's mostly not even REST, not in a HATEOAS kind of way. But that's ok, I still feel more productive than I did 15 years ago, and I wouldn't want to go back.
throwaway136 10y ago
REST is so passe. The crowd now uses Protobuf with gRPC, retro like 1995.
pjmlp 10y ago
I agree with you, the hate on JEE seems to steam from younger developers not burned what came before it. And REST now with tooling like Swagger is catching up with what SOAP already provided out of the box. Kids, there are reasons why those features where there in first place.