Roberto Chinnici's Blog

Java EE 6 Platform (JSR-316) Update

In the spirit of transparency, I'm going to be posting regular updates on the work of the Java EE 6 expert group (JSR-316).

For the most part, this is going to be a condensed version of the updates that are sent to registered observers to the expert group. In order to join as an observer, you need to be a JCP member. The instructions to join the observer list are on the JSR-316 community update page (JCP access required), also linked from the publicly accessible JSR-316 detail page.

Starting with some trivia, the expert group is fully formed now, and it counts twenty-five members plus the two spec leads.

The following issues were discussed and resolved:

• Application client class loading - The Java EE 6 specification will clarify that classes and resources belonging to an application client are isolated from other modules present inside the same ear file. This includes other application clients as well as other kinds of modules within one ear file. In concrete terms, if you have an ear file containing, say, an application client and a web application, the application client won't have access to classes and resources inside the web application, and vice versa.
• Pruning - The pruning process will be identical to the one proposed for SE and described by Mark Reinhold in this blog entry. The Java EE 6 specification will mark the following technologies as possibly being made optional in a future release: EJB entity beans, JAX-RPC, JAXR. The first two technologies have been effectively replaced by Java Persistence and JAX-WS respectively. The rationale for pruning JAXR is based on its limited use, which doesn't seem to warrant its status as a required component of the platform.
• Content repository for Java (JSR-170) - The Java EE 6 specification will NOT include JSR-170 as a required component.
• JBI (JSR-208, JSR-312) - The Java EE 6 specification will NOT include either of the JBI JSRs as required components.

The following notable issues are currently being discussed by the expert group:

• Best practices around distribution of web applications - In particular, how web applications support customization by the user, either before or after deployment.
• Web profile - Definition and contents of the Web Profile.

Check this blog again in a month for more updates!

Comments

• Hi RobC,
  thanks for keeping the community up to date with whats going on in the expert groups. I appreciate it a lot.
  I just wanted to say that to my mind, it is sad that the java content repository technology isn't going to be a required component. I assume that not only JSR-170 is being rejected for EE6 but also JSR-283, the second version.

  My point of view is: IF one considers it justifyable to have a message queue service as a mandatory component AND to have a relational database system as a mandatory component THEN it will be hard to argue against introducing JCR as a mandatory component. In simple term, one might coin JCR to be the next generation database technology.

  Having it as a mandatory component would probably help to proliferate this wonderful standard.

  Posted by: wtff on September 24, 2007 at 09:04 AM

• Hi Robertowe're developing JSR170-based applications (among others). We consider it a bad decision for JEE6 that JSR170 is not part of the standard, because an inclusion would force developers of JSR170-"compliant" repositories to really adhere to the JSR170 specification (and not only write about it in the pamphlet;-).Anyway, we're sure, that future web application will more and more rely on content repositories and a support of them in JEE6 is important for Enterprise Java.
  

  Posted by: luethjec on September 25, 2007 at 01:56 AM

• @wtff

  Where is the logic in JMS inducing a parallel need for a content repository? Note that JMS is a core requirement to make enterprise technologies like MDB work. Also Java EE does *not* require an RDBMS as a mandatory component. If you are referring to JPA, then that's not correct; JPA is simply an API to simplify the Pojo-JDBC bridge (as stated many times Hibernate and other impls of JPA are state-management solutions, not database connectivity or RDBMS tools).

  @luethjec
  The vendors in the EG did not see much (or any) demand for JCR from their clients. The consultants & developers in the EG (myself included) did not see much widespread (or any significant) use of JCR. In fact, impls like Jackrabbit are easily embeddable in any environment; so Im not sure why JCR requires a Java EE blessing.

  Posted by: dhanji on September 26, 2007 at 04:23 PM

• I would have liked to see JSR-170 as a mandatory component in JEE6 as well. Even Oracle ships with it already and IMHO it's one of the most notable features the Java platform currently offers.

  Posted by: xmaniac on September 28, 2007 at 06:04 AM

• 
  WeWantJSR170InJEE6++ ;

  I think that JSR 170 must attract some focus!
  There are wonderful possibilities for dynamic-model based architectures in Java with JSR 170, but the problem is that the implementations must be solid.
  Making JSR170 a mandatory spec requirement would contribute to some focus, making implementations better and educating people that the JSR can greatly help them build generic applications.

  Yuval.
  

  Posted by: yuvalgo on October 02, 2007 at 09:11 AM

• JSR 170 should surely be part of the standard package? Who makes this decision? For Java development jobs look here
  Sheffield Jobs

  Posted by: andy_java on November 15, 2007 at 07:41 AM

This work is licensed under a Creative Commons License.