Profiles & Extensibility Major Refactorings in Proposed Java EE 6

| by Scott Delap Follow 0 Followers on Jul 03, 2007. Estimated reading time: 4 minutes |
The Java EE 6 (JSR 316) proposal was published today. InfoQ has covered community ideas for the upcoming release of Java EE in the past. Two major themes for release are extensibility and profiles:
...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.


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.


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:

  1. 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.
  2. 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!

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Pruning by Corby Page

As Rod says in his blog, "I hope that this is followed through."

But the track record isn't great. Look at the glacial speed of pruning in Java SE. I can't really figure out why things would be much faster in the Java EE environment.

I look forward to seeing the profile definitions.

Re: Pruning by Rod Johnson


I agree: the track record on pruning isn't great. Remember: you can help. I would encourage the community to try to make sure this is followed through--and that the expert groups listen to their feedback in general. You can send emails to the expert groups, and I'm sure that many members read forum threads such as this.

One of the reasons I feel good about getting involved in this effort is that I think that there's a real will from the spec leads to improve in areas where EE hasn't done so well. And to listen to feedback from the wider community. This should not just be about a group of vendors.


"Support" by Rod Johnson

Btw when I said that I (and Interface21) are "supporting" the JSR I meant that we are formally "supporters" of the proposal in the JCP sense, not merely that we think it's a Good Thing (which we do). And we will be involved on the umbrella expert group and other Java EE 6 JSRs.


Re: by Brian Edwards

Thanks for the clarification. When is the Spring App Server coming? ;P

In the year 2020... by Thom Nichols

Ooh man... We're not even using Java EE 5 yet, and once it is supported by WebSphere, Lord knows when the middleware group will migrate.

I'm 24 and I think I'll be retired before I use JEE6 professionally :(

Re: by Oliver Gierke

Thanks for the clarification. When is the Spring App Server coming? ;P

It's already available with the BEA Weblogic ;).


fantastic news! by Floyd Marinescu

This is fantastic news and I think this new pragmatic approach will mean that Java EE and EE standards process in general will regain their prominence and maintain relevance in the long term.

Interestingly, the fact that J2EE as a platform was defined as a big umbrella spec was very important and very successful back in 1999-2000. It's what the industry needed in order to migrate away from the 30+ vendors specific platform programming models and to a standard.

Today however, migration to 'best tool for the job' approach is something the industry has already been migrating too on its own (the sheer volume of pure Tomcat installations being a good indicator).

This move is absolutely needed in order for Java EE 6 to matter going forward, congrats to all the people behind this spec for making the hard but necessary choice.

Re: In the year 2020... by Guru Prasath

I'm 24 and I think I'll be retired before I use JEE6 professionally :(

I am 27 and I am going to learn JEE7 from my grandson. Coooool...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss