dagblog.
← Archive

J2EE 6 takes a step in the right direction

Roman Pichlík ·

JSR 316. That’s the number of the Java EE 6 specification, which will turn the wheel of history forward and never take a step back. That, more or less, is how a slightly twisted paraphrase of a line from the film of Miloslav Švandrlík’s novel Black Barons might sound.

I greatly enjoyed Java EE 6 Gets it Right by Rod Johnson, which praises what’s planned for the specification. I’m glad Rod Johnson and Interface 21, the company behind the Spring Framework, will finally be involved in this tremendously important specification.

I’m also pinning hopes on Gavin King. He’ll have a word for JBoss and bring real experience of using J2EE technologies in the Seam framework. King has already come out with a substantial wish list of changes he’d like to get into the specification or at least discuss.

Before getting into the spec, I’d like to quote one of King’s proposed EJB improvements. I’ve always said it should have been part of EJB 3.0, and I’m happy to bring it up whenever I meet an IoC theorist.

Optional business interface
The fifth item on my wishlist is a pure ease-of-use concern. Currently, EJB mandates that all session beans have some @Local or @Remote interface. This was not an unreasonable requirement when session beans were understood to exist in a business tier, with a well-defined API sitting between the business logic and the client. But now that we’re using session beans everywhere — even for presentation logic — it’s clear that defining the local interface for every bean is simply a PITA. Unfortunately, we realised this much too late in the process of writing the spec to do anything about it in EJB 3.0 (I’ve kicked myself many times over this, I should have known better). Especially in an environment like Seam, where the only client of a bean might be a JSF page with EL expressions, the interface looks totally redundant!
The interface should be optional, and when it is missing, the public methods of the bean class should be taken as the business methods of the session bean.

The enterprise edition’s sixth release focuses on three areas.

  • Extensibility
  • Profiles
  • Pest control

Extensibility

Extensibility takes away the monopoly of the technologies provided by an application server and replaces it with the option to integrate technologies according to the application’s needs. The server will offer extension points where technologies used by the application can integrate with server services. That means, for example, that Hibernate or Spring can be tightly integrated with the services of the application server. What used to require workarounds should be transparent.

Profiles

Profiles define the set of technologies needed for a particular area. A web profile, for example, might define JPA, servlets and JSF. An application server can therefore comply with the specification at the level of a narrower profile. Most applications use only some of the technologies, so there’s no reason to wait months for certification of the whole server. Profiles should get the specification into production much sooner.

Pest control

Common sense has finally prevailed. Technologies left over from prehistoric times will be removed so they don’t bloat the J2EE family. Their successors will remain. The specification already mentions CMT entity beans, replaced by JPA, and JAX-RPC, replaced by JAX-WS.

The following additions are planned.

Existing specifications will also be revised.

From the first outline, EE 6 really looks as if it’s driven by how people currently develop applications rather than how a JCP expert group thinks they should. Extensibility and profiles offer something like what the Java platform introduced with scripting languages. There’s a JVM that acts as a foundation for several languages, beyond the JVM and one language. Developers choose which language to use, and the same will be true of technologies that can integrate with the application server.

Even application server vendors seem to have realized that integrating works better for them than trying to destroy or warn people off technologies outside the original J2EE specification. Developers get to choose their technology, and easy integration with application server services will stimulate demand for the servers themselves. Just as the saying goes, the wolf gets fed and the goat stays whole.

I expect people like Gavin King and Rod Johnson to simplify J2EE technologies further so using them doesn’t require mountains of tutorials, stacks of theory and a ton of design patterns. At the end of 2008 we’ll see what they managed to deliver and where they bit off more than they could chew.

Medium version

Related articles

Related CZ Podcast episodes