8 ms·

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 reall

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 10y ago
Distributed transactions, queues, clustering, ORM, messaging, batch processing, web services, etc. All built-in, mostly working well and documented.
- jamesblonde 10y 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 10y ago
  All supported by Spring as well, sometimes interchangeably with, or adapting to, Java EE alternatives.
reitanqild 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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.

sz4kerto 10y ago

Distributed transactions, queues, clustering, ORM, messaging, batch processing, web services, etc. All built-in, mostly working well and documented.

jamesblonde 10y 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 10y ago
All supported by Spring as well, sometimes interchangeably with, or adapting to, Java EE alternatives.

reitanqild 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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.