Skip to main content

Profiles in the Java EE 6 Platform

Posted by robc on February 22, 2008 at 11:38 AM PST

Update: See the related stories on The ServerSide and on InfoQ.

It's been several months since my last update on the work going on in the Java EE 6 Platform Expert Group (JSR-316).

The main topic of discussion in the EG has been profiles. There are several aspects to this, ranging from the number and contents of profiles to the somewhat more general subject of SPIs and pluggability.

By the far the most animated part has been the discussion around the Web Profile, with several definitions being proposed. Personally, I found it very interesting to see how EG members crafted their proposals by following different routes and aiming for somewhat different goals. This is a testament to the activity and liveliness of the platform.

At this stage, we think that the best path forward consists of polling the community for feedback on which definition of Web Profile they'd most like to see adopted by the expert group.

One reaction that people sometimes have is to ask: Why should we choose? So, as a premise, I should point out that profiles come at a cost. As the specification lead for JSR-316, Sun is responsible for delivering a Reference Implementation (RI) and a Technology Compatibility Kit (TCK) for each profile. Additionally, Sun needs to take all the legal and business steps to license the platform and each profile, provide support to licensees (including no-cost support for qualified ones), etc. This does not come for free.

In very practical terms, then, we cannot support a large number of profiles in the desired timeframe for the Java EE 6 platform. Here "large" really means "more than one".

Not all is lost though. One of the driving ideas around profiles is to move away from a big-bang model for the delivery of the platform, enabling smaller, focused communities to forge ahead in the context of a profile they define. It is natural then to achieve as much decoupling as possible from the beginning and push profiles into separate JSRs, to be finalized on their own timeline.

This said, we originally proposed defining a Web Profile as part of the Java EE 6 JSR because (1) it's helpful to have a use case at hand when developing the notion of profiles, as opposed to doing so in the vacuum, and (2) we believe that there is interest in the market and in the community for a web-centered profile of the EE platform. Incidentally, the amount and depth of EG mail that the Web Profile generated more than proved the first point.

To come to the central part of this post, here are the two profile proposals that got the most interest in the EG. I've tried to come up with a characterization of them in five words or less, but in the interest of not attaching strong labels or identifying the proponents, in what follows we'll simply call them A and B. As a reference, I also listed the contents of the full platform in the third column.

(A) (B) Full platform
Servlet 3.0
JSP 2.2
EL 1.2
JSTL 1.2
Servlet 3.0
JSP 2.2
EL 1.2
JSTL 1.2
Servlet 3.0
JSP 2.2
EL 1.2
JSTL 1.2
EJB 3.1 (Lite)
JTA 1.1
JPA 2.0
JSF 2.0 *
Web Beans 1.0 *
EJB 3.1
JTA 1.1
JPA 2.0
JSF 2.0
Web Beans 1.0
JAX-RS 1.0
Connectors 1.6
JAX-WS 2.2
JAXB 2.2
JSR-109 1.2
JSR-181 1.1
JMS 1.1
JAF 1.1
JavaMail 1.4
JSR-88 1.2
JSR-77 1.1
JAXR 1.0

In (B), the inclusion of JSF 2.0 and WebBeans 1.0 is controversial, so we marked them with an asterisk (*). Not coincidentally, these are technologies which could be handled via extensibility (keep reading for more details).

Some clarifications are in order.

"EJB 3.1 (Lite)" refers to the idea of allowing implementations to deliver a subset of EJB 3.1. The contents of this "lite" subset are wholly undecided at this point, but as an example it might include the annotation-based programming model introduced in EJB 3.0, restricted to session beans with local interfaces (only). In other words, you could write an annotated session bean with a local interface and use it in your Web Profile-compliant product (assuming (B) is accepted, that is). But, for example, you could not write a EJB 2.1-style session bean, or an EJB 3.0 message-driven bean, or a EJB 3.0 stateful session bean with a remote interface.

It's important to note that proposal (B) assumes that "EJB 3.1 (Lite)" will exist, but this is a decision that is entirely up to the EJB 3.1 expert group (JSR-318), where it's going to be prioritized against other features. The precise definition of what comprises "EJB 3.1 (Lite)" is also left to the EJB 3.1 expert group, with no particular proposal being put forward as of today.

A second point worth discussing in some detail is related to extensibility, which you may remember is one of the goals of Java EE 6. As a feature, extensibility interacts with profiles, allowing some interesting scenarios to be played out.

First of all, in the web tier extensibility refers to the ability of taking advantage of third-party frameworks with a much simplified programming model. Developers won't need to manually edit the web.xml descriptor to add context listeners, filters, servlets and servlet mappings per the instructions given by their favorite web framework. Rather, adding a third-party jar to the web application will trigger the addition of all these elements, with no developer intervention. We expect that this feature will cover the requirements of all major web frameworks such as JSF, Struts and Spring MVC, scripting solutions like JRuby on Rails and Grails, WS-* web services following the JAX-WS 2.0/JSR-109 model and RESTful web services written to JAX-RS 1.0. One important point to note here is that extensibility is agnostic to whether a technology is based on a JCP standard or not.

