Kai WaehnerThe question comes up often. It came up in my new project in November 2011, too. I will use Java EE (JEE) instead of the Spring framework in this new Enterprise Java project.
I know: Several articles, blogs and forum discussions are available regarding this topic. Why is there a need for one more? Because many blogs talk about older versions of Java EE or because they are not neutral (I hope to be neutral). And because many people still think thank EJBs are heavy! And because the time has changed: It is Java EE 6 time now, J2EE is dead. Finally! Finally, because not only JEE 6 is available, but also several application servers (not just Glassfish as reference implementation). I do not want to start a flame war (too many exist already), I just want to describe my personal opinion of the JEE vs. Spring „fight“…
Therefore, I think it is very important to start with a short overview and history of both alternatives. Afterwards, I will list the differences of both and explain why these differences lead me to JEE instead of Spring for most new Java projects. I am explicitly talking about new applications. If you have to extend an existing application, continue using the existing framework!
One more disclaimer: I am talking about mission-critical Enterprise Java applications. I am not talking about a little internal application or other uncritical stuff. I also would prefer using a combination of Scala, Groovy and Clojure persisting to a NoSQL database while being deployed at a PaaS cloud service such as JBoss OpenShift or VMware CloudFoundry…
General Information about JEE and Spring
First, I want to summarize some general information about JEE and Spring:
- In the end, both alternatives consist of several libraries which can be used by developers to create enterprise applications.
- Both can be used in most use cases, they have very similar functionality (business logic, transactions, web-frameworks, whatever…) – they only differ in realization (e.g. declarative transactions in Spring vs. conventions in JEE).
- You also can use only one or some of the available libraries. You can even combine JEE and Spring stuff.
- Usually, the crucial question is: „Should I use JEE (i.e. especially EJB, JPA, CDI, etc.) or the Spring core framework (i.e. especially Spring Application Context, Spring beans, etc.) for realizing my new application? Mostly, you can choose both, it does not matter from the point of view of the end user. But you should not merge both, this only creates higher complexity.
- There always was a debate about which alternative to choose. It is very difficult to discuss this question in a neutral way. That’s why almost all discussions end up in praising one framework and bashing the other one (I hope to be neutral in this blog post).
History: J2EE was horrible, so Spring helped!
J2EE was horrible. So much XML configuration, so many interfaces, and so lame application servers. This is why the Spring framework was created. It solved many problems of J2EE. It was lightweight, easy to use, and applications could be deployed in a web container (such as Tomcat) instead of a heavy J2EE application server. Deployment took seconds instead of 15 minutes. Unfortunately, JRebel did not exist at that time. The Spring framework is no standard as J2EE, nevertheless it became very widespread and an large community arose.
Today: J2EE is dead. JEE „stole“ the lightweight Spring ideas!
Everything started with a little shortcut change. J2EE was dead. The new shortcut was JEE. JEE 5 was born in 2006. It „stole“ many good, lightweight ideas such as „convention over configuration“ or „dependency injection“ from Spring and other frameworks. Yes, JEE application servers still were heavy, and testing was almost impossible. Nevertheless, developing JEE applications was fun with JEE 5. You did not have to write 20 interfaces when creating an EJB. Wow, amazing!
Then, in 2009, JEE 6 was released. Development is so easy. Finally! For example, you have to add only one annotation and your EJB is ready! Of course, the developers of the Spring framework did not sleep. Much new stuff was added. Today, you can create a Spring application without any one XML file as I have read in a „No Fluff Just Stuff“ article some weeks ago. Besides, several really cool frameworks were added to the Spring stack, e.g. Spring Integration, Spring Batch or Spring Roo.
Today (November, 2011), both JEE and Spring are very widespread and have a large community. Much information is available for both, e.g. books, blogs, tutorials, etc.
So, after I have described the evolution of JEE and Spring, why will I use JEE in most new Java projects?
Pros and Cons of JEE and Spring
A decision must be made. Which alternative to use in new projects? Let’s look at the pros and cons of both. I will add a „BUT“ to the Spring advantages – these „BUTs“ are the reason why I prefer JEE to Spring.
Advantages of JEE
- JEE is a set of standard specifications, thus it is vendor-independent. Usually, several implementations exist of a specification.
- Sustainability: Well, this is the advantage of a standard which is supported by several big players.
- Yes, believe it or not, testing is possible! Lightweight application servers and frameworks such as Arquillian arrived in the JEE world!
- Convention over Configuration is everywhere instead of explicit (I know that some people will disagree that this is an advantage).
Advantages of Spring
- You do not need a heavy JEE application server, you can deploy your application in a web container such as Tomcat.
BUT: JEE application servers are not as heavy as they were some years ago. Besides, the JEE web profile can be used, too. You do not have to use a Tomcat or Jetty to be lightweight!
- Spring offers features which are not available as JEE standards, such as Spring Batch.
BUT: You can add such a library to a JEE project without problems. You can also add other Spring libraries such as JDBCTemplate or JMSTemplate (which help reducing some boilerplate code) if you want.
- Spring offers much more flexiblity and power, e.g. aspect-oriented programming is more powerful than JEE interceptors.
BUT: In most projects you do not need this flexibility or power. If you do need it, then use Spring, not JEE – of course!
- Faster Releases (because it is no standard and only one vendor). The reaction to market requirements is much faster. Some current examples: cloud, mobile, social computing.
BUT: All enterprise projects – of many different clients – which I have seen, are not that flexible. Enterprise applications do not change every month or year. If there is a project, where you can change your version very easily, Spring might be better than JEE under some circumstances. But in most enterprise projects, you cannot simply upgrade from Spring 2.5 to Spring 3.x or from JEE 5 to JEE 6. I wish this would be possible, but low flexibility and politics rule in large companies with thousands of employees.
Conclusion: I will use JEE in most new Enterprise Java Projects
Due to the reasons I explained against Spring in the „BUT“ parts, I will choose JEE in most new Enterprise Java projects. Nevertheless, I will sometimes use a Spring libraries, too (such as Spring Batch). Sometimes, I will even have to use Spring (if I need its flexibility or power), but only then I will choose it. Of course, for existing projects, I will continue using the framework that is used already. I would probably not migrate a Spring 2.5 application to JEE, but I would migrate it to Spring 3.x instead!
So, I have described my reasons why I will use JEE in most new Enterprise Java projects. If I have missed something, or if you have got another opinion (probably many guys have), you can bash me in the comments. I appreciate all „non-flame-war“ discussions…
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
52 comments
This is the answer to many questions. I agree with you!
I agree with everything you said. But spring has a great autentication and authorisation framework (old acergy) integrated. And its help us a lot. JEE has something like that?
Hey Daniel.
Spring Security may be one of the features which is more powerful than the JEE standard. In our last projects we had to implement low-level LDAP or NTLM integration for some reasons. Usually, we use the Atlassian stack (Jira, Confluence, Crowd) whenever possible because IMO Atlassian makes awesome easy-to-use products for a fair price. Crowd is used for Single-Sign On.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Thanks for writing this up.
Even though you concluded with JEE, seems like a pretty even fight. I think developer experience will probably sway the vote in most EE environments. Dev. teams are probably even harder to switch then frameworks.
@Danny:
You are absolutely right! The “fight” will not end, because you can realize most applications with both alternatives. I also know developers who prefer Spring. Of course, developer experience is important, too.
Though, the trend goes in the direction of JEE (in my opinion). In a while, there will be much more JEE developers than Spring developers available. One reason is that all guys coming from universities will learn the lightweight standard and there is no reason to learn Spring at the university anymore (contrary to J2EE times, where Enterprise Java was too complex to solve problems quickly).
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Isn’t Oracle the Vendor who controls JEE? Sure they maybe a commitiee but isn’t certfication only possible from Oracle?
I would also argue that as SPRING can do what JEE can do, then it comes down to where the most developers are at. And there are more that have learned SPRING than JEE. Agreed that is due to the legacy days of J2EE, but that is the way it is.
Also what about using TomEE?
http://jaxenter.com/tomee-be-small-be-certified-be-tomcat-38434.html
Using SPRING with this you get the best of both worlds no?
Hi,
I think a comparison between JEE and Spring for the sake of comparison has no real value. I support the approach of using the minimum libraries you need for the project as you need them, and not decide in advance to go all-JEE or all-Spring.
You should first start (at least in your mind) with a main() method, and ask yourself what else you need: DB access? REST endpoints? Transactions? Then pick the tools that you think fit best for your specific needs. You may end up deciding that you don’t need JEE/Spring, or even a web container at all. For example you can do amazing stuff with Guice.
JEE containers may be a lot better today than J2EE, but that doesn’t mean you should use one if you don’t get a real benefit from it over the alternatives. As for the specific JSRs, you may or may not use each of them in your project (some JSRs are also supported by Spring), but that too shouldn’t necessarily lead to all-JEE architecture.
Personally I agree that the more flexibility you need, the better you choose Spring and other open source libraries. If you stick to JEE, you may need to wait for years to get features that are available today in such libraries.
@Gabriel:
As I have stated at the beginning of the article, I had to choose between JEE and Spring for future projects – I did not say that I wanted to choose 🙂
In theory, your suggestion may be possible. Also in some companies, this may be possible.
In practice, best-of-breed is not possible in many large companies. Politics and other keywords such as “technology consolidation”, “know-how transfer”, and so on prohibit your suggested approach.
I have seen this in several companies – and often it is not a bad idea IMO. My company also does Enterprise Architecture Management. There are so many application silos with different technologies, and the people with know-how already left. 🙁
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
@LazyFan:
Well, you could use TomEE and combine Spring with JEE. But why would you do that? IMO, it would only increase complexity. If you want to use Spring, you should use its tc Server (and buy support for this server). If you combine Spring and JEE, you have to buy support for both, as Adam Bien stated some months ago in a blog:
http://www.adam-bien.com/roller/abien/entry/java_ee_6_xor_spring
You may argue that you do not need that support, but in mission-critical systems, this support is necessary.
I am no expert in this TCK certification stuff, but many other vendors made the certification for JEE in the past.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Hi Kai! It’s not bad to have a bias in this discussion. If view points don’t differ then where is the value add in discussion. Seriously, I believe you have a strong JEE bias (you only have the “buts” against the Spring option) and you explain why. Again, that’s OK and its the only way I see to add value here.
I do agree to many points you mention. To me its not a matter of features to be honest in the end ’cause features are well sorted in both architectural options. It’s also not a question of “heavy weght” or so. In the end (to me) it’s a decision where you want to place your framework libs: in the server lib directories or with the WAR/EAR file in WEB-INF/lib. Now what’s the consequence: if you have all the stuff in the server lib and you use those APIs directly then
(1) migrating JEE servers will become non-trivial due to the migration and testing efforts associated
(2) therefore not all the clients want to migrate cause they don’t see a reason -> result: multiple JEE server versions in IT landscape, multiple local dev env versions due to different Java versions in production, more complex ALM solutions – all in all: more complexity and more heterogeneous landscape
(3) shift of responsibility: in Spring scenario the development or application architecture guys decide what to use und also have the knowledge to fix problems in production. in a JEE case the operations team is in charge of the application framework libs, they typically don’t have the knowledge and need vendor support
(4) less flexibility: e.g. you need to talk to procurement guys before you can add a new framework feature of a new server version (licensing costs), or e.g. you need to talk to operations team to upgrade. as with Spring you just compile a new version of your WAR/EAR file and deploy that to a java runtime of your choice
(5) snowball-effect: you need one feature but ’cause the app server you’re using (and in JEE you’re not the only stakeholder that can decide which server to use!) doesn’t have that feature you need to upgrade. Ups, you need to migrate and retest all your application ’cause all the API versions changed!
Now, all in all I think I do have a strong Spring bias. As soon there is a solution to these extensive problems I will change my mind ’cause obviously my live would be much easier if I could just say: we use the JCP “standard” programming model. Unfortunately, this is not the case right now.
Also, I do believe it’s not JEE against Spring, it’s CDI vs. Spring IoC in particular and its also about like EJB or not. Also, it’s a lot about independence of your business applications from the underlying application server runtime. E.g. we use EJB but the business app doen’t know it. The key to platform independence is not using either Java EE or Spring but making sound decisions which APIs to use directly in your business apps. And sometimes its better not to use some app server lib dir derived ones 😉
JEE is moving towards a good direction. More modularity (as a standard) would be desireable to make it more applicable to complex and large IT environments.
Cheers, Niklas
All comparisons between JEE and Spring i have seen were biaised and not serious.
A good comparison should involve every single module/package of the spring framework. And explain how you do it with pure JEE.
A lot of third libraries offer a spring namespace extension. Will it be simpler with JEE only ? For exemple : BPM, ESB, nosql databases (all the spring-data-* stuff) …
And what are “entreprise java projects” ? Is it webapps … or complex integration systems ?
And today we have cloud platforms. Do you want to use them NOW, or wait for java EE 7/8 ?
So what happened to all the new ideas of spring which come with Spring 3.1. The Spring Data and Cloudfoundary efforts (agreed that you can integrate things around, but then who is to stop you from integrating things with .NET or RoR then)
The It seems that you are comparing stolen_from_spring_of_yesterday_framework to spring_of_yesterday. I am not so clear about standards.
I think standard is some thing which is widely used and spring beats JavaEE in 2011 IMO.
@Kai
Yes I totally agree on support. TomEE+ is very new and will no doubt get support. As we know Tomcat already has support from not only Spring Source but Mulesoft as well. And your article was about 2012. I think you will find that it will get that commercial support in 2012
Let us say you need Spring feature X, well just use it. TomEE+ is clearly the future. Which I think you will find is 2012 as per your article.
Also as a side note I am assuming Oracle control the certification for JEE. And so far, they have been reasonable. So, far! Let us suppose they get heavy with say your JEE container (Larry is already in an official War with IBM on hardware) get it black listed. Now you will have to move or you could just swap to Spring in TomEE+.
I lol’d @ “stolen_from_spring_of_yesterday_framework to spring_of_yesterday”
So true. We should have respect for Jurgen Hoeller and Rod Johnson’s work. Through spring, they’ve popularized so many concepts and patterns …
For people interested in an approach of migrating your Spring legacy apps towards Java EE, have a look at our JavaOne talk “Best Practices for Migrating Spring application to Java EE 6” on slideshare: http://www.slideshare.net/ertmanb/javaone-2011-migrating-spring-applications-to-java-ee-6
Both of these:
EE is a set of standard specifications, thus it is vendor-independent. Usually, several implementations exist of a specification.
Sustainability: Well, this is the advantage of a standard which is supported by several big players.
These are very weak Pros IMO. Spring is not vendor specific either. I also think there are many big players supporting spring as well.
From a dev point of view I would much rather work with spring than JEE, and drawing good devs and keeping them working efficiently and happily will determine your project’s success or failure much more than the JEE vs Spring decision.
I recently worked on a project whose architect choose JEE just for the reasons you mentioned. The project failured under the bloat and dissatisfaction of devs wanting to work efficiently but just couldnt with JEE being the bloat it is.
Spring is not just one library, it’s a full software stack, so what are the real alternative stacks on the JEE side you are suggesting?
IBM WebSphere, Oracle Weblogic, SAP NetWeaver – not free.
GlassFish? Oracle killed most of it’s ecosystem: OpenSSO, OpenMQ, OpenESB, SailFin. And after merging with WebLogic, it’s quite obvious it will be more like Oracle’s “Express Editon”.
Geronimo? More like a mix of other Apache projects. Not really popular in enterprise or elsewhere.
JBoss? Yes. Real alternative. The only one. So isn’t it more about JBoss 7 vs Spring for ones without IBM/Oracle/SAP(usually stuck on old versions with EJB2)?
I was just thinking about “When do you need a JEE container” … and came across this blog post.
I know the answer is, you want to write a JEE app … but that leads to when do you want to write a JEE app .. and then to this blog post … my question came from a dev manager who wants to switch his unit from Weblogic to JBoss for cost savings, but then asked me why they can’t just use tomcat (like we had done at a previous company) … and I think the author is right, corporates are going to pay for JEE servers, and if you have a JEE server all the for/against arguments about spring/jee are close to valid … if a little biased
This kind of begs the question: just what is an _enterprise_ java project? i.e. when JEE is required. In my experience, the motivation seems to be mostly related to (transactional) messaging/JMS integration and JTA (or perhaps JTA transactions across multiple data stores).
Thought I’d mention that if you end up using Groovy and Grails comes along for the ride, then you’ve already adopted Spring.
I also wonder if you’re targeting PaaS would you still use JEE?
Hey Steven,
IMO, an “Enterprise Java Project” is a medium to large project which solves core business problems. It is in production for several years, versions cannot be changed instantly due to high complexity and large code basis. On the contrary, internal projects (e.g. for evaluation, proof of concept, some cool but not required core functionality) are no enterprise projects.
Of course, you do not always have to use Java EE (including an application server) in such projects, often Java SE or the integration of one or two Java EE APIs is sufficient.
I agree: Java EE ‘s main motivation is transactions and IMO easy thread management.
I do not have a problem using Spring libraries, even in combination with Java EE. Though, I would probably use JSF instead of Grails when using a Java EE application server due to its better integration into other Java EE APIs such as CDI or JPA (and not because Grails depends on Spring libraries).
Finally, yes, I would also prefer Java EE for PaaS! I think there is no difference… I have looked at both alternatives a little bit, e.g. VMware Cloud Foundry (Spring) and JBoss OpenShift (Java EE). Both are not production ready yet, but I would prefer a Java EE PaaS for same reasons as in an own hosted solution.
Thanks for your perspective Kai. I’ve just started evaluating Cloud/PaaS offerings (particularly for Java apps but also more broadly). Good to know that you don’t think either Cloud Foundry or OpenShift are production-ready yet. Others I’m looking into are Heroku, CloudBees, Amazon AWS, Google App Engine and Microsoft Azure.
What I understood reading your article is that you have never gone so far to use the advantages of Spring framework.
If you think about modularity, library switching (just because you don’t want to use that 4.1 crappy XX version) as well as testing (did you really used Arquilian in a large enterprise project?), Spring is THE only viable way, in my point of view, JEE is like using cathedral stones to build a castel.
So far so good, you have to spend more time on the elaboration of a Spring stack, spending your nigths reading documentation and elaborating POCs, and need more knowledge about the underlying libraries, is it really evil?
What I understood reading your article is that you have never gone so far to use the advantages of Spring framework.
If you think about modularity, library switching (just because you don’t want to use that 4.1 crappy XX version) as well as testing (did you really used Arquilian in a large enterprise project?), Spring is the only viable way. In my point of view, JEE is like using a built cathedral stones to build a castel.
So far so good, you have to spend more time on the elaboration of a Spring stack, spending your nights reading documentation and elaborating POCs, and need more knowledge about the underlying libraries, is it really evil?
Kai, please note, there is nothing named “JEE”. The correct name is “Java EE”. Thanks.
Bill Shannon
Java EE Spec Lead
JEE6 is a worthy alternative to Spring in the specific scenario cited (clarity over support if the customer has already invested in a JEE app server) but in most large corporate environments they prefer to stay 1 major release behind the latest and won’t be going with a JEE6 compatible WebSphere v8 or whatever any time soon. So, if the choice is between JEE5 and Spring as it is in reality in most cases right now then there is really no contest – Spring wins. Sooner or later though, JEE6 is going to win out, its inevitable, so start using JEE JSRs (e.g. 299) wherever supported by Spring today. BTW if it wasn’t for Spring, Java would be long dead. J2EE was awful and too many got burnt by it.
I would chose spring, and here is why.
http://www.vmware.com/company/news/releases/vmw-spring-momentum-3-14-12.html
I’m currently using Tomcat 7 + SpringMVC + freemarker + OpenEJB 3.1.4 Stand Alone + OpenJPA 1.2 i find it flexible, fast do develop and setup and ease of use with Eclipse.
I just will guys will continue separate branch for OpenEJB Standalone (not in Tomee) and will keep it simple.
I’m currently using Tomcat 7 + SpringMVC + freemarker + OpenEJB 3.1.4 Stand Alone + OpenJPA 1.2 i find it flexible, fast to develop and setup and ease of use with Eclipse.
I just wish guys will continue separate branch for OpenEJB Standalone (not in TomEE) and will keep its simplicity.
Very nice article. However your four pro Jee arguments are quite debatable:
1. Standard? Spring is a defacto standard, and has emerged as the standard. The vendor-independence is a good argument (for the future if they emerge.)
2. Sustainability: Spring is is higher use, so this point is even.
3. Testing is possible? Really? How is that an argument for Jee?
4. Convention over configuration is available (and already being done in frameworks like Grails, which runs Spring+Hibernate).
I don’t see any valid points, other than everyone jumping on the bandwagon. That is the best argument as far as I can tell. The industry does not always choose the best alternative.
Jee remains a subset of Spring + Hibernate. Personally I’m still waiting for a good reason to switch to Jee.
IMHO the argument for Grails is strongest, since history favors developer productivity.
Code faster in a Java-compatible, next generation language while preserving seem-less integration to legacy Java code? Now that makes sense to dollar-starved CEO’s! And Java developers find Groovy is fun!
Hey Eric, thanks for your feedback.
The great thing about the Java platform is that everybody can choose from a lot of alternatives. So, you can create awesome enterprise applications with both, JavaEE or Spring. In the end, you and me are both happy.
I agree to your Groovy comment, too! Probably, many developers do not use Groovy in projects due to policital reasons. 🙁
Why still Java?
What about Play! with Scala and Akka?
JavaEE Jboss 7.1 is great, You can easily turn an EJB 3.1 into SOAP Service by adding “@WebService” in the class level. And its so fast in startup, deployment and stopping the server. No need to add too many jar files its all in Jboss.
With Jboss 7.1, instantly you can consume the SOAP services into C# and Java client.
For the Backend i will go for JavaEE EJB 3.1 and SOAP WS
It’s great that you included some practical arguments in your decision. You are right that large, enterprise apps rarely change – you really do not need a ton of flexibility in most cases.
Another argument: When those large companies are staffing their projects, it will alwayts be easier to find programmers with JavaEE skills as opposed to programmers with JavaEE + other proprietary frameworks (spring, hib, struts, etc..). The JavaEE code will tend to be more stable, too – it will be easier to maintain throughout the shelf life of the app.
easy:
i will use Spring when the enterprise not have $$$ for a roboust web server, other hand i use JEE6
Thank you for the article, it is very nice summary. I hope I am not redundant as there is so many comments, BUT BUT you really didn’t try to be neutral :). I still prefer Spring because I disagree with statements like “you do not need such power”. Although JEE is a nice way to go and I definitely will try that. Cheers
@DanielDom, I don’t understand your point.
Is not Glassfish a robust Web Server?
Is not JBoss a robust Web Server?
Arquillan is not part of JEE and testing, even with Arquillan, is possible in Spring so this is not a “pro” for JEE at all. Your sustainability argument is simply a rehash of “it’s a standard”. So basically the JEE “pros” are that it is a standard and convention over configuration. I don’t really buy “it’s a standard” as an argument with much merit on it’s own, but convention over configuration is something worth discussing.
I’ve been reading a lot of this debate between JEE and Spring lately as I’m trying to decide what direction to take on a new project. Unfortunately the vast majority of the articles I’ve read, some of them published by Oracle employees, are devoid of content and present absolutely nothing of merit. Your article is the best so far, the most reasonable, sane and rational, kudos for that.
The problem for me is this JEE vs Spring argument seems irrelevant on it’s face. Spring is a framework built to use JEE technologies and fill gaps where necessary. I’ve been using Spring, Spring Web MVC, Shiro, JPA and JTA on a project for a few years. Of course Web MVC relies on JSP, JSTL and Servlet which are all JEE technologies along with JPA and JTA, and they all run in any JEE 6 certified application server.
So how does that fit into a Spring vs JEE argument? It doesn’t, there’s pieces of each. It’d be far more useful to debate Spring Core and CDI, or Spring Web MVC and JSF with EJB. That’s where it gets really interesting, especially if you for example decide that you prefer CDI to Spring Core and prefer Spring Web MVC to JSF/EJB. What implications does that have, can you use Spring Web MVC with CDI?
People like Arun Gupta comparing FILE SIZES is just a laughable joke. How obscenely out of touch, how far from reality must you be to believe that has any relevance. All these turd piles are making it really hard to find any USEFUL information comparing Spring technologies and JEE technologies.
“JEE is a set of standard specifications, thus it is vendor-independent”
I am afraid I can’t agree with that. JEE is a set of standard specifications, and a set of not so standard ones.
Some of the specifications have changed so many times, so deeply … and backwards compatibility has been ignored in such a way that they cand hardly be considered standards. That’s the case of EJB, for example. The cuestion is, can I be sure that future versions of JEE wil be compatible with JEE 6? Will it be easy to migrate form a JEE 6 server to a JEE7 one?
On the other hand, while specifications are valid for al vendor implementations, vendor specific extensions are what make this implementations great (JSF is probably the best example). Using a JEE server, forces me to choose specific vendors for several specification: ie if I choose JBoss server, I am forced to use hibernate + richfaces. What if I want to use a different combination? What if I want to use a different hibernate version to solve some bug? I find it easier changing a war than waiting for a new server version.
But filesizes do matter – the are a rough measurement of the thickness of your stack – but not an absolute measurement.
Absolute measurement can easily be made by creating an invalid access against your favorite db layer tool. You’ll propably get about 100 – 200 levels of “stack” to your exception. Each level representing actual functional code your application has gone tru, before running into your exceptional code.
So, thickness matters.
Hello Kai,
This blog really helped me in clearing the confusion about Spring framework. Thank you very much.
By the way, How can I follow your blog posts, is there any subscription required?
Thanks,
Chandra.
Hi Chandra,
thank you. I think there is no subscription available (I have to check this out in the future. Probably, WordPress offers this functionality). In the meantime you can follow me on Twitter or connect via LinkedIn or Xing to see new blog posts.
Kai
Hi Kai,
This article post on 3 years ago , what your opinion now Kai ? Are you still love your decision ?
Well, the article is just one year and three months old 🙂 My opinion did not change. I still think that you can solve most problems with Spring or Java EE. However, I still recommend Java EE in most use cases…
Kai,
Would you reccomend Java EE (including JSF) for a medium to large ecommerce application… I hear issues with JSF (page bookmarking, large memory footprint with sessions due to state keeping etc).. however not sure these are all old issues already addressed in JSF 2.0/Java EE… .
Our team is mostly experienced in small to medium internal applications on JSF1.2/J2EE stack… trying to decide which would be better option for us Spring or Java EE in the long run…since majority of our new project is going to be work effort on the presentation layer, presentation framework is a key concern (JSF vs Spring MVC )… thoughts?
Jo,
first, I think every web framework has advantages and disadvantages. However, I think the problems you are talking about are old issues.
Definitely, my answer is yes, I recommend JSF 2.x! There are many other great web frameworks available on the Java platform. However, if your team has experience with J2EE / JSF 1.2, then I would not think about using another framework. Getting started is much easier, and (as JSF 1.2 user), you will love JSF 2.0…
By the way, JSF (and Spring MVC) are a very good fit for (public) ecommerce web applications, compared to GWT, Vaadin, etc., because you have full (and easy) control over your presentation layer. The latter are great for internal applications where you want quick results, but in your case I think JSF 2.x is perfect.
Thanks Kai… appreciate your feedback..
Nice article.
Jo, may I humbly throw in my 5 cents: migrate to JSF2, have a look at Seam3 (www.seamframework.org) and than at Apache Deltaspike – which is a synergy of Seam3+CODI MyFaces+Spring.
As JSF2 already in the market have a look at RichFaces, IceFaces and my favorite Primefaces (www.primefaces.org).
For the bookmarking, enjoy the ocpsofts prettyfaces.
We still use struts2, but agressively moving on a “it just works” tool-chain: Seam3 (CDI, etc.) + Primefaces (JSF2) – and enjoying it greately!
No more struts2 and JSF1.x!
I think Spring gives you much more flexibility, like you can wire stuff together to create the application framework that best suits your needs. You can leverage from better APIs and libraries out there, but with JEE you are kind of stuck with what is available. There is no doubt that your deployments are a lot lighter in JEE. But you may not need what is available on your JEE server. I had issues with JEE servers, especially around classloading and deploying applications that use different versions of the same specification or api. Whereas in spring you can bundle it all together with isolated classloaders. OSGi now kind of address this problem.
In my company, old developers had created a framework for a Java EE project in 2005. In this project, we are using our own dispatch servlet, our own controller and view layer (jsp files) in the project. I am one of latter developers of this system. So I don’t understand why we don’t use Spring in our project. We live in 2013 now. We are migrating the project into another framework which is very similar to old one. We’re just changing view layer and the way of its communicate. The view will work on totally in client with Jquery, and it sends just ajax calls to dispatch servlet. We didn’t touch much to business layer. I am not sure whether it is the true way or not.
Seval U does not realize that he is using the MVC pattern. The MVC pattern is the true way of doing the web tier, whether you implement it in spring, faces etc.
@admin, according to the well known site Indeed.com job trends (http://www.indeed.com/jobtrends?q=groovy%2C+java%2C+c%23%2C+php%2C+python&l=&relative=1) I cannot find a faster growing general purpose programming language than Groovy over the past 5 years.
Once you code in Groovy, Java becomes painful.
But back to this blog: it is useless as input into a decision regarding Spring persistence vs JPA. I am un-subscribing.
What matters to users is cost. So where are the numbers? The highest cost is developers.
Which option is more productive to develop, test and maintain? How many talented developers are available with existing knowledge? Are there significant performance differences?
This blog does not provide any proof, just “arm waving”. Show me a compelling argument, like data from independently funded studies.
Otherwise this is just useless bickering.
JavaEE for “object and connection pooling” max use of resources for business code also available as webservice for various client apps. I use SpringMVC + freemarker for UI.