6 ms·

Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012

44 points by markokocic 15y ago

vetler 15y ago
JEE 6 is a huge leap forward compared to how J2EE used to be. However, there are a few problems. First of all, JSF is the most horrible framework for creating web applications that I've ever used. Its intention is to make web development easier, but what you get is a huge mess of HTML and JavaScript that introduces a lot of new problems. Escpecially since it gives you the impression that you don't need to know HTML and JavaScript to work with it. EJBs are a lot easier, and as long as you don't access them remotely, you don't need interfaces or XML files. If you put them remotely, you need both. With injection you don't need to look up EJBs manually, except if you put them remotely - because if the reference to the remote EJB is invalidated (i.e. if it's accessed while the remote server is down), you'll need to look it up manually again. As long as you choose something other than JSF, JEE 6 is fine. Of course, then there's the application servers. I've only tried Glassfish (for a while it was the only fully certified JEE 6 app server), but it had a few problems - I heard one of the latest versions had a GZip filter that would have spinning threads taking 100% CPU. JEE has come a long way, but I'll probably choose Spring for my next Java project.
- deleted 15y ago
  [deleted]
- UK-AL 15y ago
  I remember jsf having a bad rep however jsf2 is supposed to be not as bad.
- edwinnathaniel 15y ago
  JSF2 has definitely improved compare to the previous version but I suppose JSF (1/2) is more akin of ASP.NET (component oriented) which might put off a large number of developers who prefer simple templating with pure JS.