Extensibility though is not limited to web technologies. Looking at existing JCP standards, it's going to be possible for a product that implements the Web Profile to also include additional technologies. The required precondition is that the technology in question must have a standalone TCK. This applies not only to technologies which are independently defined, but also to those who are required components of the full platform.

For example, assume that JAX-RS 1.0 (JSR-311) becomes part of Java EE 6. None of the two Web Profiles (A/B) includes it as a required component. Still, since JAX-RS 1.0 plans to offer a standalone TCK, Web Profile products may decide to offer support for it out-of-the-box. The difference with the case of a developer dropping a jar file for a JAX-RS implementation into the WEB-INF/lib directory is that the vendor of the Web Profile product would have certified the JAX-RS implementation and would presumably be supporting it.

Currently, not all technologies in Java EE 5 have a standalone TCK. For example, neither EJB 3.0 nor JTA 1.1 do. As part of the conversation in the EG around profiles, we at Sun have offered to make many more TCKs available in a form that is suitable for running them on a Web Profile product. These include TCKs for technologies like EJB 3.1 Lite, JTA 1.1 and Connectors 1.6. We believe that this will empower application vendors to ship Web Profile-compliant products that offer more than the minimally required technologies, to help bridge the gap with the full platform.

As an aside, I should point out that the recent trend toward more modularization in application servers will work very well with extensibility, by delivering a simpler, more effective way to manage the versioning and availability of libraries to applications.

As we expand the freedom to combine technologies in a product, the issue of compatibility requirements that span multiple technologies comes to the fore. For example, the Java EE 5 specification contains requirements that servlet containers must honor wrt the availability of JTA. The plan for Java EE 6 is to rewrite such requirements so that they will apply to any profiles and implementations thereof that contain the relevant combination of technologies. Going back to the example, any product conforming to any Java EE profile that includes both servlets and JTA will have to honor those requirements. The rationale has two components: on one hand, we think that the Java EE requirements add significant value to standalone technologies, as testified e.g. by the large number of servlet containers which implement JTA in a way that is compatible with what Java EE mandates; at the same time, calling out the requirements will help ensure that applications that target profiles will work on the full platform. Overall, this makes profiles more than just collections of independently tested technologies, because those technologies will be tied together in interesting ways, deliver more functionality than they would on their own.

This brings me to the last point I'd like to make. One concern we heard around profiles is that they might weaken compatibility. Essentially, if my application targets the Web Profile (however defined) + JAX-RS 1.0, then it won't run on any plain Web Profile product. Although that's technically true, it's important to recognize that there is an upward compatibility guarantee in the form of the full platform, at least when the added technologies are required components, as JAX-RS is. This is no worse than (and, in fact, better than) the current compatibility story for, say, servlets + Struts.

We do expect though that, whatever choice is made re the Web Profile, we may enter an "experimental" phase in which products with different feature sets will compete in the Web Profile space, until one feature set prevails. I'd describe that development as welcome and look forward to standardizing the winning feature set in a future Java EE profile. The Web Profile itself may evolve in the future by adding more technologies (but not by subtracting them, except via pruning), based on experience acquired after its first release.

It's also the case that the full Java EE 6 platform will always be there, offering an ample choice of certified Java EE 6 products from different vendors, to address needs that go well beyond what the Web Profile offers.

Related Topics >>


i think there should be more fine grained approach. the most basic version should be the bare bones. ready for servlet or RMI deployment only (not even jsp). As it can be used for rich client applications, or GWT. Also, why not provide a mechanism to add-remove things easily (console and gui) so you don't need this profiles stuff at all?

While it's fair to say that neither profile includes JavaMail, the base JDK/JRE will include JAXWS/JAXB. I think JAF is also part of JDK 6 now.

how about 'A' minus all the stuff relating to JSP's? i think a set of layered profiles would suit everyone best.

I propose a module-based architecture for JavaEE 6 such as this:

Core -

  • Servlet jar

Pluggable modules-

  • JSP jar
  • JavaMail jar
  • JTA jar
  • JSF jar
  • EJB jar
  • and the rest

When one needs JSP functionality, he can drop the required jar and have it available. When he decides to no longer needing it, he can just remove the jar.


The Full JEE 6 Platform should require JSR-286 (Portlet 2.0), which has recently been submitted to the JCP. All the major commercial and open source vendors have provide portals that run on top of a JEE server. For those who do not, there are a number of open-source portals that could be easily paired with a JEE server, as the portals are just a web application that deploys as a war file.

