A cup of Java

There is no doubt that Java EE 5 is a big step forward from the J2EE 1.4 specification. The two major improvements are the replacement of the entity beans with JPA for ORM and of course the introduction of Java 5 annotations. You could state that the need for annotations is driven by two reasons. One is to diminish the need for endless XML configuration files. And the second one is to help people stop thinking that aspects can be applied to methods without impacting to code itself. Most EE 5 annotations imply more than just a configuration parameter. For example,

sessionContext.getCallerPrincipal();

only really makes sense on methods annotated with

@RolesAllowed("the_allowed_role")

And in case that the annotation really boils down to pure configuration you can still reconfigure an aspect without altering the annotation parameters within the code via the XML file descriptor overriding mechanism.

With all the recent noise about the start of the JCP of the Java EE 6 specification it's time to make up my personal wishlist for Java EE 6. So here we go...

The thing that I'm missing most in EE 5 is decent support for lifecycle management of your business entities. The problem with a J2EE application is that, after it has started, it just sits there waiting for someone to come in and poke the system alive. Most of the time you don't want to 'manually' make the J2EE application to start breathing. So people came up with different solutions out of which the most container-independent is via a ServletContextListener that fires towards a stateless session bean which in turn could start some timers via the TimerService. An interesting design pattern here is to let the ServletContextListener perform a JNDI listing over some predefined subcontext like for example

MyApplication/startup

If the listener finds a component registered in that JNDI context that is also implementing a Startable interface, it can simply start and stop those components. So to make startable components all you need to do is to implement the following interface:

public interface Startable {
   void start();
   void stop();
}

and to register your component under the correct JNDI subcontext via the

@LocalBinding(jndiBinding = "MyApplication/startup/fireMeUp")

annotation, which should by the way not be JBoss specific but be part of the EE 6 spec. It would be nice to see all of this being replaced in EE 6 by some simple annotations like:

@PostStart
public void postStartCallback() {
   // thanks for starting me like the ServletContextListener
   // used to do
}

@PreStop
public void preStopCallback() {
   // thanks for notifying me of a shutdown like the
   // ServletContextListener used to do
}

on your stateless session beans. By allowing a priority parameter on the PostStart and PreStop annotations you could even do simple start-stop dependency management.

I know JBoss has some EJB 3 extension to define JMX services, but this is not exactly what I'm looking for. These services are singletons that have a lifecycle scoped to the application itself. What I want is the lightweight version of this; I only want to receive notication when the system starts and stops, just like if it was handled via the ServletContextListener within your WARs.

Another big missing thing is defining tasks. A task can be very useful to perform for example database cleanups. Right now if you want some task to be performed at a regular interval you need to play with the TimerService. And since it doesn't support cron-expression you end up using Quartz, or at least its cron expression evaluator. What I would like to see is that you could annotate a method of a stateless session bean as follows:

@Task(name = "A Demo Task", preferredScheduling="0 0 * *")
public void pleaseRunMeEveryNowAndThen() {
   // ...
}

The EJB3 container should group all these tasks per application. Then the application administrator could assign each task to a scheduling via some task console that is part of the application server.

While I'm going off: configuration management of J2EE application is another big issue today. How do you capture configuration parameters in your current J2EE applications? You can use the env-entry element within your ejb-jar.xml deployment descriptors. But for most configuration parameters you want something that is more dynamic. Another possibility is to put your configuration somewhere in JNDI. Such an approach works, but you still need to have access to the JNDI tree via some console that is part of the application server.
What I would like to see is that you can annotate session bean fields as follows:

@Config(domain = "MyApplicationDomain1", name = "Initial Amount")
@ConfigConstraint(max = 10000)
@RolesAllowed("admin")
private int amount = 1234;

When the EJB3 container encounters such annotations on a field it should register the configuration parameter in a ConfigService that is application scoped. Each application configuration is divided into different domains. A configuration parameter has a name and an initial value. It can also have value constraints and roles to drive the input validation and RBAC of the configuration console of the application.

And then finally there is input validation. Instead of:

public String concat(String a, String b) {
   if (null == a) throw new IllegalArgumentException(...);
   if (null == b) throw new IllegalArgumentException(...);
   return a + b;
}

wouldn't it be cleaner to just write:

public String concat(@NotNull String a, @NotNull String b) {
   return a + b;
}

and let some EJB3 interceptor interpret the method parameter annotations and throw IllegalArgumentExceptions if he feels like. This feature would be very similar to the Hibernate input validation annotations that you can put on your JPA entity fields.

Definitely to be continued.