Discussions

News: Why Should We Dump JEE Standard?

  1. Why Should We Dump JEE Standard? (9 messages)

    Prologue

    I never thought that I have to write about this topic again, but I have to since a couple months ago I have to justify a decision of using Spring Framework in an enterprise environment. The decision to be made was whether we are going for JEE or using Spring Framework. The constraint was very clear:

    • We need to support both batch and web apps.
    • For web apps we only can use an old OAS (Oracle Application Server) with JEE 1.4.
    • Commercial support has to be available for the framework and the runtime environment.
    • We are going to update the app server for JEE 6 or 7 soon, so it should be possible to have a smooth migration.
    • We would like to minimize the use of our home grown frameworks.

    Still there was such a quarrel in the team because there are already some JEE web apps run in OAS upgraded with JBoss Weld CDI 1.0. Normally JBoss Weld 1.0 won't run out of the box in OAS but with some patches we got it run. The problem with all those web apps is we had a lot of our own CDI extensions to fulfill enterprise features (declarative transaction management for services, caching, security) which already a part of Spring Framework a long time ago.

    So it's time to google this topic "JEE vs. Spring Framework" to see whether the dispute between them still exists.

    Spring Framework Bashing 2012 and 2013

    I found in Google a lot of Spring Framework bashing in years 2012 and 2013. There are some of blogs and articles saying that with the existence of JEE - especially JEE 7 - we don't need or should avoid Spring Framework. One of the most controversial article is this one: Why is Java EE 6 better than Spring? Luckily there are also some counter parts like this one: Java EE a tough sell for Spring framework users and this one Java EE vs Spring. Or: What is a standard?

    So the topic is still hot!

    Base on these discussions I need to make my own picture so let's get the two important aspects of enterprise application development: programming models and runtime environments.

    ...

    To conclude: the umbrella JEE specification which contains all those APIs also makes everything more complex and makes update to a newer version of APIs very slow. 

    ...

    Epilogue

    In my opinion the enterprise development in Java has to go in the direction above:

    • Drop the umbrella standard JEE.
    • Concentrate on one and only one runtime environment specification, the Servlet specification.
    • Concentrate on APIs standardization like JPA, JTA, JMS, CDI, Batch and others and make them loosely coupled. Let the version of the APIs to be used mixed and matched.
    • Use the standard dependency mechanism of Java to include the implementations within the web and batch apps.
    • Don't forget the Security APIs, just copy them from Spring Security analog to Batch APIs using Spring Batch.

    So at the end as an end user we have one and only one runtime environment (container). The rest is just standardized APIs (JPA, JMS, CDI, Batch, Security) with their implementations (Hibernate, ActiveMQ, Spring DI, JBoss Weld, Spring Batch, Spring Security) which can be used mixed and matched as you need them. With this style you can update the version of particular specification without having to update the whole runtime environment and all the APIs in one step. A new developed app can use the up-to-date APIs and their implementations. Update of older web and batch apps can be planned carefully without the need to update all the apps at once.

    The full story can be found here: http://lofidewanto.blogspot.de/2014/06/why-should-we-dump-jee-standard.html


     

    Threaded Messages (9)

  2. Misses the mark[ Go to top ]

    Reza Rahman is already doing a good job debunking a lot of what the article talks about over on DZone: http://java.dzone.com/articles/why-should-we-dump-java-ee.

  3. Thanks Ulf. Yup, Reza can always be trusted to lead the charge of the Java EE brigade. I threw my two cents worth in over there myself. My issue? The unclear migration path between Java EE and Spring. For a green project, I'd stick with CDI, but what about a new iteration on an existing Spring project. Co-existence between Java EE and Spring is a mystery, if not a mine-field. And I'm not sure if having the two co-exist is a wise suggestion. Throw in a desire to use JavaServer Faces (JSF), and you've potentially three containers managing beans - not a friendly situation.

    One of the big challenges I'm seeing is that many organizations want to move to a CDI/Java EE 7 approach, but they are so invested in Spring, that making a move introduces a potential risk. I saw a big customer flush out the veracity of their entire system as supporting CDI, but kept with Spring, upgrading to version 4, just because they didn't want to lose their existing skills and code base.

    One thing that appeared lacking was really clear guidance on how to first have Spring and Java EE co-exist, and then how to eventually move towards CDI. The 'co-existence' seemed to be the problem. Having two containers seems dangerous. Throw JSF into the mix, where you might have a third if you used JSF managed beans, and it's a situation where architects just throw their hands in the air and say "Let's just play it safe. Let's stick with Spring and just move to a newer version."

     

  4. For a green project...[ Go to top ]

    Mostly you don't have a green project. You still have your infrastructure where your app should run and this is already your constraint. This is exactly what I'm talking about in my article.

    I myself - if I have to build a new webapp - will never use JSF, just RESTful + HTML5 + JavaScript (or AngularJS, GWT). This is the way to go.

    My proposal is actually to make enterprise app development easier. Yes the standards like JPA, JMS, CDI, ... are fine and should stay. But we don't need the Java EE umbrella standard. We just need the Container spec. and yes, we already have this == Servlet.

    So, why offer different kind of containers like Web container and Java EE container? IMO it is enough just to have ONE container == Web container, that's it. Just KISS principle. For the customers is becoming easier and transparent. It's always tough to discuss why we need JEE container or just a simple web container. Simplify: there is only ONE and ONLY ONE container: Web container.

    Lofi.

  5. It's not about some micro-feature that some solution would have and the other wouldn't. It's about a standard, with a specification and multiple implementations. Spring isn't that. It was a valid choice when it had much more features. Long ago.

    Besides that, having multiple people and organization think about a standard just makes better stuff. It could seem more difficult to use at first, but it's just better designed. Just take type safety as an example, Spring just sucks at that.

  6. It's about a standard, with a specification and multiple implementations.

    Actually there are less and less implementations from version to version. See this http://arjan-tijms.blogspot.com/2014/05/implementation-components-used-by.html.

    Of course standards are great but when you're not free to create the implementation (TCK?) it's not perfect...

    regards

    Grzegorz Grzybek

  7. My article just said that we should drop Java EE umbrella standard and NOT all the specs standards (JPA, JMS, CDI, Batch, ...). Please read the article carefully.

    Thanks, Lofi

     

  8. You realize that you suggest using Spring, which is the opposite of any standards? The umbrella specs makes it possible to have standard app servers, with a baseline which oughts to work the same whatever implementations have been chosen. This article looks like this jehovah's witnesses' book I saw recently. Full of explanations, sometimes inaccurate, sometimes just wrong, some magic, and some unrelated conclusion, like "drop the umbrella spec".

  9. I am not sure the author understands what and why JEE was created. I donot think there should be call to drop spring for jee as spring is not a replacement for jee, it only provides a small sub set of the feature of jee, that will be sufficient for a section of the software needs, but never all.

     Jee will eventually have features from spring making spring redundant, we are not there yet. Spring is just an a standard for good  standardized code development. but jee was  designed as means for the correct scalable system architecture. 

  10. It's a good standard - for other people.  As they said about returning WWI soldiers, "Once the boys have seen Paris it's hard to keep them on the farm."  The spec is mature, implemented, and met a need at the time.  It still does but technology has moved.  Apps have moved to the client.  Server side apps tend to be smaller services. For most development groups it takes courage to invest in newer technologies that take advantage of newer skill sets and fit into newer paradigms like cloud and nosql.  In the end adhering to the standard is all in your mind or your current companies'.