Why isn`t EJB lite marked also as controversial in the profile B? It should be better to mark EJB lite as optional since there is an alternative as Spring framework.

If you only want a servlet container, then go find one. This is "Java Enterprise Edition 6 Web Profile". It's not an EE 6 web profile unless it includes EE 6 web technologies such as JSF, WebBeans and JSP. It should also include the other EE 6 features that will be useful to an application built for the EE 6 Web Profile, such as the ones listed in the B list and JavaMail. If someone wants nothing but a servlet container then they are not using Java Enterprise Edition 6 technologies (ie Spring, Hibernate, etc). Stop trying to hamper EE 6, and go use a bare servlet container such as Tomcat like you're doing now! Let EE 6 be all it can be, and compete with the non-EE 6 technologies. An EE 6 Web Profile including everything in "B list" will be **serious** competition.

I think the B profile is almost right. I use JSF+JPA and want to use WebBeans for a cleaner programming model. My only quibble is with the absence of JavaMail. Just about every web app that I worked on recently had at least one feature requiring mail (such as sending a confirmation upon registration).

I would go for the A version which is lightweight end even better, quite generic, thus it can be a foundation upon which other web frameworks (Wicket, etc.) can be built.
The B version is a bit heavyweight (not very different from the complete stack). The fact that it contains JSF/JPA is a fair idea (it is not that difficult to ship a JSF/JPA implementations with the application) but the EJB here is imho an overkill ... Let's not forget that not everybody uses JSF (Strtus 1/2, Spring MVC, Wicket, Tapestry, etc.) nor JPA (plain JDBC/Spring JDBC, Hibernate, iBatis, etc.) nor EJB (Spring).

"When in doubt, take it out". That's all I can say. It's always easier to add things in later to a platform, if deemed necessary, than to take things out.

Frankly, I don't see why you can't support both A and B, being as A is a complete subset of A. It seems to me that the work described is incremental. If you're comfortable doing the work for B, then do all of the testing and spec (re)writing for A, stop, print it, then continue and finish the work for B.

it could also be argued that you should focus on A and then add in the other aspects as components with standalone TCKs. So, if someone wants to drop in JSF -- that would be easy for them to do. They would also provide out of the gate solid examples of how to incorporate complicated frameworks in to the profile for others to follow.

Personally, I am most interested in EJB lite. I think being able to have simple SSBs with their annotation driven, declarative transaction management, on top of zero to very minimal configuration would be a great thing.

Please check this Java EE 6 Thoughts

Seriously, we need to look beyond just JSPs and Servlets to equate a profile to Java EE 6. Web Developers need frameworks to help perform development (JPA, Web Beans and EJB3.1 Lite) fit the bill.

Where is DWR it fits in A

  • I vote for a modified version of (B), in which we remove the EJB3.1 (lite) if there is not time to accomplish that.
  • If time is available I think having the EJB3.1 (lite) will give the a chance for Web developers of designing for using EJBs and later when a full profile of EJBs is provided to them they only need to change the interface - remote in place of local - they use, it will be like a migration step rather than a full re-implementation.

In a BASIC profile just include servlet, el and annotations.

This would allow to build JEE6 compatible embedded systems, weher each byte counts (remember the Java stamp controller?).

JSP/JSTL is pure ballast, if you go for JSF and use JSFTemplating or Facelets, or whatever comes with JSF 2.0

other languages? sure not a BASIC issue.

I forgot to mention that I think Web Profile should also include JAX-RS, JAX-WS and JavaMail. To have JAX-WS, you'll probably need JAXB. To have JavaMail, you'll probably need JAF. Still, I think those all belong in Web Profile.

The "B" version of Web Profiles would be my preference.

I can understand how requiring JSF 2.0 is controversial for those who don't wan to use it, but it isn't going to use CPU or memory if they don't use it. If you are going to require JPA 2.0 and JTA, then you have to require JSF 2.0. I really want to see all three required.

I also realize that WebBeans is controversial with the Spring folks, but this adds fundamental things to web programming (not just JSF) such as "conversation scope". I want to see this required as well.

Regarding EJB light, what benefit are we going to get from only stateless session beans that WebBeans doesn't already provide? If you do include it, I would expect EJB 3.1 Lite, not EJB 3.0 Lite (no local business interface required). The biggest thing from EJB that I would want to see in WebProfile is the EJB 3.1 Timer.

I think that mandating JPA 2.0 and JTA is great because _everyone_ needs those anyway. If you had to choose the "A" profile, I would add JPA 2.0 and JTA to it.

Hello Roberto, nice entry! It seems that what you guys are trying to do with Web Profile is something near from what we have tried in ME space with JWTI ( and, more recently, with MSA ( Cheers, Bruno.

This will be controversial, but I don't think the jsp-related technologies should be a mandatory part of a Web Profile.

Certainly make it an option for the containers to implement, but I don't think in 2008 one particular, serverside presentation technology should be given such precedence.

I've blogged about it here:

I've put on my flame-retardant underwear :-)


B (with JSF and JPA) + JavaMail