I am a Software Architect at IBM India Software Labs and part of the BPM product development team.In my spare time, I like to research on upcoming technologies and like to share my knowledge and experiences through blogs,articles, books and various forums.I am also a Master Author with IBM developerWorks,have co-authored books on Spring framework, the first book on Apache CXF and multiple IBM Redbooks.You can reach me on my website www.naveenbalani.com Naveen is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

Do you need to move from Spring to Java EE 6?

07.30.2011
| 10081 views |
  • submit to reddit
I read an interesting post last year - “Moving from Spring to Java EE 6: The Age of Frameworks is Over”.  I am sure, everyone would have its perspective on the above blog and here are my views on this.

But before that, let’s step back and look and why frameworks like Spring was invented in the first place. In my view, primarily it was created as an alternative to J2EE stack, to keep it simplified, POJO centric and testable without the need for a container. Then came in support for various abstractions layers – JDBC, Transactions, ORM, JMS which can be applied POJO in a consistent manner and support for plugging in any web framework , all backed by principle of dependency injection. What it offered was a choice to programmers (and that’s very important) and didn’t restrict it usage to any specific API directly.  Using Spring, one could create modular components which could be run against a J2SE environment(derby and local transaction manager for your local test environment) and then promoted to use capabilities offered by J2EE Applications servers like JNDI, JTA and so on.

Over the years, J2EE tried to catch on, tried to create specifications and standardizations which were well adopted and tested by the framework like Spring or ORM providers like Hibernate. Specifications are good, but lot of time goes in creating specifications and it takes even lot more to get these specifications incorporated into the release of J2EE servers and stacks. Though specifications were created, you would still see vendor specific extensions required to run a particular feature. I mean, can you still take an Enterprise application (running on latest J2EE spec), which has couple of EJBs (3.0 or 3.x), uses transaction and JMS services and run it on a server which supports the same J2EE specs. Probably No, Yes, May be with the latest specification, may be with vendor specific extensions (?).  Let’s look at the latest release features to find more of this information.

The latest release of J2EE has support for Dependency injection (JSR-299 contexts and Dependency Injection for the Java EE platform specification), which is same as offered by Spring, Bean Validation (standard Bean validation offered by Apache projects, but now using standard annotations), streamlined development (through the use of POJO, JPA for persistence and revised EJB approach) and extensibility to add in vendor specific extensions in a consistent way. If you look at these goals, these matches with principles which I had listed earlier on why Spring was invented, only thing it took J2EE probably too long (probably 6-7 years assuming Spring starting gaining widely adopted in 2003) to arrive at this specification.  Even though J2EE has the principles now, it still restricts its usage to that of a container, for instance I can run spring in a standalone environment (J2SE environment with local database and transaction support) as well as promote it to full fledged J2EE application, running on multiple application servers.Also there are no approaches provided on how to test individual components (in and outside the container) using a pure J2EE stack. I seriously feel, there should be specification around testing of components.
To conclude with some thoughts -

  • I can achieve everything in Java EE 6 using Spring , but not the other way round.
  • I can get Java EE 6 (or 7.x or 8.x  ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.
  • I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.
  • J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.
  • J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.
  • Finally it’s up to your requirements and what applications you are building.
References
Published at DZone with permission of Naveen Balani, author and DZone MVB. (source)

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

Comments

Rob Wilson replied on Sun, 2011/07/31 - 1:30am

A refreshing reflective view, on where we are now. Something had been nagging me about Spring recently, then after reading your post I realised what it was, the additional complexity (and footprint) of a framework that you no longer 'need'. Regards, Rob

Seb Cha replied on Sun, 2011/07/31 - 6:09am

This is questionable in a context of web application.

But JEE 6 is unuseable for a little standalone application.

 

Henk De Boer replied on Sun, 2011/07/31 - 7:08am in response to: Seb Cha

This is questionable in a context of web application.

It's not questionable, the Java EE 6 Web Profile is absolutely perfect for a web application (be it a little one or a large one).

But JEE 6 is unuseable for a little standalone application.

If you mean "desktop application" with little standalone application, then I wouldn't really say unusable at all! It's true that the focus does not seem to be at Java SE (it's called Java EE after all), but have you been paying any attention to how much of the Java EE stuff is explicitly spec'ed for usage in Java SE? JPA, CDI, EJB and JMS among all have explicit APIs and sections in their spec for Java SE. JTA is also fully usable in Java SE (and has been for years). Granted, JSF doesn't directly work in Java SE and nor does Servlet, JSP and JAX-RS, but those are very specific web technologies that make less sense on the desktop. (if you really wanted, I'm sure you could get some way with using an embedded Servlet container).

Henk De Boer replied on Sun, 2011/07/31 - 10:20am

Even though J2EE has the principles now, it still restricts its usage to that of a container, for instance I can run spring in a standalone environment

Take a guess where Spring beans run. Is it maybe the... Spring Container?

Hussachai Purip... replied on Sun, 2011/07/31 - 11:06am

Spring container is more portable than JavaEE container. You can install it to JavaEE application server and use both Spring and JavaEE. I prefer Spring to JavaEE in case I have to install my application to multiple brands of server such as Tomcat, Glassfish, JBoss, etc. If you still choose JavaEE - even you know that you've to install your application to various brands of server, without doubt, you must be a hardcore configuration master.

Zqudlyba Navis replied on Sun, 2011/07/31 - 5:57pm

I can take a WAR file and run it in Tomcat or any Java EE container, but can I take an EAR file and run it in Tomcat ?

Hussachai Purip... replied on Sun, 2011/07/31 - 9:57pm in response to: Zqudlyba Navis

Yes you can but in the modified tomcat, Tomee http://openejb.apache.org/3.0/apache-tomee.html

Charlie Mordant replied on Mon, 2011/08/01 - 1:57am

J2EE container is a all in one solution, compared to Spring where you pick up what you want.

I agree that you must have to write some more configuration files, but with this, you'll learn what you'll do, the adjacent concepts and the way to use it.

I think it's far more interesting to choose the best brick to use in your program (hibernate instead of eclipselink for example) due to benchmarks and comparisons for the needs of your application than to be constrained using a lot of useless and not optimized libraries.

Reza Rahman replied on Mon, 2011/08/01 - 10:47am in response to: Henk De Boer

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Reza Rahman replied on Mon, 2011/08/01 - 10:52am in response to: Hussachai Puripunpinyo

Thanks for pointing out Apache Tom EE. It is indeed an excellent solution for people hung up on Tomcat, as is pluggable solutions like OpenWeBeans and OpenEJB. I was actually planning on doing a talk outlining how any non-Java EE environment can be turned into a Java EE environement using just pluggable solutions like these.

Anton Arhipov replied on Mon, 2011/08/01 - 6:25pm

Does it make sense to compare EJBs to Spring beans? It is rather meaningful to compare CDI (weld) to Spring, IMO. Given that you can use Weld the same way as Spring - on Tomcat, Jetty or any other container, why bother? Yeah, Spring has a longer history behind with all the bells and whistles... JavaEE is catching up. The bottom line is if you do not use EJB, you're not tied to any container.

Reza Rahman replied on Mon, 2011/08/01 - 6:46pm

Actually, you can use both CDI and EJB in Tomcat/Jetty using embedded solutions like OpenEJB and OpenWebBeans. In fact, Tomcat integration is a primary focus for OpenEJB, OpenWebBeans and Tom EE.

Carla Brian replied on Sat, 2012/05/05 - 10:37pm

I haven't use this one. But I've heard good feedbacks on this. Maybe I will try this one. - Tawny Tucci

Comment viewing options

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