The two main themes of the next Java Enterprise platform release are extensibility and modularity. While the former is often understood as a corollary of the latter, there is more subtlety to what these terms mean in the context of the Java EE 6 specification, according to Roberto Chinnici, spec lead for JSR 316, Java Platform, Enterprise Edition 6.

In a recent blog post, Extensibility and modularity, Chinnici writes that:

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.

He explains that extensibility must be weighed against simplicity and ease of use:

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.

Chinnici points out that modularity is more difficult to achieve, because it requires standard interfaces to exist between modules:

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)...

What do you think of the direction Java EE 6 is taking?