Adam Bien's Weblog

Wednesday Sep 06, 2006

Java EE 5 applications more portable?

J2EE 1.3/1.4 specifications were relatively easy. The reason: the hard stuff like locking, concurrency, versioning, eager/lazy loading or primary key generation wasn't specified. In projects such functionality was needed - so developers had to use vendor specific stuff to provide the required (actually essential) foundation. Application servers offered these services as additional functionality, which was configured and "activated" using proprietary deployment descriptors. The problem here: even basic functionality like locking had to be specified in vendor-specific descriptors. There were also subtle differences between the application servers. The main work porting J2EE 1.X applications was to take into consideration this differencies and translate them between vendors (often mission impossible :-)). Tools like XDoclet were crucial, but XDoclet didn't supported all vendor specific extensions of different vendors. The meta-tags varied also between vendors so it wasn't pleasure to built portable applications.

The Java EE 5 simplified the programming model, but the specification is more complex now. This is actually good, because now the vendor specific functionality is standardized. So large, vendorspecific, deployment descriptors are no more needed. Actually no xml-Deployment Descriptor is needed. In case you entity 3.0 persistence is used only a short descriptor (for all entities) is needed. Sample:

  <persistence-unit  name="test" >
//vendor specific stuff



Vendor specific extensions can be provided as key-value pairs - but are not essential. I started with my first Java EE 5 project on JBoss 4.0.4. then moved to glassfish. No recoding or refactoring was needed. I only provided two optional toplink key-value pairs. Now I'm developing with glassfish and deploying to JBoss - it still works. I will then migrate the whole app to glassfish - and I do not expect any problems. The application is rather small (some entities, stateless sessions beans, timer service, webservice client and JMS) but uses most of the Java EE 5 APIs. It is also critical (heating control) :-).

In the practice we will still have to struggle with different implementations and especially quality of different vendors. But the syntactic "war" in vendor-specific deployment descriptors is over :-).

Special Events: Java 8 with Java EE 7: "More Power with Less Code", 13th October, 2014 and Java EE 7: "Testing and Code Quality", 14th October, 2014

A book about rethinking Java EE Patterns


If you stick to nothing but the standard then JEE5 applications can indeed be pretty portable. However in my experience it is extremely difficult to stay within the bounds of the JEE5 specification because you almost always have to rely on vendor extensions for doing things not covered in the holy spec.

JPA is a good example. For a 1.0 version of the spec it is pretty good but just look at the kind of extensions you will find in Hibernate, TopLink or OpenJPA. In my experience you start using these to work around limitations in the spec and thus you are bound to a specific implementation.


Posted by Stefan Arentz on September 12, 2006 at 06:53 PM CEST #


yes, but it is a huge step forward. Everything, what was "proprietary" extension is standardized now. Deployment Descriptors are not necessary. So it is much easier to build portable applications without huge XDoclet-headers :-).
Thank you for your comment,

Posted by Adam Bien on September 12, 2006 at 07:22 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments