The Java EE 6 proposal (JSR 316) was published today. I believe that this will be the most important revision of the platform since it was released nearly 10 years ago, and that it should be welcomed by users of the technology. Interface21 is happy to be a supporter of this JSR, and I am looking forward to contributing to it.

Java EE (known as J2EE for most of its history) has played a valuable role in creating a market for Java middleware. However, over those 10 years, important issues have emerged with the platform, such as:

• The need for a Java EE compliant server to be bloated with a range of functionality that is of little interest to the vast majority of users
• The fact that enterprise requirements have changed since J2EE was envisaged and that a "one size fits all model" is less and less appropriate
• The fact that enterprise Java has been greatly strengthened by the emergence of frameworks (especially in open source) that make developers more productive and their production applications more efficient and maintainable
• New challenges such as Ruby on Rails, and even .NET, showing that, in a time of rapid change and innovation, a cosy 2-3 year release cycle imperils the entire platform

Java EE 6 is an important revision of the platform that has the potential to address all of these issues.

It may also have the potential to address another issue: the fact that if EE vendors need to certify against a huge range of functionality that most of their customers will never use, meaning that it's hard for them to keep up with the specs, that it's a challenge to make stable upgrades, and–importantly–that the likelihood of new entrants in the Java EE market is nil. The last point is concerning, as it's not in the interests of users for EE servers to be a cosy franchise for the incumbents. To bear out the difficulty of doing a new platform release: At this point, to my knowledge, BEA is the only one of the market leaders, to be Java EE certified, although the Java EE 5 specification has been final for months. And the most valuable new parts of Java EE 5, such as JPA, were ready in WebLogic for months before the final release, unable to be released in a GA product while issues were resolved around some technologies that most WebLogic users will probably never touch.

Enough of my interpretation: let's go straight to the proposal and hear from the source:

In the past 8 years, the Java EE platform has grown and matured, and is now able to cover a wide range of enterprise and web application development needs. In addition, the Java EE platform has fostered a vibrant community and marketplace for additional technologies, frameworks, and applications that work with the platform. Some of these provide facilities that are missing from the platform. Others provide alternatives to platform facilities. A major theme for this release is to embrace and support those technologies as part of the overall Java EE landscape, while also continuing to simplify the platform to better target a wider range of developers. To that end we propose two goals for this release – extensibility and profiles.

A few years ago, this would have been heresy. I was a heretic at the time, but I never wanted to be a heretic. Java EE is finally taking into account the bigger picture, instead of imagining that it would ever provide a good solution for all user requirements. With Java EE 6, the EE platform is partly reintrepeted as the central point of agreement underpinning a choice of solutions: the fertile earth that lets a thousand flowers bloom. It's been encouraging seeing this kind of bigger picture thinking grow within Sun: consider their embrace of JRuby, and recognition that, like the EE platform, the JVM is the base for an ecosystem rather than being tied to a single language.

It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers. Instead, we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform.

