Java EE 6 Web Profile

Roberto Chinnici has posted a blog entry discussing the idea of introducing “profiles” in the JavaEE 6 specification(aka JSR-316).
Essentially, a profile is a subset of the enormous number of APIs/specs etc that a JavaEE platform supports. Over time, EE platforms have grown in complexity and size, leading to very large downloads and very large runtimes. Of course, if your app happens to use 99% of those APIs, you’re a happy camper (although IMHO your app could probably benefit from a long, hard think about it’s architecture 🙂 ). For very many – dare I even say the majority – of cases, the full EE environment just isn’t needed. In recognition of this, most of the well known application servers have released “lite” versions of themselves (although the success of the diet has to be measured in terms relative to the starting size and not the absolute outcome).
So that’s the motivation for the JSR’s consideration of  “profiles” – they’re a way of  slimming down the EE environment. A profile defines a minimum feature-set for a compliant product to implement, although a product could also choose to offer additional features, apparently with the provisio that a TCK must exist for those features.
The first profile they will be tackling is the Web Profile. Roberto lists 2 options under discussion:
Option A

• Servlet 3.0
• JSP 2.2
• JSR-45
• EL 1.2
• JSTL 1.2
• JSR-250

Option B

• Servlet 3.0
• JSP 2.2
• JSR-45
• EL 1.2
• JSTL 1.2
• JSR-250
• EJB 3.1 (Lite)
• JTA 1.1
• JPA 2.0
• JSF 2.0 *
• Web Beans 1.0

Whilst being the least heavy of the two, I actually think that Option A still has some dieting to do! The days are long past where one server-side presentation technology should be annointed as an essential part of a web container. These days many dynamic, slick web user interfaces are being created without the use of JSPs at all. Just have a trawl through the technologies listed on http://www.ajaxian.com to get some idea of the variety that is out there. By all means let Web Profile compliant containers provide JSP support as an optional extra. This would permit a migration path for existing web apps. However,  to mandate its inclusion at this point would be to look backwards in time rather than forwards into the future.
Option B, even minus all the JSP-related and derived technologies is still too heavy. I guess when you come right down to it, I think you can get a long way if your web container simply supports the ability to plug in extra services via JNDI. Want to use EJB3? Select one of the implementations available, throw it into the container’s classpath and hookup what’s necessary into JNDI and away you go. Want to use JPA? Throw an implementation library into the container’s classpath, hookup JNDI and again, you’re good to go. Not satisfied with your initial choice of JPA impl? Take it out and replace it with another.
In short, I’m not really sure that profiles are the answer. Is it really feasible to select a set of APIs and expect that one-size will fit all?  I think what we really need is the ability to run a web container and a mix of API implementations according to our needs, and I think to a large extent a web container + JNDI already provides this.
My experience with Jetty is that by using JettyPlus (which is essentially Jetty plus JNDI), you can plug in all manner of tools that let you get the job done. If you can’t be bothered to work out which implementations of the tools you want to use, then you can use something like Hightide, which is JettyPlus with a bunch of tools pre-plugged in. If you don’t like them, then you’re free to swap them for others.