Java Champion / JavaOne Rockstar Adam Bien (adam-bien.com) is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Future Of Enterprise Java ...Is Clear (Java EE with/without Spring and Vice Versa)

03.26.2010
| 4881 views |
  • submit to reddit

Java EE 6 and Spring 3 became very similar - at least the resulting architecture and even design will differ only in details (see also Juergen Hoeller comment). I don't expect differences in development lifecycle either - e.g. Glassfish deployment (changing a JPA entity or a Session Bean) takes only a few hundred milliseconds - but you could achieve the same easily with Spring as well (there is no reason, why not).

Spring also comes with own server. Spring has (since October 7th, 2008) similar maintenance policies to opensource servers with commercial support. If you would like to have patches for an older Spring-version - you will have to buy commercial support from SpringSource / VMWare. For serious projects you will have to sign two maintenance and support contracts - one with your application server vendor and the another one with SpringSource. That is very hard to justify having Java EE 5 / 6 in place. In mid term I only see this two options:
  1. Deploying Spring on the "proprietary" tc Server
  2. Deploying Java EE 6 applications without Spring (you could build them with Spring support, but deployment to production will be the issue)

All the migration projects will also have to make this decision, whether they will stick with Java EE, or migrate straight to Spring. This decision has nothing to do with technology - and a lot with business / strategy / politics. You could of course build Spring from source and deliver a binary by yourself. Delivering an uncertified, un-indemnified "custom" Spring-build would be impossible for "mission critical" and very hard for most commercial projects. The future of Enterprise Java is very clear - full stack Spring or full stack Java EE - but no mix any more.

From http://www.adam-bien.com

Published at DZone with permission of its author, adam bien.

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

Tags:

Comments

Ronald Miura replied on Fri, 2010/03/26 - 8:50am

To DZone:

If you are going to 'republish' content from other blogs, at least include a link to the original article (http://www.adam-bien.com/roller/abien/entry/future_of_enterprise_java_is), instead of the main site (http://www.adam-bien.com/) as you usually do.

Jonathan Fisher replied on Fri, 2010/03/26 - 9:23am

I'm not sure why I follow that you're 'only option' is to deploy Spring Applications on Spring Server? Whether or not you have a maintenance contract for SpringFramework seems to be irrelavent, can you elaborate on this please?

Reza Rahman replied on Fri, 2010/03/26 - 4:11pm

Adam,

Great job as usual. I do indeed agree that the case for Spring/Java EE integration is much weaker with Java EE 6 than it has been with Java EE 5 and J2EE 1.4. Plotting a chart forward, with Java EE 7 I think we will see two very distinct camps evolving that have very little in terms of common ground.

Cheers,

Reza

Liam Knox replied on Sat, 2010/03/27 - 5:55pm in response to: Jonathan Fisher

I agree. The notion that Spring is only used via tc or dm server is complete non sense. Within my industry by far the most common deployment is stand alone in vanilla Java applications.

Comment viewing options

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