Again, great stuff. The fallacy that technologies shipped with the platform were "better integrated" with the server infrastructure than these "interesting and useful technologies" was long used by server vendors to confuse users and prevent innovation. (Fortunately, nearly all of them have long since stopped doing so: for example, consider IBM's part in the certification of Spring on WebSphere).

The key here is innovation. Some technologies naturally progress at different rates: notably, on one hand, server infrastructure and wire protocols (which change fairly slowly and benefit from standardization); as opposed to the "interesting and useful" technologies that sit on top of it that need to change at a way faster rate and which standardization has largely failed with respect to.

The reach of the Java EE platform has become so broad that it has lost some of its original focus. To refocus the Java EE platform on particular classes of developers and applications, we propose the introduction of Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both. In addition to defining the base Java EE platform, this specification will define the rules for referencing Java EE platform technologies in Java EE Profiles.

Profiles are a great step forward. At last, users will have the power to shop around for what they want, rather than what a specification committee thought they wanted, 2 years before the users start building the application. It's high time that a Soviet style command economy was replaced by some healthy competition. To follow on from my previous point: whereas in previous revisions, the EE platform tried to dictate how you built applications a bit like a Soviet Five Year plan, in EE 6 the role of the platform is more like that of the framework of laws in a Western country, that ensure that people can compete and acts freely as individuals, while agreeing on the rules of the game for the advantage of all.

It's clear that users of enterprise Java technologies have already identified a number of profiles. Today's web applications, SOA applications and financial middleware, for example, have quite different requirements of server infrastructure, although different parts of Java EE have value to offer for each of them. In particular, the batch and headless middleware users have been neglected by Java EE thus far; at last, there is hope for them in sight within the potential of Java EE 6.

The use of profiles is one tool to address the ever increasing size of the Java EE platform. It's also the case that some technologies included in the Java EE platform are no longer as relevant as they were when they were introduced to the platform. There needs to be a way to "prune" these technologies from the platform in a careful and orderly way that minimizes the impact to developers using these technologies while allowing the platform to grow even stronger.

I hope that this is followed through. Let's suppose you have a Java EE 5 server (which your vendor may or may not be able to provide you in an acceptable timeframe). You are the proud owner of a product that supports EJB CMP 2.0 and even 1.1. Remember the public instance variables in CMP 1.1?? You can still enjoy them. This is ugly prehistory that deserves to be forgotten, rather than bloating today's products. If there are any applications out there still running on this stuff, they can crawl out the last years of their existence on an older server until someone puts them out of their misery.

It is great to read in the proposal "EJB CMP – effectively replaced by Java Persistence". A big theme about this release is making EE more relevant in the world of 2007, and removing or making optional old failures is a great statement of that, with real practical benefits for users and vendors who bring products to them.

Interface21 is looking forward to working with Sun and the other companies and individuals on the EE 6 umbrella group and related expert groups to make EE 6 as strong a platform as it can be.

As I said, I never wanted to be a heretic. Essentially the vision of J2EE without EJB (which I coauthored with Juergen Hoeller) was not to trash J2EE, but to help it to prosper by being honest about the bad apples in the barrel and the need for standardization to be tempered by innovation. The Java EE 6 proposal seems to allow this to happen, and I am delighted that I can join the congregation. Let me quote from that book, most of which was written almost 4 years ago. Note the emphasis not just on criticizing EJB but stressing that the big picture of J2EE is what really matters:

J2EE is still a relatively young technology. It’s not surprising that it’s imperfect. It’s time to take stock of where it’s worked, and where it hasn’t worked so well, so that we can eliminate the negatives and enjoy the positives. Because J2EE contains a lot, this essentially means identifying the subset of J2EE that delivers most value, along with some supplementary infrastructure we need to harness it most effectively.
…
You may be wondering, “What’s left of J2EE without EJB?�
The answer is: a great deal. J2EE is much more than EJB. Many J2EE developers believe otherwise, and will tell you so when they see this book on your desk, but a dispassionate analysis of what EJB does, and what J2EE does overall, shows that EJB is only a part of a much bigger and more important picture. J2EE is essentially about standardizing a range of enterprise services, such as naming and directory services (JNDI), transaction management offering a standard API potentially spanning disparate transactional resources (JTS and JTA), connection to legacy systems (JCA), resource pooling, and thread management. The true power of J2EE lies in these services, and this standardization has done great service to the industry.

I believe that supporting Java EE 6, given its aims, is consistent with my position on J2EE, expressed in J2EE without EJB and elsewhere. For example, another central theme of J2EE without EJB is the role that standardization should play and where it's better to have competition among frameworks to foster innovations:

While an open (or at least partially open) specification process is positive, I think one of the biggest advantages of J2EE over .NET is the richness of Java/J2EE open source software…
As we've seen, orthodox wisdom on J2EE architecture is out of step with real-world experience. Some of the J2EE specifications are also, to a lesser extent. I feel that we're at an important crossroads in the evolution of the J2EE platform. It clearly needs to evolve and innovate to survive and prosper. Yet the specification of the fundamental enterprise infrastructure such as JTA, JAXB, JDBC and the Java language itself means that there's scope to innovate on how that infrastructure is accessed without destroying the benefits of a consistent, standard approach to the toughest, low-level problems of enterprise software.

When I wrote those words in 2003, I did not anticipate that the Java EE expert group would eventually use the term "extensibility" to capture the same idea. It's a pleasant surprise.

I believe that the enterprise Java community should welcome Java EE 6, and should welcome Sun's willingness to move with the times and take the choices that will strengthen the enterprise Java platform as a whole. There's a lot of good in J2EE/Java EE, but some of the problems have obscured it. Java EE 6 should change that!

Similar Posts

• VMware vFabric Powers Cloud Application Platform Vision
• The Biggest Loser's Next Contestant: Java Bloatware
• Job Trends: Tomcat, Spring, Weblogic, JBoss, EJB
• Spring 3 on a Java EE 6 server
• dm Server project moves to Eclipse.org