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

Lean Java EE 6 Without Spring And Spring 3.0 in the Java EE 6 World: Summary and Conclusion (eJug Session)

07.06.2009
| 9265 views |
  • submit to reddit

It turned out, that both components models are surprisingly similar. You could migrate an EJB 3.1 based application, almost without any additional effort to Spring (search and replace for annotations). It is even possible to run an EJB 3.1 applications without ANY modification just tweaking Spring a bit. 

Although both technologies are almost identical from the programming model perspective - the philosophy is totally different. Spring "is not just a glue-framework" (Juergen clarified that), rather than complete solution - the full stack. Spring was architected as a layer above the actual application server. The idea: you can upgrade your APIs updating Spring and not touching the application server. This is especially important if you have to use the "heavyweights" application servers (=they come with at least with one DVD to install and the installation takes several hours :-)) without having any control about the version. The Dependency Injection is only a small part of the framework. Spring offers you from DI, over Spring MVC with REST support (similar to JAX-RS) and even monitoring. It actually replaces the most parts of the application servers with own services.

What was also interesting - Spring is exactly NOT Convention Over Configuration. The idea is to configure everything is needed explicitly, without relying on conventions. But you don't have to configure everything over and over again - you can use "Stereotypes" for that purpose. Stereotypes are "Meta-Annotations". So you can introduce your own annotations, using "annotation inheritance". Then you only will have to use your own shortcuts (e.g. @Service, @ServiceFacade etc.). 

The philosophy of EJB 3.1 is exactly the opposite. It is not a complete solution, rather than "only" a component model for transactional, serverside applications. It comes with a set of suitable conventions, so you don't have to configure anything an rely on the existing conventions. Neither annotations (except @Stateless), nor XML-configuration is needed. The EJB infrastructure has to be available at the application server - so you only have to deploy your application - without the EJB-"framework" (Glassfish EJB 3 container is about 700kB) bits. The DI are not as sophisticated as Spring's, JSR-299 or JSR-330, but actually absolutely sufficient for most projects (at least my projects :-)).

EJB 3.1 components are aimed to run directly on the server, without any indirections. This also means: you can only use EJB 3.1 in case your application server has support for it. But: I also saw some projects using openEJB container to run EJB 3.1 on tomcat :-). Whats also true: SAP, IBM Websphere, BEA Weblogic, Oracle OC4J, JBoss 4 and 5, openEJB / Geronimo and Glassfish v2 (+several others) comes already with EJB 3 support. In that case your components become vendor neutral. You can move them around, without changing any EJB 3.X setting (JPA is harder to port across different providers). You will, however, have to test them on different servers. 

Spring will support parts of the Java EE 6 specification - except the @Stateless annotations :-). We (Juergen Hoeller, eJug audience and me) discussed a bit longer this issue. We have different opinions on this: If I were SpringSource, I would support @Stateless and few EJB 3.1 annotation to make the transition more easy. Juergen said it would be hard to support @Stateless in completely compliant way - and he would expect some criticism then. But: the differences could be documented - so there should be no problems as well at this point.

In the practice, however, the support issue may be important as well. It is more and more important to provide the support for the full stack from one company. I guess in future you will see SpringSource only (e.g. dm server), and Java EE 6 only solutions. These decisions will be not driven by technical, rather than political / strategic reasons. Imagine Spring will run on a commercial application server in production and something goes wrong. Such support issues could be really "exciting". Some of my involvements in the resolution of multi-vendor J2EE-only support cases were already funny enough in the past :-).

I hope this is a unbiased description of this event - otherwise please free to drop me an email or comment. The eJug meeting was well organized at a nice venue - the upcoming sessions are interesting as well. My (English) slides are based on some contents from my "Real World Java EE Patterns" book -the slides should be available for download from eJug. See the German (eJug) summary as well. Thanks Juergen Hoeller for the invitation

Btw. I will cover some "extreme" EJB 3.1 / REST with Convention Over Configuration approaches in the upcoming Java Magazin (German only :-)).

From http://www.adam-bien.com/roller/abien/entry/java_ee_6_ejb_3

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

Comments

Ronald Miura replied on Mon, 2009/07/06 - 12:45pm

The main strength of EJB is also its main weakness (aside from being crap before 3.0). It's a specification, and a big one.

I don't remember having any problems with portability between containers when using Spring. Developing on Tomcat and deploying on, say, Websphere, is completely viable, since we are depending just on the Servlet spec, which is pretty simple and straightforward (so, doesn't leave much room for introducing incompatibilities between different vendors and versions). Spring is a product, does what it does, and the guys have been doing a great job (so far) on maintaining backwards compatibility, or making it clear when things will break (which is very rare) between versions.

Since EJB is a spec, every vendor may interpret it in a different way. Things that look simple may introduce subtle differences in behavior that will be impossible to find until deploying on another container, which is, often, production. EJB 3 simplified its programming model, but AFAIK, it didn't change the deployment model (vendor-specific descriptors), and still has lots of holes (classloader isolation). If you use the container just to spare you to call 'new', you're mostly safe, but in real projects, it's very easy to bump into this kind of problem.

The same problem appears in JPA, for example. If you're using it in anything other than one-page tutorials, you probably are tied to the implementation you used when developing. Many things are unspecified (cache), forcing you to use vendor-specific features. You may even be using product-specific features without knowing! For example, Hibernate accepts collections as parameters (for IN clauses), JPA don't say anthing about it. HQL's syntax accepts queries like 'FROM Entity', whereas JPA requires 'SELECT e FROM Entity e'.

Specs are good (in general), but you have to acknowledge that you're using a product, not a spec, when developing an application. Or, be very careful to not step outside the spec (thus, you have to READ the damn spec document), and hope the vendors interpret it the same way you do.

Oh, the Wicket+Spring+Jetty combo takes 2~5 seconds to bootstrap (although Hibernate may take some more, depending on the number of entities you're mapping). JBoss 5 takes about 40, with no app deployed.

adam bien replied on Tue, 2009/07/07 - 3:08am in response to: Ronald Miura

We had to port EJB 3 from server to server (WLS --> JBoss --> Glassfish) and it worked surprisingly well. You have to test your application of course - because of thread pooling and performance differences - but this is true for every framework. Glassfish v3 starts in few (2-10) seconds. You don't even have to redeploy your application - saving classes is sufficient - even the HTTPSession remains preserved. Such a deployment takes about 2 seconds. But even Glassfish v2 was fast: Deployment performance of 660 JPA Entities and 80 EJBs ...and why you are using WebSphere - just for Servlets? :-) Btw. EJB 3.0 are running in WebSphere 6.1/7.0 also surprisingly well.

Rainer Eschen replied on Wed, 2009/07/08 - 3:35pm

Nice to hear that EJB 3.x delivers similar features than Spring. Although, one important difference is that I still need an EJB container to use it and have more maintenance efforts finally. Interesting is yur OpenEJB on Tomcat example.

Maybe we should rethink the old J2EE container idea and come back to full-blown executables that have everthing on board. I have no problem to find a complete servlet container in such an executable anyway. All this war/ear creation and deployment cycle stuff is still pretty time-consuming during development. To add some jars to the executable and start an application would be much faster.

Ant Kutschera replied on Wed, 2010/05/12 - 7:46am

@Rainer: Yes, we should rethink the old J2EE container idea! Have a go at downloading GlassFish 3 - you'll be up and running before you know it. I was very pleasantly surprised (check out my own blogs on DZone for an article that describes how to configure GlassFish), and have questioned my needs for Spring in the future...

Comment viewing options

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