J2EE 5 is the new competitive edge. I remember reading the first whitepapers about C# and being impressed about how easy it was in the .NET framework to write a webservice. None of the complicated programming model we had in J2EE with API's and EJB's and XML and yada yada, just raw support at the language level for tags. Writing a webservice meant writing a C# object and tagging the methods for WS support. That was 3 years ago, it sent shivers down my spine, they were ahead on language.

Today, java has support for annotation since JDK5.0. We are already using it to transform the way we think about, design, implement and indeed standardize middleware in the next generations of J2EE. Where J2EE has a big edge over .NET is first in a large installed base but most importantly in the quality of the services.

The language of C# had some syntactic advantages, fair enough, the java camp caught up. But the services, meaning the actual "words" you can use to program are not up to speed in .NET. Quality of the services was always J2EE's advantage. Cache technology was always ahead. Take for example persistence and you will see that compared to the state of the art in Java (with solutions like Hibernate) the .NET framework really has some way to go, indeed they have no proper standard object to relational database toolset to speak of, just souped up JDBC. Now that we have the language let's make sure we standardize the words to STAY ahead.

We have been doing the right thing in the spec committees, namely simplifying the programming models to support POJO and annotations at the specification level by leveraging JDK5.0. Across the board in EJB3 for example, we have completely revamped and simplified the way developers interface with and program to middleware. Instead of complex API's and tons of XML, developers can tag their objects with annotations. Developers have already adopted this approach.

The wave of microcontainers, a departure from the traditional marketing of J2EE as heavy weight containers, is the clear message we are embracing and extending in this release of EJB3 and a message that has already been accepted by developers. Many packaged microcontainers are already on the market. The growing popularity of these lightweight programming models in the open source community is proof positive that our efforts come at the right time. Developers are pointing in the right direction.

We have delivered on a microcontainer spec, with speed, efficiency and no sacrifice on performance or industrial-grade features. I am personally proud of JBoss's involvement in the EJB3 spec committee, since JBoss AOP and Hibernate, had great experience in how these lightweight programming models worked and we pioneered a lot of these features.

The discussion today in the spec committee really seems to narrow down on the inclusion of persistence. This yields two subquestions.

First, the technology. The technology is ready, we shouldn't drag our feet. There seems to be a fear from some vendors that they will not be ready in time with their own implementations. Not only is this ludicrous, there are a wide variety of vendors supporting pojo persistence, including all the JDO vendors but also open source implementations. We are not standardizing products, we are standardizing best practices in these products, with years of experience under our belts.

I am glad the JDO vs EJB noise has died down. I am also glad the folks involved in JDO found a home in the EJB spec committee. We are not merging the technologies, we are merging people and leveraging years of POJO persistence experience and applying it to the relational subset. This should in fact speed up the specification process. We have got perfect storm conditions on the persistence front.

The second issue is the brand. The EJB brand must introduce pojo persistence to the market. I can understand that the EJB brand is an emotional topic for many of the JDO folks that have joined the EJB spec. I am glad SUN finally took the difficult decision to merge the people for one tool. From a marketing standpoint, I would invite the JDO folks to embrace and ride the EJB marketing machine as a way to get their dream of pojo persistence in the hands of many. No offense but the market for EJB technology is in the billions, the market for JDO wasn't, embrace that distribution and that brand and move on for the sake of everyone.

Bottom line, we are all better off pushing a POJO technology vision in persistence under the EJB brand. There are no losers today, just winners as we standardize on one pojo persistence view. With the advent of POJO annotations we are moving to a world where the view of the container becomes a lightweight one. The persistence, EJB persistence is useable "outside the container", meaning outside the traditional J2EE container and usable inside a microcontainer. The emphasis is on J2SE with managed environments. In a sense this is the JDO legacy to EJB. Let's all embrace and extend it.

EJB3 will have a long life, as it is the first to introduce this long awaited microcontainer, lightweight programming view of the world. EJB services can now be used on J2SE with these microcontainers. The crown jewels are individual services, without them microcontainers are empty shells, the EJB brand represents quality for a wide set of services. We must retain that branding value and association and introduce to a mass of J2SE developers the power of the new model, persistence first and foremost.

All of this is already used in production, today. Many vendors are on the market, many packages await branding standardization for further penetration of the market. J2EE will remain strong. JBoss has has an alpha on the market that implements most of the API today. The call to action, at least for the naysayers, is one of "inaction". At least just let us do our work instead of looking for ways to delay, let us collectively finish our standard work, remove what wasn't competitive embrace and extend what is. It ain't that hard, just listen to what developers want.

marcf