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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
[+] [-] CodeMage|14 years ago|reply
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|14 years ago|reply
[+] [-] edwinnathaniel|14 years ago|reply
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).
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] vetler|14 years ago|reply
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.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] edwinnathaniel|14 years ago|reply
[+] [-] UK-AL|14 years ago|reply
[+] [-] lebski88|14 years ago|reply
- 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.
[+] [-] jfager|14 years ago|reply
[+] [-] moondowner|14 years ago|reply
[+] [-] thebluesky|14 years ago|reply
[+] [-] robfig|14 years ago|reply
Basically, what enterprise features am I missing out on by not using one of them?
[+] [-] UK-AL|14 years ago|reply
Java play is the get it done platform.
They both have their uses.
[+] [-] acerimmer|14 years ago|reply
[+] [-] livando|14 years ago|reply
[+] [-] UK-AL|14 years ago|reply
[+] [-] juliano_q|14 years ago|reply
[+] [-] mark_l_watson|14 years ago|reply
Java EE 6 is a great skill to have, job wise, but it is more fun using agile platforms.
[+] [-] UK-AL|14 years ago|reply
[+] [-] thebluesky|14 years ago|reply
[+] [-] Sandman|14 years ago|reply
[+] [-] eccp|14 years ago|reply
[+] [-] francoisdevlin|14 years ago|reply
[+] [-] shareme|14 years ago|reply
This article is devoid of any dev value