jfager 15y ago
Alternate title: Why I will stab my eye out with a fork instead of running a cheese grater over my knuckles.
- moondowner 15y ago
  Definitely. I'm perfectly happy with Spring. A developer can create the most lightweight web application with the most manageable code with Spring.
  - Torn 15y ago
    Have you tried Play (playframework.org) yet?
    - rufugee 15y ago
      I have high hopes that Play will become the defacto "pragmatic" java/scala(/kotlin, when it's finally ready) framework. Play rocks.
      - eropple 15y ago
        I would dearly like to use Play, but I find it really uncomfortable (and not because I'm some stuck-in-my-ways Java developer). Play's heavy abuse of statics is a real problem from my perspective, in large part because it's extremely painful to write inheritance-based code; I realize it helps the simpler use case but I find that I don't regularly write to the simpler use case. I've gone back to Servlets+Guice+Velocity because it's easier for me to write expressive code.
    - moondowner 15y ago
      Yes I've tried it (pre Play 2), and there's one thing I don't like - favoring/integrating certain tools in it. I know that it uses Hibernate through the JPA API, and if you want to use a different ORM you'll have to make a lot of workarounds. And it's not only about ORM. A month or so ago I read that it will integrate a certain JavaScript library in it too. Tapestry Web Framework had this attitude, but the developers found that it brought more negative than positive effect, I hope Play will see the same. Modularity and ease of configuration is a very important thing. I like it's Scala support and enthusiasm though, and I will definitely try it some day again.
lebski88 15y ago
I'm exceeding unconvinced by this article. His plus points for JEE were really stretching: - Sustainability - do we really think Spring is going to die? - Light weight testing is possible - so JEE has caught up with spring... - Convention over configuration - like spring. - Multiple providers - OK that's a potential benefit but I'm not seeing the realisation of it yet. It could also mean that different providers have different bugs. From my personal investigations Spring offers many advantages. In some places JEE has matched them in others it's still behind. So I would ask myself do I want to go with the framework that's driving the advancement, or the framework that is playing catchup? Also these days Spring is the standard.
CodeMage 15y ago
The article is almost completely devoid of useful content. Basically the only useful argument is: JEE 6 has most of the stuff Spring has, it's "light" (lighter than J2EE) and, unlike Spring, it's a standard with several reference implementations. While the argument itself is worthy of discussion, there was no need to package it inside an article full of fluff. The author claims that she hopes to be neutral, but completely fails to do so when it comes to comparison of Spring and JEE: she lists advantages of JEE and then those of Spring, but makes sure that each of the Spring advantages listed is accompanied by a "BUT", which boils down to either "JEE has it too" or "JEE doesn't have it, but you probably won't need it". Yes, I know she said beforehand that she would explain why differences between Spring and JEE lead her to JEE, but the way she did it robs her of neutrality she claims to have. And it's not just the form I'm talking about, it's the substance, too. If all of your reasons to lean towards JEE boil down to "well, it has all that I need that Spring has and I personally don't care about the stuff it doesn't have", you're not really contributing anything.
- astrodust 15y ago
  Most Java programmers wouldn't know "light" if it fell on them and pinned them to the ground.
  - UK-AL 15y ago
    As a java programmer I get offended by this. I was taught programming on scheme, I use django for quick apps, i know a variety programming paradigms but there is no one best tool to rule them all. Different tools are good for different jobs. For example scala programmers completely ignore backwards compatibility problems they have had in the past. Such a thing would unimaginable for a large app.
    - kaffiene 15y ago
      Yeah, me to. I've used Java for years without doing any Enterprise stuff, so to me Java has always just been a really good general purpose programming language that does OO a million percent better than C++ (from whence I came). When I had to do some web stuff with Java I recoiled in horror from the mess that all that old enterprise stuff was at the time - XML hell! I gave up and just wrote a servlet directly. What I'm leading to is that there is bloat in the Java space - that old EE stuff was god-awful, but extending this to say that everything in Java is bloated and over-engineered is offensive and ignorant. Some frameworks are heavy like old EE. Some frameworks are light like Play! There's nothing inherent in Java that means you can't have lightweight solutions. But bashing Java is cool on HN...
juliano_q 15y ago
This article only reinforced my conviction to use Spring and not JEE. It is possible to test on JEE? It is "light"? It have convention over configuration? Well, Spring has it for almost a decade, is trivial do deploy on any server and have much more powerful libraries. Furthermore, JSF is horrible.
thebluesky 15y ago
Friends don't let friends use either Spring or Java EE.
- Sandman 15y ago
  You've already expressed your disdain for both Spring and Java EE in several comments. However, I haven't noticed that you provided any arguments on why you think both of these solutions are bad. I'd be interested in hearing them.
  - tbsdy 15y ago
    I second this. Please, put your money where your mouth is!
  - codemonkeyland 15y ago
    I think he's simply stating what has made many Java programmers very cynical about frameworks such as these. Java EE layers abstraction on top of abstraction. App servers like WebSphere use a ton of memory before you've even deployed your app to the server and they charge you an arm and a leg (yes I know glassfish and jboss are free). Java code is verbose and ill-suited to crafting systems which generate html. The Java enterprise camp was championing the idea that web applications should have JSP talking to session beans, which talk to entity beans which then talks to your actual data store. By the time you've coded it all up you realise that it's slow before you've even added any business logic. Things have improved since then, but they lost my trust a long time ago. Spring seems to love having programmers take java source and translating it into XML so it's much more verbose than java (quite a feat in itself) and hides some of the most critical code from the IDE. The "benefits" provided by such approaches are marginal at best. The ironic part... I'm a huge fan of Java the platform, just despise the culture of bloatware which has sprung up around it. The world is moving on to lightweight solutions which don't require app servers which generate stack traces so long that they span 3 screens.
livando 15y ago
With this article I was really hoping for some counter points of how JEE is doing some new and exciting things. Unfortunately, it looks like the only innovation was to throw some of the dead weight off the back of the truck. I can understand how corporate developers (i.e. can't use open source and it needs a support plan) would be happy about the lighter alternative approaches. I just don't see how given the whole technical landscape, that JEE is still a viable front runner.
- UK-AL 15y ago
  What? Jee is a open standard, there are open source and closed source implementations of that standard.... The idea being applications are portable between different vendors. If anything it's even more "open source" than most open source frameworks.
robfig 15y ago
Why would someone use J2EE or Spring over the Play Framework (which we use at work for our "mission critical enterprise applications")? Basically, what enterprise features am I missing out on by not using one of them?
- acerimmer 15y ago
  Exactly my thoughts, I can't think of any scenario where JEE is a better choice than Play.
- UK-AL 15y ago
  Java EE is a big hammer, it's got everything you could possibly ask for. You used to pay for this by requiring huge config files. Ejbs for example allow access from remote servers to objects as if they were local Objects. This can be used to separate out general application logic from the web, native application, web service interfaces which can be run on there own dedicated servers all communicating with the backend transparently via ejb. Any operations in a ejb are automatically transaction with the database. Ejbs used to be a configuration nightmare though, but not anymore. Java play is the get it done platform. They both have their uses.
mark_l_watson 15y ago
I used Java EE 6 a lot last year when I was helping a friend's company. Yes, it is a major improvement over JavaEE, especially JPA 2. I agree with the author of the article that Java EE 6 has a place for large mission critical applications. That said, I have had a good experience with two (admittedly small, and medium sized) Clojure + Compojure + Noir web apps: very stable, no apparent memory leaks so far, "just runs forever", etc. Java EE 6 is a great skill to have, job wise, but it is more fun using agile platforms.
shareme 15y ago
Now you know why I do not write articles for javacodegeeks.. This article is devoid of any dev value
francoisdevlin 15y ago
And this is why I use noir.
UK-AL 15y ago
JEE has improved, and I'm considering it over spring. Everything's annotation based compared to what jee used to be. Just use an annotation for a ejb, a persistence context, to get request any object you require via DI like a user service object for handling user profiles. Add a annotation and you've got your self a web service that implements rest etc
edwinnathaniel 15y ago
We recently delivered a big integration project using the best of both worlds. 1) Spring Portlet MVC - cause we have to deal with Portlet (don't ask) 2) JAX-RS client-side - Portlet talks to GlassFish via JAX-RS 3) JAX-RS server-side - GlassFish RESTful (this is probably one of the key feature for using JavaEE 6, a simple, straightforward, productive way to create APIs that can return XML or JSON or ATOM or ALL of them easily via annotation). JAX-RS is very similar to Sinatra. 4) JAX-WS client-side - to communicate with 3rd-party systems 5) JAX-WS server-side - to provide services for 3rd-party systems 6) Spring-Data - to reduce writing boilerplate JPA 2.x code (the way Spring Data works is as simple as writing an interface method where the method has the same name to the NamedQuery and Spring will automagically inject bytecode) 7) Spring library to read properties file - no need to write the actual implementation of a class that reads a property file and deal with IO exception abd opening/closing files try-catch-finally. Provide an interface and annotate the interface, set up minimal config and you're done. 8) Apache Derby to test the persistence layer for integration testing 9) Spring Web Test module - this provides HTTP Request/Response mock object so you don't have to construct your own Other libraries: 10) FlyWay - database migration library that integrates nicely with Spring as well. Flyway is executed when you deploy your EAR/WAR to your App Server container. 11) GSON - Java to JSON object converter written by someone from Google. We send JSON from our Portlet MVC to the front-end that is of a mix between JSP (5-10%) and heavy JS usage. 12) Dozer - Object to Object mapping, very useful if you have to deal with 3rd-party systems that have a subset or superset of your internal/local domain model. 13) Maven - we can build for multiple environment (DEV, UAT, PROD, STAGE, etc), it's easy. We are quite satisfied with the set-up and I have to say that if you come from Rails background, the only part of the stack that would make you a bit unhappy is the database ORM since ActiveRecord is probably nicer compare to the JPA 2.x/Hibernate/Spring-Data. We're not using EJB yet but we may use it in the future if we have to use queue via JMS as well. To my knowledge the latest EJB (3.1) helps you a lot to deal with transactional multi-steps operations that include persistence operations and JMS operations on one execution path. I'd say the code that we have to write is almost as short as Rails when it comes to the business logic part. Deployment was straight forward: package it up as WAR (or EAR) and deploy it to GlassFish. The part that we're lacking right now is the front-end. Even though we're not using JS _that_ heavy, we are moving toward that direction and eventually we have to clean it up and start using best-practices (Backbone.js, Underscore.js, and a few other things).
eccp 15y ago
Use none of them, try Grails or JRuby. Really.

44 points by markokocic 15y ago

JEE 6 is a huge leap forward compared to how J2EE used to be. However, there are a few problems. First of all, JSF is the most horrible framework for creating web applications that I've ever used. Its intention is to make web development easier, but what you get is a huge mess of HTML and JavaScript that introduces a lot of new problems. Escpecially since it gives you the impression that you don't need to know HTML and JavaScript to work with it. EJBs are a lot easier, and as long as you don't access them remotely, you don't need interfaces or XML files. If you put them remotely, you need both. With injection you don't need to look up EJBs manually, except if you put them remotely - because if the reference to the remote EJB is invalidated (i.e. if it's accessed while the remote server is down), you'll need to look it up manually again. As long as you choose something other than JSF, JEE 6 is fine. Of course, then there's the application servers. I've only tried Glassfish (for a while it was the only fully certified JEE 6 app server), but it had a few problems - I heard one of the latest versions had a GZip filter that would have spinning threads taking 100% CPU. JEE has come a long way, but I'll probably choose Spring for my next Java project.

deleted 15y ago
[deleted]
UK-AL 15y ago
I remember jsf having a bad rep however jsf2 is supposed to be not as bad.
edwinnathaniel 15y ago
JSF2 has definitely improved compare to the previous version but I suppose JSF (1/2) is more akin of ASP.NET (component oriented) which might put off a large number of developers who prefer simple templating with pure JS.

jfager 15y ago

Alternate title: Why I will stab my eye out with a fork instead of running a cheese grater over my knuckles.

moondowner 15y ago
Definitely. I'm perfectly happy with Spring. A developer can create the most lightweight web application with the most manageable code with Spring.
- Torn 15y ago
  Have you tried Play (playframework.org) yet?
  - rufugee 15y ago
    I have high hopes that Play will become the defacto "pragmatic" java/scala(/kotlin, when it's finally ready) framework. Play rocks.
    - eropple 15y ago
      I would dearly like to use Play, but I find it really uncomfortable (and not because I'm some stuck-in-my-ways Java developer). Play's heavy abuse of statics is a real problem from my perspective, in large part because it's extremely painful to write inheritance-based code; I realize it helps the simpler use case but I find that I don't regularly write to the simpler use case. I've gone back to Servlets+Guice+Velocity because it's easier for me to write expressive code.
  - moondowner 15y ago
    Yes I've tried it (pre Play 2), and there's one thing I don't like - favoring/integrating certain tools in it. I know that it uses Hibernate through the JPA API, and if you want to use a different ORM you'll have to make a lot of workarounds. And it's not only about ORM. A month or so ago I read that it will integrate a certain JavaScript library in it too. Tapestry Web Framework had this attitude, but the developers found that it brought more negative than positive effect, I hope Play will see the same. Modularity and ease of configuration is a very important thing. I like it's Scala support and enthusiasm though, and I will definitely try it some day again.

lebski88 15y ago

I'm exceeding unconvinced by this article. His plus points for JEE were really stretching: - Sustainability - do we really think Spring is going to die? - Light weight testing is possible - so JEE has caught up with spring... - Convention over configuration - like spring. - Multiple providers - OK that's a potential benefit but I'm not seeing the realisation of it yet. It could also mean that different providers have different bugs. From my personal investigations Spring offers many advantages. In some places JEE has matched them in others it's still behind. So I would ask myself do I want to go with the framework that's driving the advancement, or the framework that is playing catchup? Also these days Spring is the standard.

CodeMage 15y ago

The article is almost completely devoid of useful content. Basically the only useful argument is: JEE 6 has most of the stuff Spring has, it's "light" (lighter than J2EE) and, unlike Spring, it's a standard with several reference implementations. While the argument itself is worthy of discussion, there was no need to package it inside an article full of fluff. The author claims that she hopes to be neutral, but completely fails to do so when it comes to comparison of Spring and JEE: she lists advantages of JEE and then those of Spring, but makes sure that each of the Spring advantages listed is accompanied by a "BUT", which boils down to either "JEE has it too" or "JEE doesn't have it, but you probably won't need it". Yes, I know she said beforehand that she would explain why differences between Spring and JEE lead her to JEE, but the way she did it robs her of neutrality she claims to have. And it's not just the form I'm talking about, it's the substance, too. If all of your reasons to lean towards JEE boil down to "well, it has all that I need that Spring has and I personally don't care about the stuff it doesn't have", you're not really contributing anything.

astrodust 15y ago
Most Java programmers wouldn't know "light" if it fell on them and pinned them to the ground.
- UK-AL 15y ago
  As a java programmer I get offended by this. I was taught programming on scheme, I use django for quick apps, i know a variety programming paradigms but there is no one best tool to rule them all. Different tools are good for different jobs. For example scala programmers completely ignore backwards compatibility problems they have had in the past. Such a thing would unimaginable for a large app.
  - kaffiene 15y ago
    Yeah, me to. I've used Java for years without doing any Enterprise stuff, so to me Java has always just been a really good general purpose programming language that does OO a million percent better than C++ (from whence I came). When I had to do some web stuff with Java I recoiled in horror from the mess that all that old enterprise stuff was at the time - XML hell! I gave up and just wrote a servlet directly. What I'm leading to is that there is bloat in the Java space - that old EE stuff was god-awful, but extending this to say that everything in Java is bloated and over-engineered is offensive and ignorant. Some frameworks are heavy like old EE. Some frameworks are light like Play! There's nothing inherent in Java that means you can't have lightweight solutions. But bashing Java is cool on HN...

juliano_q 15y ago

This article only reinforced my conviction to use Spring and not JEE. It is possible to test on JEE? It is "light"? It have convention over configuration? Well, Spring has it for almost a decade, is trivial do deploy on any server and have much more powerful libraries. Furthermore, JSF is horrible.

thebluesky 15y ago

Friends don't let friends use either Spring or Java EE.

Sandman 15y ago
You've already expressed your disdain for both Spring and Java EE in several comments. However, I haven't noticed that you provided any arguments on why you think both of these solutions are bad. I'd be interested in hearing them.
- tbsdy 15y ago
  I second this. Please, put your money where your mouth is!
- codemonkeyland 15y ago
  I think he's simply stating what has made many Java programmers very cynical about frameworks such as these. Java EE layers abstraction on top of abstraction. App servers like WebSphere use a ton of memory before you've even deployed your app to the server and they charge you an arm and a leg (yes I know glassfish and jboss are free). Java code is verbose and ill-suited to crafting systems which generate html. The Java enterprise camp was championing the idea that web applications should have JSP talking to session beans, which talk to entity beans which then talks to your actual data store. By the time you've coded it all up you realise that it's slow before you've even added any business logic. Things have improved since then, but they lost my trust a long time ago. Spring seems to love having programmers take java source and translating it into XML so it's much more verbose than java (quite a feat in itself) and hides some of the most critical code from the IDE. The "benefits" provided by such approaches are marginal at best. The ironic part... I'm a huge fan of Java the platform, just despise the culture of bloatware which has sprung up around it. The world is moving on to lightweight solutions which don't require app servers which generate stack traces so long that they span 3 screens.

livando 15y ago

With this article I was really hoping for some counter points of how JEE is doing some new and exciting things. Unfortunately, it looks like the only innovation was to throw some of the dead weight off the back of the truck. I can understand how corporate developers (i.e. can't use open source and it needs a support plan) would be happy about the lighter alternative approaches. I just don't see how given the whole technical landscape, that JEE is still a viable front runner.

UK-AL 15y ago
What? Jee is a open standard, there are open source and closed source implementations of that standard.... The idea being applications are portable between different vendors. If anything it's even more "open source" than most open source frameworks.

robfig 15y ago

Why would someone use J2EE or Spring over the Play Framework (which we use at work for our "mission critical enterprise applications")? Basically, what enterprise features am I missing out on by not using one of them?

acerimmer 15y ago
Exactly my thoughts, I can't think of any scenario where JEE is a better choice than Play.
UK-AL 15y ago
Java EE is a big hammer, it's got everything you could possibly ask for. You used to pay for this by requiring huge config files. Ejbs for example allow access from remote servers to objects as if they were local Objects. This can be used to separate out general application logic from the web, native application, web service interfaces which can be run on there own dedicated servers all communicating with the backend transparently via ejb. Any operations in a ejb are automatically transaction with the database. Ejbs used to be a configuration nightmare though, but not anymore. Java play is the get it done platform. They both have their uses.

mark_l_watson 15y ago

I used Java EE 6 a lot last year when I was helping a friend's company. Yes, it is a major improvement over JavaEE, especially JPA 2. I agree with the author of the article that Java EE 6 has a place for large mission critical applications. That said, I have had a good experience with two (admittedly small, and medium sized) Clojure + Compojure + Noir web apps: very stable, no apparent memory leaks so far, "just runs forever", etc. Java EE 6 is a great skill to have, job wise, but it is more fun using agile platforms.

shareme 15y ago

Now you know why I do not write articles for javacodegeeks.. This article is devoid of any dev value

francoisdevlin 15y ago

And this is why I use noir.

UK-AL 15y ago

JEE has improved, and I'm considering it over spring. Everything's annotation based compared to what jee used to be. Just use an annotation for a ejb, a persistence context, to get request any object you require via DI like a user service object for handling user profiles. Add a annotation and you've got your self a web service that implements rest etc

edwinnathaniel 15y ago

We recently delivered a big integration project using the best of both worlds. 1) Spring Portlet MVC - cause we have to deal with Portlet (don't ask) 2) JAX-RS client-side - Portlet talks to GlassFish via JAX-RS 3) JAX-RS server-side - GlassFish RESTful (this is probably one of the key feature for using JavaEE 6, a simple, straightforward, productive way to create APIs that can return XML or JSON or ATOM or ALL of them easily via annotation). JAX-RS is very similar to Sinatra. 4) JAX-WS client-side - to communicate with 3rd-party systems 5) JAX-WS server-side - to provide services for 3rd-party systems 6) Spring-Data - to reduce writing boilerplate JPA 2.x code (the way Spring Data works is as simple as writing an interface method where the method has the same name to the NamedQuery and Spring will automagically inject bytecode) 7) Spring library to read properties file - no need to write the actual implementation of a class that reads a property file and deal with IO exception abd opening/closing files try-catch-finally. Provide an interface and annotate the interface, set up minimal config and you're done. 8) Apache Derby to test the persistence layer for integration testing 9) Spring Web Test module - this provides HTTP Request/Response mock object so you don't have to construct your own Other libraries: 10) FlyWay - database migration library that integrates nicely with Spring as well. Flyway is executed when you deploy your EAR/WAR to your App Server container. 11) GSON - Java to JSON object converter written by someone from Google. We send JSON from our Portlet MVC to the front-end that is of a mix between JSP (5-10%) and heavy JS usage. 12) Dozer - Object to Object mapping, very useful if you have to deal with 3rd-party systems that have a subset or superset of your internal/local domain model. 13) Maven - we can build for multiple environment (DEV, UAT, PROD, STAGE, etc), it's easy. We are quite satisfied with the set-up and I have to say that if you come from Rails background, the only part of the stack that would make you a bit unhappy is the database ORM since ActiveRecord is probably nicer compare to the JPA 2.x/Hibernate/Spring-Data. We're not using EJB yet but we may use it in the future if we have to use queue via JMS as well. To my knowledge the latest EJB (3.1) helps you a lot to deal with transactional multi-steps operations that include persistence operations and JMS operations on one execution path. I'd say the code that we have to write is almost as short as Rails when it comes to the business logic part. Deployment was straight forward: package it up as WAR (or EAR) and deploy it to GlassFish. The part that we're lacking right now is the front-end. Even though we're not using JS _that_ heavy, we are moving toward that direction and eventually we have to clean it up and start using best-practices (Backbone.js, Underscore.js, and a few other things).

eccp 15y ago

Use none of them, try Grails or JRuby. Really.