Blogging about software development for the enterprise. Strong focus on Java Enterprise Edition (Java EE) and more general Java platforms.
You'll read a lot about Conferences, Java User Groups, Java EE, Integration, AS7, WildFly, EAP and other technologies that hit my road.

Tuesday, August 18, 2009

J2EE to JEE5 or JEE6 Migration

09:20 Tuesday, August 18, 2009 Posted by Markus Eisele
, , ,
More and more mature projects think about migrating these days. After a couple
of years of successfull development it is time to decide weather to
switch to updated enterprise java versions or to keep the old ones.
Looking out for the JEE6 release, which is getting closer each day, I will have
a look at some things to keep in mind if you are thinking about updating your J2EE

Migrate to JEE5 or JEE6?
Even if the final version of the JEE6 specificatione is getting closer, there are
only few pre-release versions of JEE6 appservers available already. And with the
late integration of JSR-299 and JSR-330 there are still some major pending changes.
In a business sense, this puts unneeded risk to your projects. If you have some
more time for migrating (target time mid of 2010) it would be worth waiting. Otherwise it will be best to update to JEE5.

Migrate to JEE5 or keep J2EE?
Basically these are your choices. Keep it or migrate. The main decision driver are
the business requirements. Do you have to update your application server version but
keep all the code and no need for making changes? Go ahead and rely on the JEE5 backward
compatibility. You have bigger changes to do? Possible performance problems? Expensive
refactorings planned? Give JEE5 a chance and migrate. Third option is to mix both strategies.
Only change parts of the implementation that needs to be touched and leave the rest J2EE style.

Effort estimation
The migration effort highly depends on the implementation quality and complexity of your application.
Starting with plain webapplications up to full blown CMP1.x/2.x projects your technical complexity
grows and the migration efforts will do so, too. The worser your code quality and arcitectures are,
the bigger are your migration efforts. Following this, the worst kind of migration project would be
a CMP 1.x enterprise applications with hardly any architectural concepts, bad documentation and
really poor code quality.

Risks and Problems
Most risky is the migration not only from one specification version to another but from one
appserver to another verdor's version. In this case you probably would have to cope with
vendor specific solutions (proprietary classes and/or features, deployment descriptors, specific behaviour).
Another problem could arise from special frameworks (e.g. Weblogic Diagnostics). If you depend heavily on
such features, you should probably try to no change the application server vendor in a first step.

Requirements for migration
Your project should meet some requirements before you think about migration.
You should have:
- ... some testcases at hand. Especially if you are going to migrate the persistence layer!
- ... a testdatasource available.
- ... two test environments (old and new)
- ... code that compiles with JDK 1.5 (check for incompatibilities/deprecations)
- ... thought about moving your development project settings to a JEE5 project.