11 ms·

Spring vs. Java EE

140 points by root_node 9y ago

openasocket 9y ago
I like Java, but I've never tried diving into the Spring or Java EE world. The little I've looked at it seem daunting and complex and I'm not sure what it really gives you at the end of the day. What functionality does it provide, what are the killer features? And is all this complexity justified?
- sz4kerto 9y ago
  Distributed transactions, queues, clustering, ORM, messaging, batch processing, web services, etc. All built-in, mostly working well and documented.
  - jamesblonde 9y ago
    And TLS/SSL, authentication using either LDAP, client-side SSL certs. Custom filters for REST endpoints (Aspect/J-like). We build our angularJS frontend against a Java EE backend. Works really well - we use ssh scripts to copy javascript/html changes to the app server instead of redeploying, means its 2 seconds between html/js changes and viewing it on the app (like it should be). Can be done.
  - jacques_chester 9y ago
    All supported by Spring as well, sometimes interchangeably with, or adapting to, Java EE alternatives.
- reitanqild 9y ago
  JavaEE provides a lot of the stuff programmers like me want in a way that is more or less consistent between different vendors. Typically this includes database access, ORM, message bus access etc. It also does so in a very integrated way so you can easily have for example a transaction that spans database modification and sending to a message bus. I like it. I found that embracing it allowed me to simplify lots of code.
