Extensibility and modularity
Thanks to everyone who left comments on my previous blog entry on profiles, as well as on the related TSS and InfoQ articles. Also to the 700+ folks who voted on the poll on java.net or commented on it either on-site or on TSS.
At a high level, I have to say that the feedback reflects quite closely the discussion in the JSR-316 EG. Perhaps the EG composition is even more representative of the whole community than we originally thought!
Unfortunately, the poll results are a masterpiece of indecision: large preference for including JSF 2.0 and WebBeans 1.0, but short of a majority (46.7%). A smaller profile without JSF and WebBeans at 28.9%, but even that camp is split nicely in two (at 17% and 11.9%). A full 24.2% of respondents who don't care.
Conclusion #1: There is strong demand for JSF 2.0 and WebBeans 1.0.
Conclusion #2: We cannot please everyone (we kind of knew that).
Having read all the comments, there seems to be a bit of confusion about the way that extensibility would work. In my original blog post I didn't go in depth into it, mostly to avoid breaking the record for the longest and most boring blog entry on java.net, but the subject deserves a few more words.
For clarity, I find it convenient to distinguish two cases, based on whether a technology can be added to an application by a user or by a server vendor. I will reserve the term "extensibility" for the first case, and use "modularity" for the latter.
At first sight, making it possible to add any technology via extensibility seems desirable. (Incidentally, this may well be the Spring tack on the whole thing.) In reality, this would require a lot of contracts to be standardized. Since standardization has a cost and the returns would be diminishing, I doubt that it will ever cover 100% of the functionality. Performance-wise, going through standard contracts at this level of granularity may turn out to be sub-optimal, so I imagine there'd always be an incentive for vendors to bundle the implementation of certain APIs with their application server to try and squeeze every bit of performance out of it.
At the same time, extensibility is a great thing if it captures the 20% of functionality that covers 80% of the needs, thus enabling a lot of developers to painlessly use a lot of technologies at essentially no cost in complexity or performance. In essence, this is the reasoning behind making extensibility in the web container a key goal for Java EE 6.
A lot of the APIs we've been considering for the Web Profile can be handled via extensibility: drop one jar into the WEB-INF/lib directory of your application (or in some suitable shared directory on your server) and you get JAX-RS, or JSF, or JPA, or WebBeans, or server-side JAX-WS, or... The key factors here are the availability of the technology in standalone form (which requires a separate TCK to exist) and the adequacy of the extensibility contracts in the servlet container. We certainly want to make sure that the latter are sufficient to plug in pretty much any web framework worth using, so please keep an eye on the Servlet 3.0 developments and let us know if you find any holes. On the TCK front, we are resource-constrained on what we can do with respect to existing technologies, but for new ones (including all the ones listed earlier) we will make sure suitable TCKs exist.
The second case, modularity, covers pretty much everything else. In a number of cases, which hopefully will get smaller over time, there is no independent TCK for a technology, so an implementation cannot consist a jar separate from a full Java EE server. In some other cases, there is no standard contract that would enable you to plug an arbitrary implementation into an application server. (EJB 3.1 is a good example.) Designing these contracts is non-trivial, so we need to accept as a fact of life that we won't have them in Java EE 6. Luckily, we got a bunch of new contracts done recently, e.g. the security-related ones in JSR-115 and JSR-196, so things are moving in the right direction.
As part of the work on profiles, we've been trying to improve on the situation as much as time and resources allow. In the case of EJB, we've been prodding the EJB EG to define a "lite" subset of EJB 3.1 which can be run on top of the Web Profile. This way, application server vendors will be able to offer a "EJB 3.1 Lite" implementation in their Web Profile products even if we went with a "small" Web Profile (e.g. option (A) in my previous blog entry).
So, why am I using the word "modularity" for this case? It's because it fits well with the trend we are seeing towards more modular application servers like GlassFish V3. Rather than having a monolithic server, you'd be running a small core and an initial set of containers, with some baseline functionality. You could then download/install/activate as needed any number of new modules providing additional functionality, like EJB 3.1 Lite. Of course, you could handle this way modules that use extensibility too, especially when they are shared by multiple applications, but for things like EJB 3.1 Lite there literally wouldn't be another option: absent an SPI, the choice of what EJB 3.1 Lite implementation you run would be limited by what your server vendor offers.
Once you look more closely at the different APIs, you start realizing that there are some "gray" cases too, like JPA. In fact, although it's possible to add JPA to a web application via extensibility, your application will be restricted to using the SE-based programming model (i.e. using the javax.persistence.Persistence class as an entry point). Enabling the resource injection-based EE model is non-trivial and would require quite a bit of work. Is the SE model good enough? Does extensibility have to go all the way in all cases? I hope not, but it will take time to figure out where to draw the line for maximum effectiveness.
As a coda, I should talk briefly about JAX-WS. It wasn't very clear in my previous entry, but since Java EE 6 requires Java SE 6, the JAXB and JAX-WS APIs would be present in *any* profile. Unfortunately, what's left out is the ability to define web service endpoints on EE, which traditionally follows the JSR-109 model. We'd like to see this case handled via extensibility, so that it'd be possible to drop a "server-side JAX-WS" jar into WEB-INF/lib and have the application work in any servlet container, especially those that don't support JSR-109. In this case, we'd also like this extension library to use the version of JAX-WS that comes with the JDK. Currently there are some missing bits in the JAX-WS API that prevent this from working, but we're looking into adding a small SPI for this purpose to the JAX-WS 2.2 release.