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.
|EJB 3.1 (Lite)|
JSF 2.0 *
Web Beans 1.0 *
Web Beans 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.