Java EE 7 – I have a (few) dream(s)
If you haven’t used your RSS feed reader lately, you might have missed that Java EE 7 is starting to kick off : JPA 2.1 (JSR 338) and JAX-RS 2.0 (JSR 339) have been voted, Robert Chinnici has talked about it, some conferences have mentioned it… Java EE 7 will happen and quite quickly (Q4 2012). The main focus is the cloud. I will not talk here about the cloud, I’ll talk about everything else (well, not everything ;o)
Java EE 7 is an umbrella specification, meaning it’s made of several specifications. Its goal is to give the other JSRs a common target (here, the cloud) and to make sure these specifications interact well with each other. The Java EE 7 expert group is not responsible for all the JSRs, just the umbrella. That means if the Java EE 7 expert group wants to add something new to the platform (eg. it would be nice to have batch processing into the platform) it will not do it : it will rely on some other spec (i.e. someone else) to specify it and to interact well with the other specs.
As part of the Java EE 6 expert group, I’ve been talking with my fellow expert members about Java EE 7. Like many of them I wish Java EE 7 had new stuff. But new stuff means a new specification, which means a spec lead, an expert group, a JSR, a RI, a TCK and thousands of hours of work. It’s so much work that many JSRs have been started and never ended (inactive JSRs).
Here is a wish list I would like to see in Java EE 7 :
- Flow management : What I really miss in Java EE is something similar to Spring Web Flow or Seam Page Flow. It would be very useful to have a new specification to standardize flow management (for JSF, of course, but something more general letting you manage different sorts of flows). That would mean JSF Managed Beans could be pruned (with CDI we don’t need JSF Managed Beans any more)
- Batch processing : That’s also something missing. With the new Timer Service we have a rich scheduler mechanism. Wouldn’t it be time to get a Batch processing specification ?
- Security : Security is still an issue I think. JAAS is too low level and something higher level and richer would be more appropriate.
- Caching : Talking about inactive JSRs, this is one of them : JCache (JSR 107). We have been using cache for a decade in all the layers of our architecture. We know how to make caches, so why not specify them (JPA 2.0 introduced a second level cache because JCache was not usable).
Ok. So, what do you think of this wishlist ? Want to add something more (and I’m talking about new JSRs here, not improvements of existing ones) ? Ok, and here is the difficult question : is anybody interested in taking the lead in one of these proposals (or a different one) ?
I want to stress out that the JCP is quite an open organisation : anybody can be a spec lead or be part of an expert group. Because it’s a lot of work, it’s true that the lead tends to be taken by big companies that can pay a few employees full time. In my case I’m just an individual expert member (not a spec lead) and I do it for free on my spare time. If you want to lead a spec, you need time, time, time and more time (plus all the skills that a project leader needs). Plus, you need expertise in the area of your spec. When I talk about expertise, what comes to my mind is :
- Flow management : someone who is involved with Spring Web Flow, Seam Page Flow, BPEL or even BPMN. Flow management is a different beast but BPEL or BPMN have a similar base.
- Batch processing : I think of Spring Batch but also, to a certain extent, Map Reduce algorithms (useful in a cloud environment)
- Security : someone involved with security at a large, JAAS, Spring Security, SSO
- Caching : there are so many caches out there, but someone involved with ehCache, JBoss Cache, even Terracotta
So, any brave company/individual/university/JUG who wants to pick up something in this list and become spec lead ? Do you know someone ? Well, I have a few names in my head… but I can’t tell ;o)
Let me know
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)