Enterprise Integration Zone is brought to you in partnership with:

Lofi has posted 6 posts at DZone. View Full User Profile

Why Should We Dump Java EE Standard?

06.20.2014
| 21343 views |
  • submit to reddit
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.


Programming Models

Following enterprise application types should be supported from both stacks JEE and Spring Framework:
  • Web apps
  • Batch apps
At last JEE 7 supports both application types. Although the support of batch apps is still very young you should be able to define centralized business logic and can use it in both web and batch apps. The biggest problem I see with JEE 7 so far are: 
  • Since JEE 7 and JTA 1.2 business logic component with transaction demarcation does not need to be an EJB component  anymore. But what about asynchronous method execution? For this purpose you still need Message Driven Beans (MDB) in EJB container. So EJB is still alive. This is where Spring Framework has its advantage. Everything like business logic components with asynchronous method execution and utilities is always POJOs, no different at all and it is available today. The counterpart of MDB is MDP (Message Driven POJOs) in Spring Framework.
  • Security mechanism like authentication and authorization in JEE 7 (JAAS) is still inflexible. If you use JAAS it is dependent on the chosen JEE container. In contrary Spring Security is flexible and you can use it in all runtime environments available. The good news is that Spring Security can be integrated easily in JEE 7 apps.  
  • Since Spring Batch 3.x supports JEE 7 batch standard and this framework is the longest batch framework available in the market you maybe will use Spring Batch as your JEE batch implementation. It is an additional complexity in case I would use Spring Batch 3.x and I need to reuse business logic components written in EJB. Do I have to run my Spring Batch app within an EJB or JEE container? Using pure Spring Batch makes everything simpler and easier.


Runtime Environments

Application server is the platform or the runtime environment where your JEE applications can be deployed and executed. Looking at the JEE application servers market you will notice that following has happened last year:
So actually the platform where you can run JEE applications is getting very few:
  • Open Source application server with commercial support and reasonable price can only be found from JBoss / Wildfly and TomEE. Also a JEE batch app needs a JEE container.
  • Apps based on Spring Framework can run everywhere (pure Servlet or JEE containers like Jetty, Tomcat, VMware vFabric tc Server, now Pivotal tc Server, JBoss, Wildfly, TomEE) as long as your apps can access the implementations of services like JMS, transaction and cache. Spring Batch apps can run just within the plain Java SE.


Your Options

So in 2014 if you ever need to start an enterprise project what kind of enterprise platform will you use?If you want to write easy, secure enterprise apps (web and batch) with a single Java programming model which can be executed in many runtime environments, Spring Framework is still the one and only one choice you have.

The Problem with JEE and My Solution: "One Runtime Environment with Standardized APIs and Simple Implementation Dependencies"

The idea to standardize some mechanisms using Java API is fine. It is good to standardize persistent mechanism with JPA, it is good to standardize dependency injection with CDI, messaging with JMS, Batch programming model with JSR-352 and others. What we don't need is the umbrella standard JEE which puts a lot of those APIs together. Take a look at this page to see the content of JEE. So what do we actually need?
  • We only need one runtime enviroment standard. That is what we know today with Servlet container (Tomcat, Jetty and others). This is the one and only application server or operating system we need for our enterprise applications.
  • We have all those standardization of APIs like JPA, JMS, CDI, Batch and others. The specification of those APIs should be completely loosely coupling. At the end as an end user you want to mix and match those APIs as you need them. The implementation of those APIs can be done like today through a normal framework implementation just like Hibernate (JPA), ActiveMQ (JMS), JBoss Weld (CDI), Spring Batch (Batch) and others.
That's it! No need to have those JEE runtime environments like JBoss, Weblogic or Websphere. Of course they can still bundle all those frameworks together like what they already have done today but the most important point is actually that you can mix and match the implementations with different specification versions. Today it is impossible to do so. If you have a JEE application server which supports JEE 1.4 it is almost impossible to use JPA 2.1.
Also if you have a lot of web and batch apps in production you cannot update all of them at once. Update has to be planned carefully. If you have JEE 1.4 container in production you will stick to it in long term, since your traditional operation won't accept if you want to use different kind of containers for example JEE 1.4 and JEE 7 in production. If you want to move to a new JEE 7 container you need to migrate all of your web apps at once and this is in a normal enterprise situation almost impossible. You can only update a web app within a project and you have limited resources to execute your project. So to use just a simple container and put all the implementation dependencies in the web app is the way to go. In this case you can use up-to-date APIs in some web apps. You don't need to update all the web apps just to be able to use up-to-date APIs in some new web apps. 

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. 

Spring Framework supports the idea of one runtime environment and mix and match APIs since the beginning:
  • You can use any runtime environments or containers which supports Servlet specification like Tomcat, Jetty or JBoss or others.
  • You can mix and match all those standardized APIs like JPA, JMS, Batch (JSR-352), CDI (not complete but some of the specs like JSR-330 and JSR-250). 
  • To use the APIs you have to include the implementations of the API specifications by yourself using standardize dependency mechanism for Java.
  • You get a lot of nice helpers to "glue" APIs together to build a nice programming model on the top.
So the ideal situation would look like this picture below:
  • Web app: the runtime environment (Web Container) does not include all the APIs implementations. The web app needs to include the dependencies by themselves (WEB-INF/lib directory).
  • Batch app: no special runtime environment, just standard JVM. The batch app needs to include the dependencies by themselves (-classpath in Java execution parameter). 

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.

