adam bien's blog

Java EE 5 vs. J2EE 1.4 and some arguments for switching. 📎

I'm over and over asked again about arguments for migration from J2EE 1.4 to Java EE 5. Only some of them:

Development:
  1. To develop a Java EE application only a third of all J2EE artifacts is needed. A Session Bean consists of an interface and a class (in J2EE Home, Remote, Class and Deployment Descriptor). You do not need the Service Locator any more, references can be directly injected.
  2. To deploy an CMP 2.0 Entity and Local Home, Local, Class, Deployment Descriptor and an associated Value Object was needed. In EJB 3 world the JPA entity is a simple class and can be detached for transport.
  3. JPA is more powerful - the usage of DAO-pattern can be reduced (another three classes are gone).
  4. Annotations are typesafe - no more "XDoclet" hell. A successful deployment is more likely.
  5. Java EE 5 comes already with installed JSF frameworks. No additional frameworks are needed for an average application.
  6. The tooling is much better.  Eclipse with "dali" plugin supports the developer in OR-mapping of JPA, or JBoss-IDE in the overall process. In Netbeans 5.5/6 (out off the box) provides a support for dependency injection, scaffolding (generation of JSF pages from JPA entities, or generation of JPA-Entities from existing tables), and JMS (injection of queues etc.).
  7. JPA entities are object oriented and polymorph. They do not have to be persistent data containers/mappers only- so they also realize business logic and can be real domain objects. This is a huge advantage in more complex applications over "anemic" CMP 2.X entites regarding development as well as maintenance.
Maintenance:
  1. The EJB 3 specification is more complete - so vendors are forced to implement more standardized functionality. Impact: Java EE 5 applications are portable between different vendors. In general case an application can be deployed without proprietary deployment descriptor.
  2. The EJB 3 code is clean and lean. There is no need for code generation. The applications are better to maintain because of more condensed code.
  3. EJB 3 can be easier executed and so tested outside of the container with less effort
The developer's productivity can increase significantly - even without special tools. In the past I used Eclipse + WTP, with JBoss IDE (for the autocompletion of XDoclet-Tags), a predefined Ant-Script with XDoclet task which generated the boilerplate code in J2EE courses. The students were able to built a basic (CRUD) J2EE application with very limited UI capabilities in five days (J2EE Patterns courses with experienced students).
I did the same in Java EE 5 space with a basic editor (I used Netbeans 5.5 in the last courses without additional templates or tooling). The students were to built the application with JMX, WebService-Support, JMS-notification,  and sophisticated Swing UI and JSF support in ...three days. With Visual Web Page (a Netbeans extension), some stundents were even able to do more and created amazing looking JSF-UIs (Grids).