...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.Extensibility
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.
Profiles
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.
This expert group will also define the first version of a Java EE Web Profile - a subset of the Java EE platform targeted at web application development. This profile will provide a more gentle introduction to the Java EE platform, providing only those technologies needed by most web application developers, without the enterprise technologies that sometimes confuse such developers...
The proposal also advocates using profiles to prune the ever increasing size of the Java EE platform. It is suggested that the process used by the Java SE export group be used for Java EE as well:
- The Umbrella Expert Group (UEG) for release N of the platform decides to propose that a particular feature be removed. The specification for that release documents the proposal.
- The UEG for release N+1 decides whether to remove the feature from that release, retain it as a required component, or leave it in the "proposed removal" state for the next UEG to decide.
The proposal lists a number of JSR as candidates for inclusion in Java EE 6 such as JSR-237 Work Manager for Application Servers and JSR-299 Web Beans. These are in addition to previously included technologies such as servlets, EJB's, and JSF. A number of API's such as JSR-168 Portlet Specification, JSR-170 Content Repository for Java technology API, and JSR-225 XQuery API for Java (XQJ) are deferred to be considered for inclusion in future releases.
Interface 21 CEO Rod Johnson has written a lengthy commentary on the proposal going so far as to declare his support for the JSR:
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...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!