At the end we chose Spring Framework. We will use all available standardized APIs with the best implementations we can get. To be able to mix and match the version of APIs in each web and batch app we will manage the dependencies within the apps itself using standardize Java mechanism.
Published at DZone with permission of its author, Lofi Dewanto. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Reza Rahman replied on Fri, 2014/06/20 - 10:40am

It is good the author is fairly clear about the fact that this analysis is something they decided upon as the correct one for their particular team after some debate instead of positioning it as the right decision for everyone. The reality is that such considerations are very much alive, will remain so in the foreseebale future and not everyone will make the same decisions. For example, here are some recent opinions that go in the opposite direction:

In fact, despite not wanting to do so, I had to update my own analysis (that BTW covers the opinions expressed in this analysis as valid choices) on request from customers: http://www.slideshare.net/reza_rahman/java- ee-and-spring-sidebyside-34320697.

A few comments on some specifics of the analysis for perhaps better balance:

  • The reality is that there are many happy users of EJB 3 and it is an excellent solution on it's own right. Just take a look at Adam Bien's hugely popular blog (http://www.adam-bien.com/roller/abien/) and some of the comments on them.
  • You have many choices for security in Java EE. For example, many of our customers choose WebLogic security for Java EE applications as they find it extensive, powerful and easy to use. That being said, you can also use Apache Shiro or PicketLink if embedded security is desired in Java EE applications.
  • The advantages of using the batch runtime that comes with Java EE 7 is that it minimizes configuration/setup, the jobs are managed by the container (e.g. through a properly managed thread pool) and you can manage/monitor the jobs through the container (e.g. the admin console).
  • GlassFish is here to stay. In fact, companies outside of Oracle have now stepped up to contribute and support GlassFish. Read a recent fairly balanced opinion on this: http://blog.c2b2.co.uk/2014/06/a-strong-glassfish.html. The Java EE application server market itself is as vibrant as ever. Take a look at the landscape: http://www.slideshare.net/reza_rahman/javaeenext-java-ee-7-8-and-beyond/38. In fact, the Sevlet container choices are very limiting by comparison.
  • Simply using and upgrading a pre-integrated runtime is far easier than getting into the business of fine grained dependency management and custom system maintenance. What many of our customers choose to do is simply use a newer runtime for new applications and leave older applications alone or gradually migrate them using WebLogic backwards compatibily features. This is especially easy to do using the cloud. One way of looking at this is bulding and maintaining your own Linux distribution vs. just going with a pre-configured one.

    Bruno Borges replied on Fri, 2014/06/20 - 11:06am

    Except from the first bullet, the Epilogue pretty much says: "Please decouple the APIs as much as possible but make sure they work with each other". This is what the Java EE EG already does: part of the goal of the Java EE Umbrella specification is making sure versions of specs work with each other.

    Lofi Dewanto replied on Fri, 2014/06/20 - 1:12pm in response to: Reza Rahman

    Dear Reza,

    thanks for your comment. 

    But this point is IMO not correct at least in my case:

    <Reza>

    • Simply using and upgrading a pre-integrated runtime is far easier than getting into the business of fine grained dependency management and custom system maintenance. What many of our customers choose to do is simply use a newer runtime for new applications and leave older applications alone or gradually migrate them using WebLogic backwards compatibily features. This is especially easy to do using the cloud. One way of looking at this is bulding and maintaining your own Linux distribution vs. just going with a pre-configured one.

    </Reza>

    I'm talking about "traditional operation" (see the article), no cloud. In a traditional operation you don't want to have a lot of different JEE servers with different versions. You stick to one app server and if you want to upgrade you need to upgrade all at once. They won't let you use different kind of app servers. Traditional operators think and act different than developers. Stabilize and harmonize the OS, app server and database is the most important target for them. And this is the real problem, since you will stuck on the old JEE 1.4 server (also for new app development) until you migrate everything to JEE 7.

    Almost all the articles I found (also your links) are written for and by consultants. They come and go and they do the project in short time (remember the definition of project). Most of them think in short term: what is the coolest technology I can use at the moment?

    I'm working as an internal architect and developer who has to maintenance all the apps in long term. My time line is 3 until 8 years. It is all about to fulfill the need of our business as fast as we can and still make the apps maintainable. 

    By adding all the dependencies to the app (batch or web) itself you will be able to maintain the "balance" between the operation and the development. The operation is happy to be able to manage and harmonize the app server. The development is also happy to be able to use newest APIs - at least in the new app development and I can carefully plan to upgrade the older apps to use the newest APIs, just step by step.



    Lofi Dewanto replied on Fri, 2014/06/20 - 1:17pm in response to: Bruno Borges

    Dear Bruno,

    my point is that we should be able to mix and match all those APIs. This is not the case with JEE since the spec put them together in particular version. So my point is not that they should work with each other, instead the should work independent with each other.

    Reza Rahman replied on Fri, 2014/06/20 - 3:22pm in response to: Lofi Dewanto

    The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment. It may be that you have a very unique and unfortunate operational situation. In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

    Not that it matters that much, but both of the cases I referenced above are actually driven by application owners with long term investments, not to mention the numerous other case studies at JavaOne over the years. BTW, most consultants do actually maintain long term relationships with their clients - my average is actually about five years :-). Otherwise, you really don't last long as a consultant :-). Again, Adam is an awesome example.

    Reza Rahman replied on Fri, 2014/06/20 - 3:04pm in response to: Lofi Dewanto

    Java EE does indeed allow this. Most application server vendors do in fact routinely update components (again just like Linux distributions), just look at the GlassFish update center facility or the WebLogic patch utility. It's also the case that applications rarely change their core dependencies in the short term instead of focusing on implementing business needs as you suggest. After all, any such change usually requires extensive testing of mission critical applications, whatever technology you are using.

    Lofi Dewanto replied on Fri, 2014/06/20 - 4:06pm in response to: Reza Rahman

    <Reza>

    The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment.

    </Reza>

    So lucky you ;-) In my 10 years Java enterprise experience it was and is always a "fight" with the operation to be able to use a "newer" or "other" app server. 

    <Reza>

    In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

    </Reza>

    I agree that this is the right move. In this case I have to say that "Spring Boot" has brought this idea (incl. Micro Services) to the next level.

    BTW. I know Adam because in 1998 / 1999 I were in the club of the first developers who support Java and Open Source in Germany within the first JavaMagazin and JAX conference ;-)


    Reza Rahman replied on Fri, 2014/06/20 - 8:17pm in response to: Lofi Dewanto

    I would say you need to introduce self-service cloud and DevOps to your IT shop instead of being stuck with a potentially unsustainable and unproductive way of operating. Interestingly, Gavin King wrote an excellent blog entry on this very topic worth reading: http://in.relation.to/Bloggers/YouShouldUpgradeToJavaEE6.

    In reality, almost all of my customers have moved into the runtime per application model for at least a good five years now - especially for mission critical applications or applications that utilize the granular sub-systems (aka micro-services) model. Believe it or not, this is even true for many WebLogic customers these days.

    BTW, if you want to look at a very large, relatively conservative environment successfully adopting Java EE for a period of time using WebLogic, take a look here: https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=2789. Also, in terms of Spring/Java EE analysis, this one is one of the best and I think almost a must-read: http://hwellmann.blogspot.com/2012/05/deconstructing-spring-myths.html.

    Lastly, I want to make sure to say it's not that I don't think your particular analysis is invalid. In fact, it may be exactly the right decision for you. The only point I am making is that it is clearly not really the only way of thinking for all environments. In fact, I happen to think Spring and Java EE co-existing in the long and short run is the best outcome for Java developers in the long and short term (and they do not need to be the same :-)).

    Lofi Dewanto replied on Sat, 2014/06/21 - 5:33pm in response to: Reza Rahman

    From your link Gavin King:

    <Gavin>

    This seems to be an organization-specific political problem, rather than an actual technical problem with the application servers themselves. Certainly, upgrading a server like GlassFish or JBoss is usually a pretty trivial task. (And upgrading third-party frameworks is certainly not always painless.) Apparently, some organizations have put in place extremely heavyweight processes surrounding server upgrades, without introducing similar processes for frameworks which run inside the server, thus making it easier for the development team to deploy upgrades to third-party frameworks than to the application server itself.

    </Gavin>

    Actually IMO this is not the question of the organization or the politic, it is just simple as money, resource and priority ;-) If you have still mainframes in your organization you will make the migration as your first priority.

    <Reza>

    In reality, almost all of my customers have moved into the runtime per application model for at least a good five years now - especially for mission critical applications or applications that utilize the granular sub-systems (aka micro-services) model. Believe it or not, this is even true for many WebLogic customers these days.

    </Reza>

    This is definitely the way to go. Therefore I don't see any problem including JAR into your web app since there will be just ONE web app in your container anyway. You don't save any memory consume or whatsoever with this mechanism. Arun Gupta's blog at https://blogs.oracle.com/arungupta/entry/why_java_ee_6_is was really a marketing blog ;-) 

    My hope with this article is following and based on KISS principle:

    1. We will have one and only one container with its spec. Servlet is the way to go. JBoss and others offer the implementation for this spec. In this spec it should be the real basic stuffs for the "Enterprise Operating System". What are the basic stuffs? IMO just the Container and the Servlet. The rest like JPA, JMS should not be included in the basic stuffs.

    Of course the vendor can put all the APIs they think it is useful. But no need of JEE umbrella spec. Analog to OS like Linux, you don't have a spec to build a Linux distro, right? Each distro (SuSe, RedHat, etc.) can mix and match APIs and implementations what they think it would be useful. 

    If you want to offer such an umbrella standard like JEE you should offer the ability to configure all the APIs mixed and matched, something like "I would like to use JPA 2.1, JMS 1.1 and JTA 3.x in my app1 within my JEE app server" and "I would like to use JPA 1.0, CDI 1.0 and JTA 1.1 in my app2 within the same JEE app server". So the JEE app server can be configured to used different APIs and implementations easily. But again the easier way is just to add the APIs and implementation versions you need in your app dependencies (WEB-INF/lib) using standard Java dependencies mechanism (Maven also helps a lot).

    2. All other APIs are independent with each others. Loosely coupling between them. All vendors implement these APIs just like today. Please no dependency something like you need CDI x.x to be able to use JSF x.x.

    Hope to see something like this will happen in the future ;-)




    Lofi Dewanto replied on Sat, 2014/06/21 - 6:08pm in response to: Reza Rahman

    One comment to this:

    <Reza>

    </Reza>

    In that blog you find this part:

    <Blog>

    On the other hand I will not take anything away from Spring. Yes is a good enterprise framework, mature and extensively used. But going forward and taking correct decisions opting for a vendor specific implementation locks you in to technologies you may don’t have the opportunity to change in the future, with the fast pace of changes in our world. I don’t neglect that the Spring community is adapting fast. But providing unified environments and ability to change, for me are far more important factors.

    </Blog>

    "Opting for a vendor specific implementation"... Ahem... Spring Framework is still Open Source software ;-) If you think like this you should not use Apache commons-xxx, or Android or Linux Kernel ;-) The guy should not talk about vendor lock-in in Spring Framework.

    Reza Rahman replied on Sun, 2014/06/22 - 12:43am

    * You can use different versions of Java EE APIs in the same application. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by specifying the version number. There is often no real reason to have this degree of customization and it is rarely ever done in Java EE applications. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications.

    * Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code. That's a perfectly valid indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this is that integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that an add-on framework simply can't do. 

    * Whether or not you use one or more applications on a server, using a pre-configured runtime will always save effort and be better supported instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus on their own application code. If you claim needing to customize your runtime is such a big deal, can you objectively explain why it's not a big deal to the users of these widely used runtimes?

    * Objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable fork. To make matters worse for users, historically forks are never compatible unless backed by a standard. By comparison switching between readily available compatible implementations is far more practical for most people. Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

    The compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

    Lofi Dewanto replied on Sun, 2014/06/22 - 5:03am in response to: Reza Rahman

    <Reza>

    * You can use different versions of Java EE APIs in the same application. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by specifying the version number. There is often no real reason to have this degree of customization and it is rarely ever done in Java EE applications. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications.

    </Reza>

    In my problem I'm not talking about backward compatibility. I'm talking about "forward compatibility". Again this is about traditional operation which is slower to upgrade the app server and the development which needs to use the up-to-date APIs. If you are using the old OAS 10.x or Weblogic 10.x it is hard to be able to use JPA 2.1 (just google it). 

    This is the definiton of forward compatibility from Wikipedia:  "A standard supports forward compatibility if older product versions can receive, read, view, play or execute the new standard gracefully, perhaps without supporting all new features". This is just not the case with all the JEE app servers. Remove JEE spec and let us the developers to be able to use the APIs mixed and matched. If you can decouple app server with its APIs (== drop JEE umbrella standard), you will be able to use forward compatibility in your app. 

    <Reza>

    Spending time building and configuring runtimes seems to be a peculiar obsession with some parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus on their own application code. 

    </Reza>

    Luckily this is not my hobby ;-) It's all about to be able to use the up-to-date APIs. JPA 2.1 has brought some features which you don't want to miss. Waiting until your app server in production beeing upgraded from JEE 1.4 to the latest JEE 7 will let you stuck doing workaround. Also don't forget about the migration volume. If you have to stick with JEE 1.4 in your new app development you will increase your migration volume. Maybe I'm just unlucky always have to deal with those traditional operations :-(

    Like you said cloud mechanism with one app server for one app would be the solution but tha't another story ;-)

    BTW. Spring Framework offers Spring Boot now to be able to easily get started with Spring and this is amazing. Just run java -jar xxx and you get everything started. Also see the Maven dependency, very simple. I think this mechanism with combination of microservices and cloud will be the way to go. But until the traditional operation gets into it, it will be a long way to go... Just my opinion ;-)

    <Reza>

    * Objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. 

    </Reza>

    Yes in some degree you are right. But IMO it's always a balance of standardization and innovation. To much standardization kills innovation, to much innovation makes chaos.



    Reza Rahman replied on Sun, 2014/06/22 - 6:12am in response to: Lofi Dewanto

    The reason Java EE does not support "forward" compatibility is that like most mainstream technologies it follows the detect and fail fast principle. Almost all infrastructure software does not support forward compatibility because it is results in potentially incorrect and unpredictable application behavior.

    I can agree that you may have a particularly bad operational environment, but that's not typically a significant problem for most IT decision makers with any real authority (and it's never personally been an issue for me for new projects in many years). After all, installing and upgrading software is a key responsibility for most  operations folks and most know how to do it quite well.

    This is precisely why it's not a problem for users of widely used platforms that focus on actual ease-of-use such as Java EE, .NET, Rails and Play!. I am happy to see Spring Boot has finally begun to embrace real productivity, even if only for very limited getting started situations right now. It's a step in the right direction that basically validates what pretty much every other modern platform like Java EE has been doing for years now.

    Java EE is aimed at providing a well-understood common platform that applications can rely upon to port between compliant runtimes as easily as possible. That means defining an API set that is clearly too small risks the compatibility that standards are all about, not to mention the ease-of-use that modern platforms of today aim for. In fact, no mainstream standard follows the model you suggest for this very reason.

    Lastly if anything Java EE is conservative and focuses on standardizing well-understood features like all other modern standards, so outpacing innovation has not been a real issue in years if ever.

    Lofi Dewanto replied on Sun, 2014/06/22 - 1:18pm in response to: Reza Rahman

    <Reza>

    The reason Java EE does not support "forward" compatibility is that like most mainstream technologies it follows the detect and fail fast principle. Almost all infrastructure software does not support forward compatibility because it is results in potentially incorrect and unpredictable application behavior.

    </Reza>

    Hmmm... if you think of separation of concerns and decoupling, I don't know why JPA 2.x would be dependent on JSF 2.x? Or Batch 1.x dependent on CDI 2.x? Or JPA 2.x dependent on Servlet 3.x? Why should it be impossible to decouple all the APIs? 

    What I'm asking is just make the Container + Servlet standard just standalone as a runtime environment. And this will be the basic of your enterprise operating system. This is today already the case with Servlet, so no change at all. The rest of the thing should be standardize as well just like JPA, JMS, CDI, etc. which should be decoupled with each others and you can use the version and implementation as you need (e.g. libraries). Today I just don't see the importance of umbrella standard like JEE. Doing this idea you will be able to support forward compatibility in your enterprise apps. 

    The situation with JEE standard is for me just like this scenario: 

    • Imagine if you need to upgrade your Windows operating system (just name any OS here) just to include a newer version of your printer driver (just name any drivers here).

    Again I'm for standardization (see the article): JPA, JMS, CDI, Batch, JSF, Servlet, Container, ... are great. What we should simplify is following:

    • Offer only ONE container specification for all enterprise applications. No need to divide into WEB and JEE. 
    • Drop JEE as an umbrella standard because of the reasons I already mentioned in my article so we are able to mix and match all the APIs and implementations.



    Lofi Dewanto replied on Sun, 2014/06/22 - 1:23pm

    There are some other voices which actually understood what I'm talking about (luckily). Go to: http://goo.gl/CaL1MI

    Reza Rahman replied on Sun, 2014/06/22 - 8:47pm in response to: Lofi Dewanto

    The reality is that most Java EE standards are actually very tightly integrated, especially at the platform level. In fact making sure every part of Java EE works together is what the Java EE platform EG spends most of it's time on so it's anything but trivial. To take your examples, JPA has always had tight integration with JTA, CDI and EJB; JSF has tight integration with Bean Validation, CDI and EL, Batch has tight integration with CDI and JTA: the list of such integration are virtually endless and highly version dependent. Putting this kind of configuration burden on the developer leads to configuration complexities that should be handled by the platform while the developer is focused on just writing business logic.

    This is why no mainstream modern platform or standard does what you suggest and focuses on providing a zero-configuration, easy-to-use out-of-the-box developer experience (such as Java EE, .NET, Ruby or even Node.js). In fact the Spring model is quite out-of-date and more like old school complex C/C++ style development - it's clear only some Spring die-hards want that model and pretty much no one else. That's exactly why they too are now looking at fixing that complex model with Spring Boot to stay competitive now that modern application servers like GlassFish, WildFly, TomEE, WebSphere Liberty and latest versions of WebLogic provide the same developer experience as Tomcat without the configuration complexity or the compatibility/lock-in risks.

    Can you really explain why pretty much everyone in the industry including Spring is going in the exact opposite direction you suggest for years? Your griping about your own IT environment that seemingly prefers to use out-of-date software just doesn't hold water given the trends towards continuous integration, effective regression test suites for change management, DevOps and the cloud, not to mention our core community that wants more usability/simplicity and less configuration hassle from us. That was the clear trend from the 4500+ people that filled out the Java EE 8 survey: https://blogs.oracle.com/theaquarium/entry/java_ee_8_survey_final.

    Cameron Mckenzie replied on Mon, 2014/06/23 - 10:31am

    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."


    BTW, which of the posts above is from "The Real" Reza? 

    Reza Rahman replied on Mon, 2014/06/23 - 12:04pm in response to: Cameron Mckenzie

    Both are my accounts - one older than the other. And I totally agree with you. There's a bit of material out there on CDI/Spring integration/migration but not nearly enough for folks that want/need the material.

    Lofi Dewanto replied on Mon, 2014/06/23 - 2:26pm in response to: Reza Rahman

    <Reza>

    The reality is that most Java EE standards are actually very tightly integrated, especially at the platform level. In fact making sure every part of Java EE works together is what the Java EE platform EG spends most of it's time on so it's anything but trivial. To take your examples, JPA has always had tight integration with JTA, CDI and EJB; JSF has tight integration with Bean Validation, CDI and EL, Batch has tight integration with CDI and JTA: the list of such integration are virtually endless and highly version dependent. 

    </Reza>

    Thanks for the insight. I think this has to be fixed first. How can JPA APIs (javax.persistence.*, not the implementation) has a tight integration with CDI APIs and other APIs? I can imagine that there will be implementation dependencies but not at the spec. (APIs) level? Ideally all the APIs (spec) are independent (also version independent) with each other. 

    <Reza>

    Can you really explain why pretty much everyone in the industry including Spring is going in the exact opposite direction you suggest for years? Your griping about your own IT environment that seemingly prefers to use out-of-date software just doesn't hold water given the trends ...

    </Reza>

    I'm working in the reality. Software development and IT infrastructure update are managed as projects. In my experience you have a lot of development and infrastructure projects within a bounded time line and you have your budget for those projects. At the end your resources is the constraint, so you need to prioritize the projects. In a lot of cases I see following examples:

    • The infrastructure will be renewed (example JEE 1.4 to JEE 6, or Java 4 to Java 6) until next year (let's say May 2015). All the apps need to be regression tested. Luckily there is already a continuous integration platform so hopefully the regression tests will be executed easily. Some tests have to be done manually because you still have some mainframes in the middle (to make my example a bit complex ;-)) 
    • At the same time the business needs to have some new batch and web apps for supporting their business processes. All the apps should go online next year (let's say February 2015). So we have to begin with the development just next month.
    So in the reality you always have time overlap between your infrastructure and development projects. Now you have to begin with your development and as you know that until February 2015 you don't get your JEE 6 environment you only have following choices:

    • Stick with your JEE 1.4 development and you'll increase your migration volume with half a year development. Half a year can mean a lot of codes depends on the amount of your person/day.
    • You try to use up-to-date APIs and implementations (yes, JPA 2.1 is worth to use) in your web apps and batch apps with following constraint: all of the apps must run under the old JEE 1.4 environment. Surely you hope that in case the infrastructure has upgraded in May 2015 you may easily migrate to the new JEE 6 environment. 
    I see this kind of game is always repeating the whole time, therefore I'm writing this article ;-). Please read the prologue. This situation will be the same with JEE 7 in 5 years. Do you know how many Windows XP, JEE 1.2 apps, Mainframes, SAP/R3 are still in production? Do you think that all those users want to stay with all those oldies? It's always the question of resources, so money and priority.

    Making the enterprise application development just like what I've written in my article will help us to be able to manage the situation I describe above. If you see my graphic in my article, IMHO, it makes everything easier and clearer.

    BTW. the dependencies for the libraries are always a complex thing, and need to be managed. But for that purpose we already have Maven and RPM, right?

    Lofi Dewanto replied on Mon, 2014/06/23 - 2:41pm in response to: Cameron Mckenzie

    <Cameron>

    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.

    </Cameron>

    It's always the question of resource (money) and priority. I cannot see the economic value of migrating Spring web app to the JEE web app. You can use Spring @Configuration to be 100% free of XML (already in Spring 3.x), also free from JPA persistence.xml ;-) You can use up-to-date APIs (JPA 2.1) in older environments (JEE 1.4). You can use just simple Tomcat/Jetty.

    At the end IT should give additional values to the business. Migrating from Spring to JEE makes IMHO no sense.

    Reza Rahman replied on Mon, 2014/06/23 - 3:52pm in response to: Lofi Dewanto

    I think this discussion is now rapidly reaching a point of diminishing return, but I'll address your (mostly repetitive points) in an effort to wrap this up:

    * The dependencies between Java EE APIs are in fact runtime, not compile time: such as supporting CDI injection in JPA entity listeners, etc.

    * Unlike other platforms like .NET, Ruby and Play!, Java EE in fact has supported what you suggest for years. That's exactly why you can even think about using Servlet, JSF, EL, JMS, Batch, JavaMail, JAX-RS, JPA, Bean Validation, WebSocket, JSON-P and even core APIs like EJB, JTA, JAX-WS and CDI outside the platform. There is little more to be done on this end that has practical value. If there is, I'd like to know the specifics.

    * The platform is there to provide better integration between all Java EE APIs, a vendor-neutral standard compatible runtime that can be relied upon as well as ease-of-use/integration/near-zero-configuration. These are in fact the reasons that folks that are moving from Spring and our steadily growing core community consistently say they value the most compared to alternatives, so it will remain a focus for us in the foreseeable future. This no different from what the majority of the middle ware industry has been doing except perhaps for Spring.

    * This is how folks that work with platforms (Java EE and all others) deal effectively with upgrades on a routine basis:

    1. They choose the most up-to-date version of their platform available at the time of project initiation, both for production, integration, development, etc. 
    2. Sometimes they choose to upgrade their productionenvironment last while being more aggressive in their development environment. For example, some of our customers use GlassFish in development and WebLogic in production.
    3. They use techniques like regression test suites, migration scripts/tools, continuous integration and DevOps to upgrade runtimes in a timely fashion with minimum hassle and always stay up-to-date without getting into the business of chaotic custom runtime/application configuration hell/local patches by application developers (which in reality is more costly/unproductive in the long run as well as unsustainable).
    4. Some folks never upgrade runtimes for older maintenance applications and simply use newer runtimes for newer or more active applications.

    Most reasonably competent IT shops have no problem doing this if you bother to ask around beyond the Spring echo chamber.

    Lofi Dewanto replied on Mon, 2014/06/23 - 5:35pm in response to: Reza Rahman

    <Reza>

    * Unlike other platforms like .NET, Ruby and Play!, Java EE in fact has supported what you suggest for years. That's exactly why you can even think about using Servlet, JSF, EL, JMS, Batch, JavaMail, JAX-RS, JPA, Bean Validation, WebSocket, JSON-P and even core APIs like EJB, JTA, JAX-WS and CDI outside the platform. There is little more to be done on this end that has practical value. If there is, I'd like to know the specifics.

    </Reza>

    Yes I hope it stays like that (and this is IMO great), so that the way I mentioned in my article can be implemented with help of some other frameworks (Spring, ...) to tackle real problems I mentioned before.

    It's good to have alternatives which can be used to tackle different problems. I came from J2EE world (see my old thread - 2005 - in TheServerSide: http://www.theserverside.com/news/thread.tss?thread_id=31914 and other J2EE discussions by googling them) and have moved to Spring after often seeing the problem I mentioned above. 

    You're right, we should stop now ;-) Thanks a lot for a very interesting discussion. Hope to see enterprise application development will be easier and easier for all of us.

    Reza Rahman replied on Mon, 2014/06/23 - 6:18pm in response to: Lofi Dewanto

    There are no plans to change anything about Java EE any time soon in terms of it's overall direction. We believe what we do is key to the overall health of the Java ecosystem now and in the far future, whether or not you are a current user of the Java EE platform itself.

    Christian Sterzl replied on Thu, 2014/06/26 - 6:56am

    First, really try to upgrade your servers. OAS isn't even supported anymore, if you are argumenting against Glassfish server because of missing commercial support.

    Second, your statements are wrong.

    •  But what about asynchronous method execution? Have you heard of @Asynchronous? Since EJB3.1
    • Why is EJB bad? EJBs with no-interface view are like POJOs. There is barely any difference.
    • JAAS is very flexible in my opinion. What are you missing?

    Your arguments are not very sophisticated.

    Steve Millidge replied on Thu, 2014/06/26 - 1:44pm

    As one of the "Consultants" referenced  but also independent so have no particular axe to grind in the JavaEE versus Spring debate as I'm an app server specialist and Tomcat + Spring is YAAS (Yet Another Application Server) ;-). Hopefully as a consultant I see many, many application server architectures and deployments and therefore may have a different perspective ( which is why people hire consultants). 

    I'm intrigued why you seem to think the Servlet spec is special and therefore serves as a baseline. Why not follow your logic and decouple the servlet specification from the runtime and all the other application server capabilities? I suspect it would be because you don't want to assemble a base application server runtime from all the parts e.g.

    Thread work management
    Security
    Socket Handling
    HTTP protocol implementation
    Application Lifecycle Management (Deployment)
    Object Lifecycle Management
    Database Pooling etc. etc.
    Transaction management

    So you essentially want a baseline. Tomcat gives you a certain baseline. TomEE gives you Tomcat + Java EE Web Profile as a baseline
    Java EE application servers give you web profile or full blown Java EE as a base line. Under the covers GlassFish is an OSGI engine so you could freely remove large chunks of core Java EE functionality. Same with JBoss.

    It all depends on what the developer wants. All developers are different. Some program web apps. Some program complex integration infrastructures and therefore don't want to assemble JMS, Batch, Job Schedulers and Concurrency utilities into their applications etc. etc. Some "Java EE" developers don't need web apps, many corporate systems have been built on Remote EJB calls or JMS and MDBs.

    Spring gives you another baseline to work with it's not "intrinsically better" just different.  I've seen horrendous bloated Spring deployments with Spring used incorrectly and developers having inconsistent jar versions spread across their production estate, causing a support and security patching nightmare, as they've assembled their own application server, using a random version of Tomcat. Try unpacking and patching that with no record of the versions of jars used. I've also seen horrendous JavaEE code.

    JavaEE gives you two baselines you can rely on to be supported across certified application servers. The JCP could define more if they wanted. It's all about how consistent you want your target deployment environment? Many developers want complete control of target runtime, many ops people want similar control. Java EE application servers draw a line somewhere, Spring on Tomcat draws it somewhere else. 

    I support app servers irrespective of the crud developers drop on them ;-)

    Steve Millidge replied on Thu, 2014/06/26 - 2:34pm

    Hi Lofi

    One specific question I ask a lot. Who in your environment is responsible for tracking the third party components you use in your production Spring applications for security vulnerabilities? I know most ops teams will subscribe to the security update feeds for Java EE application servers and Tomcat. I haven't met many that track components embedded within Spring wars or that track Spring specifically.

    A genuine question.

    Steve

    Ritesh Nath replied on Thu, 2014/06/26 - 2:55pm

    Lofi,

     Excellent article, my organization is also on the same cross-roads. We have to decide whether to move ahead with JavaEE or Spring. Right now we have a good mix of both.

    Java EE has certainly caught up with Spring, but it appears to be a catch up game rather than leading by innovation. 

    I88 Li replied on Thu, 2014/06/26 - 3:04pm

    "Lastly if anything Java EE is conservative and focuses on standardizing well-understood features like all other modern standards, so outpacing innovation has not been a real issue in years if ever."

    Totally agree. The effort to dump Java EE standard is 

    futile

    in the long run. If you dump current Java EE standard, the industry will need another Java EE standard anyway.

    John Hogan replied on Thu, 2014/06/26 - 4:27pm

    <Lofi>
    We would like to minimize the use of our home grown frameworks.
    ....
    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.
    </Lofi>

    So what's the problem, upgrading to jee 6 or 7 allows you to get rid of your homegrown CDI frameworks and achieve one of your stated goals.  Also, the CDI and transactional features are there for you in Java EE 6 or 7.  Also, enterprise java (J2EE and JEE) also had the declarative transaction management for services, caching, security long ago also.  Actually, long before Spring existed.  It's just all easier to do in Java EE, relying heavily on convention over configuration.


    <Lofi>
    Since JEE 7 and JTA 1.2 business logic component with transaction demarcation does not need to be an EJB component  anymore. But what about asynchronous method execution? For this purpose you still need Message Driven Beans (MDB) in EJB container.
    </Lofi>

    Actually, you can do essentially the exact same thing in Java EE 6 & 7 just by using a web-profile/war application.  In this scenario, an ejb is just a pojo.  It is transactional by default, and it can be asynchronous as well.  You can also apply all you're transactional demarcations on the class and/or methods to your heart’s desire.  However, there's no need to as all your EJBs are transactional already using convention over configuration, nice and clean.  In most all cases, there's no need to touch the built in transaction support.  No need to muck up your code with all the tx annotations, or worse still by having to individually configure your beans and a tx manager in your application context file.  You're life will be better and the team will love it.

    <Lofi>
    Security mechanism like authentication and authorization in JEE 7 (JAAS) is still inflexible. If you use JAAS it is dependent on the chosen JEE container. In contrary Spring Security is flexible and you can use it in all runtime environments available. The good news is that Spring Security can be integrated easily in JEE 7 apps.
    </Lofi>

    I've never had any major issues migrating a security implementation from one java ee sever to another.  Generally, if the implementation is standard, migration to a different vendor’s app server is straight forward.  This is because they're all built to the same standards.

    <Lofi>
    Since Spring Batch 3.x supports JEE 7 batch standard and this framework is the longest batch framework available in the market you maybe will use Spring Batch as your JEE batch implementation. It is an additional complexity in case I would use Spring Batch 3.x and I need to reuse business logic components written in EJB. Do I have to run my Spring Batch app within an EJB or JEE container? Using pure Spring Batch makes everything simpler and easier.
    </Lofi>

    If you have a spring batch app that does the job and is not running in a Java EE container, keep that. There is need to fix something that isn't broken. On the other hand, if you'd like your spring batch app to communicate with business components in a java ee container, you can do that as well.  You're spring app can communicate with Java EE in another jvm if needed.  I just wouldn't mix spring with your Java EE app.  Also, as you mention, there's batch support in Java EE 7.

    <Lofi>
    Application server is the platform or the runtime environment where your JEE applications can be deployed and executed. Looking at the JEE application servers market you will notice that following has happened last year:

      2013 Oracle pulled out OSS JEE server Glassfish's commercial support.
      OSS JEE server Apache Geronimo is going nowhere, because IBM pulled out the commercial support for Geronimo.
    </Lofi>

    Does this matter?  Oracle is not a non-profit company, and they happen to own that other app server you may have heard of called weblogic.  They will continue to provide commercial support Java EE 6 on Glassfish 3 for years to come.  Also, even though Oracle discontinued support for Glassfish 4 going forward, commercial support can still be obtained from 3rd party vendors, just as you can with Tomcat.

    <Lofi>
    So actually the platform where you can run JEE applications is getting very few:

      Open Source application server with commercial support and reasonable price can only be found from JBoss / Wildfly and TomEE. Also a JEE batch app needs a JEE container.
      Apps based on Spring Framework can run everywhere (pure Servlet or JEE containers like Jetty, Tomcat, VMware vFabric tc Server, now Pivotal tc Server, JBoss, Wildfly, TomEE) as long as your apps can access the implementations of services like JMS, transaction and cache. Spring Batch apps can run just within the plain Java SE.
    </Lofi>

    Actually, this is very far from reality.  Go have a look at Oracle's Java EE compatibility page at: http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html.  There are 16 different Java EE compliant servers to choose from, with many options both open source and commercial.

    <Lofi>
    So in 2014 if you ever need to start an enterprise project what kind of enterprise platform will you use?If you want to write easy, secure enterprise apps (web and batch) with a single Java programming model which can be executed in many runtime environments, Spring Framework is still the one and only one choice you have.
    </Lofi>

    I'm going to choose the one backed by open JCP standards that enjoy broad industry support from some of the greatest technology companies in the world like IBM, Oracle, ... the list goes on.  I'd much rather do this than rely on a single vendor/company.  If you don't want any choice at all, put your eggs in the spring basket.  Also, remember that Java EE works quite well without spring, and spring cannot accomplish much that's useful without Java EE.

    I think it's clear you're a Spring fan, and that's fine.  I just think you should get your facts a little straighter, and stop with the FUD campaign.

     

    Cristian Malinescu replied on Thu, 2014/06/26 - 6:42pm

    Note - I'm the architect and lead developer of the new, pure Java Core Web development framework  Cherry - see https://github.com/Sabadios/Cherry so I'm biased towards my brain child :). I think currently Cherry is the best alternative in the Java world to develop high complexity and high performance web applications due to its natural lightweight architecture and 100% compliance with standard Java and Java Enterprise API unmatched currently by any other framework I'm aware off. Grails is just heavyweight, bloated and non Java EE API compliant, same about Play! and Restlet - with Cherry Framework there you can run just a simple jar without an application server and without the bloat of any XML descriptors - everything from persistence till browser is 100% JSON not even a single line of XML required. 

    Currently I'm looking for developers to join the project and implement new features, so don't hesitate to give it a try from here https://github.com/Sabadios/Cherry. A sample very basic webapp can be found here https://github.com/Sabadios/GoCherry and it also requires advancement so that it can be deployed in the near future as the reference, live PoC of the main platform.  

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.