- cle 9y ago
  The Spring that I've used (the DI Framework, Spring Integration, Spring MVC) is mainly designed to simplify and standardize enterprise applications. Mostly this involves standard and automated ways to "wire" together applications. This includes DI, but also includes configuration (e.g. configuration to enable a deployment pipeline), communication between components/services (client and server mapping of messages in a message bus to their ser/de impl and schema definitions, database interfaces), service and UI implementations themselves (SpringMVC, Spring Boot), etc. The benefit is that Spring is a glue layer that integrates all these various pieces of "enterprise" systems with minimal boilerplate. I don't have much experience with Java EE, so can't comment. My experience with Spring is not very positive--it enables and encourages applications and systems to have complex dependency graphs, and so often I've seen this result in giant balls of mud that, despite Spring's claim that it enables decoupled and modularized design, are rat's nests of unexpected coupling and hard-to-predict behavior.
  - ivan_gammel 9y ago
    Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you can wire dependency of one module on interface with implementation in another one). Moreover, it opens the way to plugin architecture, because application context definition can serve also as plugin definition and there exists discovery mechanism (e.g. classpath:/plugins/*.xml in plain DI or Spring Boot AutoConfiguration).
    - jacques_chester 9y ago
      I think maybe this comes down to the kind of injection. If you rely on variable or setter injection, you can easily create a kind of dark matter that invisibly warps the flexibility of the project. I and others have generally found that using Constructor injection greatly decouples a design and simplifies testing. And the Spring team have been saying so for at least as long as I've paid attention to the question[0]: > Constructor-based or setter-based DI? > ... > The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state. > ... [0] https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-setter-injection https://docs.spring.io/spring/docs/current/spring-framework-...
- nugator 9y ago
  Depends on what you're trying to solve. If you need to use a database, serve or get data over HTTP, run things every hour etc. chances are you'll save time and have a more stable and performing solution by using libraries from other parties. For example Spring libraries.
- jacques_chester 9y ago
  I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry project. Pivotal employs many members of the Spring team. I am not speaking for either Spring or Pivotal. Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...). I'm personally only familiar with Spring. And by "familiar" I mean I've learnt enough to be dangerous. But I've also learned to ask, before doing something: "Have the Spring team already solved this?" Take, for example, retrying an operation. A slightly hacky way to achieve this is to nest try-catches. A slightly less hacky way is some sort of loop. Then we extract this functionality out. I dunno, lambdas maybe? Or: I could use Spring-Retry[0]. That's just one example from my own experience. It used to be that Java EE was it. And it had to be: the mega-buyers insisted that there were sufficiently rigorous standards that they could switch vendors. Every giant corporation bleeds gold to some ancient vendor and they have an immune reaction, nearly a spasm allergy, to vendor lockin[1]. Opensource tools kinda sail around this, because ... uh ... what vendor lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's opensource. You can wait for community action, or engage a consultancy, or a related product company, or hire specialists, or sponsor something ... you have a wider range of options. Oh sure, there's tech lockin, but that's true of any decision. Either you exploit the features of a platform and tie yourself to it, or you write a rubber-room abstraction layer and tie yourself to that instead, but at your expense. In my observation as a 1st? 2nd? party, the Spring team pay close attention to the standards and support them. And, not coincidentally, many standards look -- gee, just awfully similar to something Spring had road-tested a few years prior. I think a lot of the shade thrown in this debate is happening because of money. Pivotal backs Spring very strongly, because it helps to sell our version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry). Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as well as being the stewards of the Java EE standards process. Red Hat own a solid suite of Java EE-capable and platform products, a portfolio largely overlapping with Pivotal's, IBM's and SAP's. In each of these cases there's a zero-ish sum-ish game underway. A company that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle (RIP your chequebook) isn't going to buy much from Pivotal. Meanwhile, the Spring team are just writing software. I lurk some of their internal Slack channels. It's almost exclusively technical and usually very thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a very different example of how to develop high-quality software. [0] https://github.com/spring-projects/spring-retry https://github.com/spring-projects/spring-retry [1] You will often find companies accusing each other this.
- orless 9y ago
  I work with Spring and Java EE professionally, prefer Spring wherever I can. Also use Spring for private/side projects (if not plain Java). But I'll talk about Spring here. I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". Dependency injection is important because it provides a healthy way to compose an application from many components or services. It's not exclusive to Spring of course, you can do DI/IoC without Spring (even without any framework), but it's baked into the very nature of Spring. Next, Spring provides "right" way to do a lot of more-or-less standard things. You have solutions for ORM, REST interfaces, security, batch processing and a thousand more tasks. From my experience, Spring solutions are mostly good or very good, at least much better than I'd design in a limited time frame. This gets me faster to the working solution. I also don't thing that Spring brings that much of a complexity overhead. Once you got past the first threshold (like, you can assemble you application from a few components) you're good to go. Ok, you will eventually need to learn concepts of individual Spring components (like ORM or security), but you'd need to learn them anyway. Eventually you'll need to fight Spring here and there, I won't deny it. This is normally related to the "automagical" stuff like autowiring or autoconfigurations - things which make your work easier in 98% but might make you crazy for the rest 2%.
  - baylisscg 9y ago
    I'd add a few more caveats. - Not all Spring projects seem to receive equal love. They can and do stomp on each other. - Spring's get-going-quickly seems to mostly come from serious design assumptions. Which is fine per se but they are not made clear which is not OK. - Spring is far too automagical. My latest bugbear is it deciding to change defaults depending on what it thinks I want. Bonus points for there being multiple settings that control the same behaviour only one of which can override. You're not using Java anymore you're using Spring.
  - springsux 9y ago
    > I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". DI creates debugging nightmares by moving what used to be compile time checks to runtime. Fowler was wrong.
- shouldbworking 9y ago
  It is daunting for sure. I stewed myself in the ecosystem last year by writing a couple open source libraries and fell in love with it. Java was the sexy language of the 90's, ironic because The best way I can describe it is the exact opposite of the current sexy language, JavaScript. Java is great, the best, when I'm trying to build something creative. It's like having access to an entire parts warehouse vs a toolshed for most other languages. Unlike especially JS, most libraries are well tested and most people agree on doing things a certain way. There's not a lot of unknowns, almost no flux, and once you know the rules you can focus on your problem and ignore the "ecosystem" almost entirely. The complexity can be looked at from a different perspective, I see it as similar to Roman characters vs Chinese. Learning 26 characters is a hell of a lot easier but with a couple thousand you can say the same things with a lot less writing. Once you've gotten over the cognitive hill of learning the complexity it doesn't really get in the way. It's there when you need it, and you ignore it when you don't. Contrast this to JavaScript where most advancements redefine workflows or parts of the language core libraries. It feels like the most exciting thing about JavaScript is how unstable it is, something that scares the hell out of me after working on 15+ year old code. What you trade off with complexity in Java is definitely less work than keeping up with js for more than a year. This sort of became a js/Java comparison because there's a ton of similarity in the hype between them and their lifecycle so far. Java was not always so complex after all. You can see the complexity of the JS ecosystem and language growing steadily and I have no doubt that in five years it will be just as complex as Java. The complexity is driven by the big guys that actually need it, and being the big guys, they also have the most influence on what the language eventually becomes. So to recap, no, for the vast majority of projects the complexity is definitely not justified. It's there so the language can support the 1% of projects that need all that. On the other hand, once you know your way around it's fairly easy to ignore those parts. What access to all this stuff really gives you is power. As a footnote, give JS some time and it will be the same. Any language picked up by corporate interests is basically destined for overengineering.
  - pjmlp 9y ago
    > Any language picked up by corporate interests is basically destined for overengineering. I saw plenty of overengineering even with C back in the 90's. My biggest example was a server framework that used its own concept of opaque pointers all over the code, because they abstracted data access over shared memory to all instances of the server. So any memory access to data structures storing server state required translating between handles and pointer all the time.
- vbezhenar 9y ago
  Both Java EE and Spring provide a huge amount of functionality and do it in an uniform way, so you don't have to glue lots of different libraries together. They aim for enterprise world, where this functionality is required. Not every project need it, so sometimes it might be not necessary. IoC is awesome on huge projects, but if your project is 10-20 classes, it's just unnecessary abstraction. Distributed transactions increase robustness, when you're working with multiple databases and message queues, but if you're creating website with a single database, you just don't need it. WebServices implementation is a must, when you have to integrate with someone, who's exposing their API via webservice and you'll drown in details, if you'll try to implement it manually, but if you're using lightweight REST APIs, it's quite possible to do it without any frameworks. So it's good when you need it, and it's unnecessary over-engineering for simple projects.
  - orless 9y ago
    Whether IoC is reasonable or not does not depend on the number of classes in the project. It is still a useful pattern even if you have, like, 3 classes (component A using implementation B of the interface Ib). It's just if you have only few components, you may want to wire them manually in maybe 10 lines of code instead of dropping in Spring JARs.
- snambi 9y ago
  I used to like spring in favor of JEE Application servers. But of late, spring is getting too bloated, too complicated and buggy. OTOH, newer java frameworks are simpler and easier to work with. For example, spark application framework or retrofit for rest APIs. At this point spring is very similar to JEE.
- twic 9y ago
  I've spent multiple-year periods using each of Java EE, Spring, and no formal framework (in practice, Guice for DI, Tomcat/Servlets for web, lots of libraries, and lots and lots of homebrew stuff). I can say with confidence that if your goal is just to build a sophisticated application, there's no advantage to using the frameworks. They include a lot of functionality, but beyond demo-scale applications, you will spend as much time fighting the framework as you save by using it. The frameworks probably do save you time in getting started; Spring Boot certainly has a pretty smooth experience going from nothing to a running project with a controller, database, etc. But that's a tiny expense in the lifetime of a project. EE might give you some kind of confidence that you can port your app between app servers (or different releases of an app server!). If you work in an environment where some idiot up the hierarchy has decided everyone should use app servers, that might be useful, but there's no point setting out to create such an environment.
  - taurath 9y ago
    In my experience an advantage of frameworks is that you can plop down a team with experience in that framework and have them be moderately productive quickly. I'd say they're a disadvantage in many cases depending on what type of app you're working on.
dlandis 9y 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 9y 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 9y 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 9y ago
    Is this an argument for using something like protobufs?
marktangotango 9y ago
Spring and EJB 3 are like Django, Rails, and their ilk: big bloated frameworks that include everything you need to build multi tier apps, plus or minus a few features here and there. Convergent evolution is a wondrous thing.
- specialist 9y ago
  Feels more like enterprise architecture jargon bingo. I never understood (the point of) EJB. Shamefacedly admit I was once a huge Hibernate fan. But I got over it. Can't speak to Django nor Rails. --- Prior joke: Spring is an stacktrace obfuscation framework. New joke: NodeJS is a control-flow obfuscation framework.
  - spiralpolitik 9y ago
    The original goal of EJB's was to push functional decomposition out onto the network. Entity beans were always a disaster, and Stateful Session Beans had scaling problems, but Stateless Session beans by the time of EJB3 were an easy way to push logic out to the network while getting a whole bunch of stuff (pooling, scaling, failover, transaction management, security, etc) for free. These days they'd be calling them micro services. The main problem was combining everything into the big ball of mud that is J2EE. If they had let each component live and die on its own merits I think the ecosystem would be in a much better state today.
  - manyxcxi 9y ago
    I laughed harder than I should've because I just moments ago was reviewing a stack trace with a teammate and questioned "have you ever gotten anything useful after line 50 of a Spring stack trace?" And then we all laughed until we realized half the trace was because it got logged and thrown and then logged again...
twblalock 9y ago
In terms of the popularity of the two frameworks, all I can say is that I have been interviewing 2-3 Java engineers per week for the past few months, and almost all of them put Spring on their resume and not Java EE.
- springsux 9y ago
  I'm thinking of changing my resume to 1 page with a 72 pt sized question mark.
- EtienneK 9y ago
  This does seem to be the trend the industry is taking. And for good reason. After using Spring Boot for 2 years now, I'll never go back to EE.
codecamper 9y ago
I'm surprised this is still a thing.
neverminder 9y ago
> for example here’s a copy from Lightbend (the company behind Scala, Play & Lagom) I use Play 2 for most of my projects and frankly knowing what I know about Spring and J2EE (even though having never worked with them for the same reason) I couldn't really think of any reason to choose either of these outdated behemoths. With something like Play 2 and Slick/JOOQ you could run circles around these two.
- gbersac 9y ago
  Same here, Scala rocks ! Too bad play 2 is now using guice and promots runtime dependency injection like in Java world. Compile dependency injection is much better, I fear they'll try to mimick spring more and more in order to attract java crowds.
  - raphaelj 9y ago
    I got the same feeling here. Implicits in Scala can act as statically checked dependency injection, I don't know why they are going for this runtime dependant injection instead.
    - merb 9y ago
      Play supports static DI aka cake pattern or macwire aswell.
  - edem 9y ago
    Until you start working with Clojure or even Kotlin. Then Scala feels like a baroque behemoth.
  - wsargent 9y ago
    Hi, I'm on the Play team. We've got a number of projects showing compile time injection: Java compile time DI: https://github.com/playframework/play-java-compile-di-example https://github.com/playframework/play-java-compile-di-exampl... Java compile time DI using Dagger 2: https://github.com/playframework/play-java-dagger2-example https://github.com/playframework/play-java-dagger2-example Scala compile time DI: https://github.com/playframework/play-scala-compile-di-example https://github.com/playframework/play-scala-compile-di-examp... Scala compile time DI with Macwire: https://github.com/playframework/play-scala-macwire-di-example https://github.com/playframework/play-scala-macwire-di-examp... Thanks!
folli 9y ago
If I want to build a web app from scratch which should have some basic features (user identification, some standard level of security, REST interface, database integration) and I have some okay knowledge of Java (mainly CLI applications and some Android programming), which framework would you recommend for me to get started? I'm afraid to get lost in the details too quickly, so a framework that provides a working example which can than be adjusted to my needs would be very welcome. Any suggestions?
- Joeri 9y ago
  Play framework is easy to get started with if you just go by their documentation. I switched from php to play and was happy with the result. Admittedly, I did not try spring, so I don't know how it compares.
- gresrun 9y ago
  Dropwizard http://www.dropwizard.io/1.1.0/docs/ http://www.dropwizard.io/1.1.0/docs/
- deleted 9y ago
  [deleted]
- andrewwharton 9y ago
  I'd recommend Grails. https://grails.org/ https://grails.org/ You use Groovy, but it's pretty similar to Java and there's plenty of resources to bring you up to speed.
  - vorg 9y ago
    Grails 2.x or Grails 3 ? Many sites using version 2.x haven't bothered upgrading to version 3 in the two years since it was released, nor are there many version 3 plugins converted. And very few new Grails projects are started.
    - andrewwharton 9y ago
      We use Grails for a lot of internal applications at our company, all 2.x (2.3.x through 2.5.x). I can't really comment on Grails 3, funnily because the applications were written before 3.x came out and we haven't bothered upgrading them yet... :) I've only taken a brief look at what's involved in upgrading them, but other stuff has always been higher priority. It's probably worth being familiar with both versions, because Grails had plenty of adoption before 3.x came out and 2.x is still being maintained.
sgt 9y ago
I am gradually phasing out Java EE in favor of vertx.io
- springsux 9y ago
  I don't get reactive or functional. I get, step 1 do something, step 2 if something then do step 4 else step 3. Those were really the days. I guess if I could have my dream framework today it would be just Java and some Apache jars and some Google jars, maybe an odd jar here or there. And Eclipse, always Eclipse. I'd also steer clear of anyone who can quote GoF or Fowler.
scaleout1 9y ago
Spring vs. JavaEE is a topic that stopped being relevant five years ago. I cant believe anyone seriously considering any of these heavy duty teach stack in 2017. There are much much better choices out there even for Java developers, and if they can come out of their comfort zone a bit there is Clojure, Scala, Kotlin etc with MUCH nicer fraemworks
- jrwiegand 9y ago
  What frameworks would you recommend or look to get started with?
  - scaleout1 9y ago
    Finagle/Finatra based microservices at Twitter. Using the same stack at a different company now
  - yogthos 9y ago
    Try Luminus http://www.luminusweb.net/docs http://www.luminusweb.net/docs for Clojure. It's pretty easy to get started with.
- edem 9y ago
  Name just one alternative you have in-depth experience with. Not just pet projects but production code.
  - yogthos 9y ago
    Sure, I used to work with Java EE in the enterprise. My team switched over entirely to working with Clojure over the course of the past 6 years. We build large applications for use at the hospital. For context, the projects I work on are typically implemented over several years by a team of 5-10 developers. We find that our projects now have drastically less code doing the same types of things. Not only that, but the code we do write is predominantly declarative in nature. Clojure makes it much easier to separate the intent of the code from the implementation details. Conversely, having less code means we're less attached to it. When it takes a 1000 lines to solve a problem, you tend to keep them around once you get a solution working. When you have 100 lines, it's much easier to throw them away and write a cleaner solution when you understand the problem. Clojure projects are easier to debug and maintain thanks to pervasive immutability in the language. This allows us to safely think about parts of the application in isolation. When I come back to code that I wrote a few months ago and make a change, I know that the change is local and it's not going to affect another part of the project via side effects. Clojure facilitates interactive development by providing strong integration between the editor and the REPL. When we're building new features, we're able to experiment interactively to see what approach will work best. Since Clojure also runs in the browser with ClojureScript, we're able to use the same language for the full stack. This also lets us share code, such as validation logic, between the client and the server. Meanwhile, we're still able to leverage existing Java libraries, infrastructure, and reap all the benefits of using the JVM.

140 points by root_node 9y ago

I like Java, but I've never tried diving into the Spring or Java EE world. The little I've looked at it seem daunting and complex and I'm not sure what it really gives you at the end of the day. What functionality does it provide, what are the killer features? And is all this complexity justified?

sz4kerto 9y ago
Distributed transactions, queues, clustering, ORM, messaging, batch processing, web services, etc. All built-in, mostly working well and documented.
- jamesblonde 9y ago
  And TLS/SSL, authentication using either LDAP, client-side SSL certs. Custom filters for REST endpoints (Aspect/J-like). We build our angularJS frontend against a Java EE backend. Works really well - we use ssh scripts to copy javascript/html changes to the app server instead of redeploying, means its 2 seconds between html/js changes and viewing it on the app (like it should be). Can be done.
- jacques_chester 9y ago
  All supported by Spring as well, sometimes interchangeably with, or adapting to, Java EE alternatives.
reitanqild 9y ago
JavaEE provides a lot of the stuff programmers like me want in a way that is more or less consistent between different vendors. Typically this includes database access, ORM, message bus access etc. It also does so in a very integrated way so you can easily have for example a transaction that spans database modification and sending to a message bus. I like it. I found that embracing it allowed me to simplify lots of code.
cle 9y ago
The Spring that I've used (the DI Framework, Spring Integration, Spring MVC) is mainly designed to simplify and standardize enterprise applications. Mostly this involves standard and automated ways to "wire" together applications. This includes DI, but also includes configuration (e.g. configuration to enable a deployment pipeline), communication between components/services (client and server mapping of messages in a message bus to their ser/de impl and schema definitions, database interfaces), service and UI implementations themselves (SpringMVC, Spring Boot), etc. The benefit is that Spring is a glue layer that integrates all these various pieces of "enterprise" systems with minimal boilerplate. I don't have much experience with Java EE, so can't comment. My experience with Spring is not very positive--it enables and encourages applications and systems to have complex dependency graphs, and so often I've seen this result in giant balls of mud that, despite Spring's claim that it enables decoupled and modularized design, are rat's nests of unexpected coupling and hard-to-predict behavior.
- ivan_gammel 9y ago
  Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you can wire dependency of one module on interface with implementation in another one). Moreover, it opens the way to plugin architecture, because application context definition can serve also as plugin definition and there exists discovery mechanism (e.g. classpath:/plugins/*.xml in plain DI or Spring Boot AutoConfiguration).
  - jacques_chester 9y ago
    I think maybe this comes down to the kind of injection. If you rely on variable or setter injection, you can easily create a kind of dark matter that invisibly warps the flexibility of the project. I and others have generally found that using Constructor injection greatly decouples a design and simplifies testing. And the Spring team have been saying so for at least as long as I've paid attention to the question[0]: > Constructor-based or setter-based DI? > ... > The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state. > ... [0] https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-setter-injection https://docs.spring.io/spring/docs/current/spring-framework-...
nugator 9y ago
Depends on what you're trying to solve. If you need to use a database, serve or get data over HTTP, run things every hour etc. chances are you'll save time and have a more stable and performing solution by using libraries from other parties. For example Spring libraries.
jacques_chester 9y ago
I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry project. Pivotal employs many members of the Spring team. I am not speaking for either Spring or Pivotal. Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...). I'm personally only familiar with Spring. And by "familiar" I mean I've learnt enough to be dangerous. But I've also learned to ask, before doing something: "Have the Spring team already solved this?" Take, for example, retrying an operation. A slightly hacky way to achieve this is to nest try-catches. A slightly less hacky way is some sort of loop. Then we extract this functionality out. I dunno, lambdas maybe? Or: I could use Spring-Retry[0]. That's just one example from my own experience. It used to be that Java EE was it. And it had to be: the mega-buyers insisted that there were sufficiently rigorous standards that they could switch vendors. Every giant corporation bleeds gold to some ancient vendor and they have an immune reaction, nearly a spasm allergy, to vendor lockin[1]. Opensource tools kinda sail around this, because ... uh ... what vendor lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's opensource. You can wait for community action, or engage a consultancy, or a related product company, or hire specialists, or sponsor something ... you have a wider range of options. Oh sure, there's tech lockin, but that's true of any decision. Either you exploit the features of a platform and tie yourself to it, or you write a rubber-room abstraction layer and tie yourself to that instead, but at your expense. In my observation as a 1st? 2nd? party, the Spring team pay close attention to the standards and support them. And, not coincidentally, many standards look -- gee, just awfully similar to something Spring had road-tested a few years prior. I think a lot of the shade thrown in this debate is happening because of money. Pivotal backs Spring very strongly, because it helps to sell our version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry). Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as well as being the stewards of the Java EE standards process. Red Hat own a solid suite of Java EE-capable and platform products, a portfolio largely overlapping with Pivotal's, IBM's and SAP's. In each of these cases there's a zero-ish sum-ish game underway. A company that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle (RIP your chequebook) isn't going to buy much from Pivotal. Meanwhile, the Spring team are just writing software. I lurk some of their internal Slack channels. It's almost exclusively technical and usually very thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a very different example of how to develop high-quality software. [0] https://github.com/spring-projects/spring-retry https://github.com/spring-projects/spring-retry [1] You will often find companies accusing each other this.
orless 9y ago
I work with Spring and Java EE professionally, prefer Spring wherever I can. Also use Spring for private/side projects (if not plain Java). But I'll talk about Spring here. I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". Dependency injection is important because it provides a healthy way to compose an application from many components or services. It's not exclusive to Spring of course, you can do DI/IoC without Spring (even without any framework), but it's baked into the very nature of Spring. Next, Spring provides "right" way to do a lot of more-or-less standard things. You have solutions for ORM, REST interfaces, security, batch processing and a thousand more tasks. From my experience, Spring solutions are mostly good or very good, at least much better than I'd design in a limited time frame. This gets me faster to the working solution. I also don't thing that Spring brings that much of a complexity overhead. Once you got past the first threshold (like, you can assemble you application from a few components) you're good to go. Ok, you will eventually need to learn concepts of individual Spring components (like ORM or security), but you'd need to learn them anyway. Eventually you'll need to fight Spring here and there, I won't deny it. This is normally related to the "automagical" stuff like autowiring or autoconfigurations - things which make your work easier in 98% but might make you crazy for the rest 2%.
- baylisscg 9y ago
  I'd add a few more caveats. - Not all Spring projects seem to receive equal love. They can and do stomp on each other. - Spring's get-going-quickly seems to mostly come from serious design assumptions. Which is fine per se but they are not made clear which is not OK. - Spring is far too automagical. My latest bugbear is it deciding to change defaults depending on what it thinks I want. Bonus points for there being multiple settings that control the same behaviour only one of which can override. You're not using Java anymore you're using Spring.
- springsux 9y ago
  > I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". DI creates debugging nightmares by moving what used to be compile time checks to runtime. Fowler was wrong.
shouldbworking 9y ago
It is daunting for sure. I stewed myself in the ecosystem last year by writing a couple open source libraries and fell in love with it. Java was the sexy language of the 90's, ironic because The best way I can describe it is the exact opposite of the current sexy language, JavaScript. Java is great, the best, when I'm trying to build something creative. It's like having access to an entire parts warehouse vs a toolshed for most other languages. Unlike especially JS, most libraries are well tested and most people agree on doing things a certain way. There's not a lot of unknowns, almost no flux, and once you know the rules you can focus on your problem and ignore the "ecosystem" almost entirely. The complexity can be looked at from a different perspective, I see it as similar to Roman characters vs Chinese. Learning 26 characters is a hell of a lot easier but with a couple thousand you can say the same things with a lot less writing. Once you've gotten over the cognitive hill of learning the complexity it doesn't really get in the way. It's there when you need it, and you ignore it when you don't. Contrast this to JavaScript where most advancements redefine workflows or parts of the language core libraries. It feels like the most exciting thing about JavaScript is how unstable it is, something that scares the hell out of me after working on 15+ year old code. What you trade off with complexity in Java is definitely less work than keeping up with js for more than a year. This sort of became a js/Java comparison because there's a ton of similarity in the hype between them and their lifecycle so far. Java was not always so complex after all. You can see the complexity of the JS ecosystem and language growing steadily and I have no doubt that in five years it will be just as complex as Java. The complexity is driven by the big guys that actually need it, and being the big guys, they also have the most influence on what the language eventually becomes. So to recap, no, for the vast majority of projects the complexity is definitely not justified. It's there so the language can support the 1% of projects that need all that. On the other hand, once you know your way around it's fairly easy to ignore those parts. What access to all this stuff really gives you is power. As a footnote, give JS some time and it will be the same. Any language picked up by corporate interests is basically destined for overengineering.
- pjmlp 9y ago
  > Any language picked up by corporate interests is basically destined for overengineering. I saw plenty of overengineering even with C back in the 90's. My biggest example was a server framework that used its own concept of opaque pointers all over the code, because they abstracted data access over shared memory to all instances of the server. So any memory access to data structures storing server state required translating between handles and pointer all the time.
vbezhenar 9y ago
Both Java EE and Spring provide a huge amount of functionality and do it in an uniform way, so you don't have to glue lots of different libraries together. They aim for enterprise world, where this functionality is required. Not every project need it, so sometimes it might be not necessary. IoC is awesome on huge projects, but if your project is 10-20 classes, it's just unnecessary abstraction. Distributed transactions increase robustness, when you're working with multiple databases and message queues, but if you're creating website with a single database, you just don't need it. WebServices implementation is a must, when you have to integrate with someone, who's exposing their API via webservice and you'll drown in details, if you'll try to implement it manually, but if you're using lightweight REST APIs, it's quite possible to do it without any frameworks. So it's good when you need it, and it's unnecessary over-engineering for simple projects.
- orless 9y ago
  Whether IoC is reasonable or not does not depend on the number of classes in the project. It is still a useful pattern even if you have, like, 3 classes (component A using implementation B of the interface Ib). It's just if you have only few components, you may want to wire them manually in maybe 10 lines of code instead of dropping in Spring JARs.
snambi 9y ago
I used to like spring in favor of JEE Application servers. But of late, spring is getting too bloated, too complicated and buggy. OTOH, newer java frameworks are simpler and easier to work with. For example, spark application framework or retrofit for rest APIs. At this point spring is very similar to JEE.
twic 9y ago
I've spent multiple-year periods using each of Java EE, Spring, and no formal framework (in practice, Guice for DI, Tomcat/Servlets for web, lots of libraries, and lots and lots of homebrew stuff). I can say with confidence that if your goal is just to build a sophisticated application, there's no advantage to using the frameworks. They include a lot of functionality, but beyond demo-scale applications, you will spend as much time fighting the framework as you save by using it. The frameworks probably do save you time in getting started; Spring Boot certainly has a pretty smooth experience going from nothing to a running project with a controller, database, etc. But that's a tiny expense in the lifetime of a project. EE might give you some kind of confidence that you can port your app between app servers (or different releases of an app server!). If you work in an environment where some idiot up the hierarchy has decided everyone should use app servers, that might be useful, but there's no point setting out to create such an environment.
- taurath 9y ago
  In my experience an advantage of frameworks is that you can plop down a team with experience in that framework and have them be moderately productive quickly. I'd say they're a disadvantage in many cases depending on what type of app you're working on.

dlandis 9y 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 9y 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 9y 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 9y ago
  Is this an argument for using something like protobufs?

marktangotango 9y ago

Spring and EJB 3 are like Django, Rails, and their ilk: big bloated frameworks that include everything you need to build multi tier apps, plus or minus a few features here and there. Convergent evolution is a wondrous thing.

specialist 9y ago
Feels more like enterprise architecture jargon bingo. I never understood (the point of) EJB. Shamefacedly admit I was once a huge Hibernate fan. But I got over it. Can't speak to Django nor Rails. --- Prior joke: Spring is an stacktrace obfuscation framework. New joke: NodeJS is a control-flow obfuscation framework.
- spiralpolitik 9y ago
  The original goal of EJB's was to push functional decomposition out onto the network. Entity beans were always a disaster, and Stateful Session Beans had scaling problems, but Stateless Session beans by the time of EJB3 were an easy way to push logic out to the network while getting a whole bunch of stuff (pooling, scaling, failover, transaction management, security, etc) for free. These days they'd be calling them micro services. The main problem was combining everything into the big ball of mud that is J2EE. If they had let each component live and die on its own merits I think the ecosystem would be in a much better state today.
- manyxcxi 9y ago
  I laughed harder than I should've because I just moments ago was reviewing a stack trace with a teammate and questioned "have you ever gotten anything useful after line 50 of a Spring stack trace?" And then we all laughed until we realized half the trace was because it got logged and thrown and then logged again...

twblalock 9y ago

In terms of the popularity of the two frameworks, all I can say is that I have been interviewing 2-3 Java engineers per week for the past few months, and almost all of them put Spring on their resume and not Java EE.

springsux 9y ago
I'm thinking of changing my resume to 1 page with a 72 pt sized question mark.
EtienneK 9y ago
This does seem to be the trend the industry is taking. And for good reason. After using Spring Boot for 2 years now, I'll never go back to EE.

codecamper 9y ago

I'm surprised this is still a thing.

neverminder 9y ago

> for example here’s a copy from Lightbend (the company behind Scala, Play & Lagom) I use Play 2 for most of my projects and frankly knowing what I know about Spring and J2EE (even though having never worked with them for the same reason) I couldn't really think of any reason to choose either of these outdated behemoths. With something like Play 2 and Slick/JOOQ you could run circles around these two.

gbersac 9y ago
Same here, Scala rocks ! Too bad play 2 is now using guice and promots runtime dependency injection like in Java world. Compile dependency injection is much better, I fear they'll try to mimick spring more and more in order to attract java crowds.
- raphaelj 9y ago
  I got the same feeling here. Implicits in Scala can act as statically checked dependency injection, I don't know why they are going for this runtime dependant injection instead.
  - merb 9y ago
    Play supports static DI aka cake pattern or macwire aswell.
- edem 9y ago
  Until you start working with Clojure or even Kotlin. Then Scala feels like a baroque behemoth.
- wsargent 9y ago
  Hi, I'm on the Play team. We've got a number of projects showing compile time injection: Java compile time DI: https://github.com/playframework/play-java-compile-di-example https://github.com/playframework/play-java-compile-di-exampl... Java compile time DI using Dagger 2: https://github.com/playframework/play-java-dagger2-example https://github.com/playframework/play-java-dagger2-example Scala compile time DI: https://github.com/playframework/play-scala-compile-di-example https://github.com/playframework/play-scala-compile-di-examp... Scala compile time DI with Macwire: https://github.com/playframework/play-scala-macwire-di-example https://github.com/playframework/play-scala-macwire-di-examp... Thanks!

folli 9y ago

If I want to build a web app from scratch which should have some basic features (user identification, some standard level of security, REST interface, database integration) and I have some okay knowledge of Java (mainly CLI applications and some Android programming), which framework would you recommend for me to get started? I'm afraid to get lost in the details too quickly, so a framework that provides a working example which can than be adjusted to my needs would be very welcome. Any suggestions?

Joeri 9y ago
Play framework is easy to get started with if you just go by their documentation. I switched from php to play and was happy with the result. Admittedly, I did not try spring, so I don't know how it compares.
gresrun 9y ago
Dropwizard http://www.dropwizard.io/1.1.0/docs/ http://www.dropwizard.io/1.1.0/docs/
deleted 9y ago
[deleted]
andrewwharton 9y ago
I'd recommend Grails. https://grails.org/ https://grails.org/ You use Groovy, but it's pretty similar to Java and there's plenty of resources to bring you up to speed.
- vorg 9y ago
  Grails 2.x or Grails 3 ? Many sites using version 2.x haven't bothered upgrading to version 3 in the two years since it was released, nor are there many version 3 plugins converted. And very few new Grails projects are started.
  - andrewwharton 9y ago
    We use Grails for a lot of internal applications at our company, all 2.x (2.3.x through 2.5.x). I can't really comment on Grails 3, funnily because the applications were written before 3.x came out and we haven't bothered upgrading them yet... :) I've only taken a brief look at what's involved in upgrading them, but other stuff has always been higher priority. It's probably worth being familiar with both versions, because Grails had plenty of adoption before 3.x came out and 2.x is still being maintained.

sgt 9y ago

I am gradually phasing out Java EE in favor of vertx.io

springsux 9y ago
I don't get reactive or functional. I get, step 1 do something, step 2 if something then do step 4 else step 3. Those were really the days. I guess if I could have my dream framework today it would be just Java and some Apache jars and some Google jars, maybe an odd jar here or there. And Eclipse, always Eclipse. I'd also steer clear of anyone who can quote GoF or Fowler.

scaleout1 9y ago

Spring vs. JavaEE is a topic that stopped being relevant five years ago. I cant believe anyone seriously considering any of these heavy duty teach stack in 2017. There are much much better choices out there even for Java developers, and if they can come out of their comfort zone a bit there is Clojure, Scala, Kotlin etc with MUCH nicer fraemworks

jrwiegand 9y ago
What frameworks would you recommend or look to get started with?
- scaleout1 9y ago
  Finagle/Finatra based microservices at Twitter. Using the same stack at a different company now
- yogthos 9y ago
  Try Luminus http://www.luminusweb.net/docs http://www.luminusweb.net/docs for Clojure. It's pretty easy to get started with.
edem 9y ago
Name just one alternative you have in-depth experience with. Not just pet projects but production code.
- yogthos 9y ago
  Sure, I used to work with Java EE in the enterprise. My team switched over entirely to working with Clojure over the course of the past 6 years. We build large applications for use at the hospital. For context, the projects I work on are typically implemented over several years by a team of 5-10 developers. We find that our projects now have drastically less code doing the same types of things. Not only that, but the code we do write is predominantly declarative in nature. Clojure makes it much easier to separate the intent of the code from the implementation details. Conversely, having less code means we're less attached to it. When it takes a 1000 lines to solve a problem, you tend to keep them around once you get a solution working. When you have 100 lines, it's much easier to throw them away and write a cleaner solution when you understand the problem. Clojure projects are easier to debug and maintain thanks to pervasive immutability in the language. This allows us to safely think about parts of the application in isolation. When I come back to code that I wrote a few months ago and make a change, I know that the change is local and it's not going to affect another part of the project via side effects. Clojure facilitates interactive development by providing strong integration between the editor and the REPL. When we're building new features, we're able to experiment interactively to see what approach will work best. Since Clojure also runs in the browser with ClojureScript, we're able to use the same language for the full stack. This also lets us share code, such as validation logic, between the client and the server. Meanwhile, we're still able to leverage existing Java libraries, infrastructure, and reap all the benefits of using the JVM.