Roberto Chinnici's Blog

September 2007 Archives

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!

GlassFish V2 and Phobos

Once you have installed the new, awesome GlassFish V2 application server, you can download and install Phobos with just a few mouse clicks, using the included updatetool. Upon installation of the Phobos module, you'll find a newly created phobos directory under the root server directory, containing the Phobos framework, the libraries and some sample applications. Each sample comes with an ant script that can be used to build a regular war file, which you can then deploy to GlassFish using the asadmin deploy command.

The version of Phobos available from the GlassFish Update Center is 0.5.11, matching the one available as a set of NetBeans modules.

The first thing you'll notice about this release is that it's quite a bit smaller. This is due to the upgrade to Mozilla Rhino 1.6R7, which implements E4X on top of the DOM API, allowing us to stop shipping XML Beans. This shaves a good 2MB off the download.

Additionally, Rhino 1.6R7 adds support for JavaScript 1.5 language features, such as the const keyword and property get/set methods. See the Rhino documentation for more details.

In Phobos proper, in addition to some bug fixes, the major new functionality we added is an actor library (please refer to the Phobos jsdocs for the details of the API). We also enabled debugging of background threads in NetBeans, so that you can put breakpoints in and step through code executed by an actor.

Clearly inspired by Erlang and Scala, the actor library allows the creation of "actors" in JavaScript, defined as named functions which asynchronously process messages sent to them. Upon reception of a message, the function is executed in a separate thread, so it doesn't have access to the usual request and response objects. Much like Google Gears tasks, actors can only communicate by sending messages to each other or by making changes to shared resources, like a database or (not too often, hopefully) a global variable. Every actor has its own mailbox; messages sent to an actor are processed in strict sequential order. All messages are JSON-encoded, which makes them look like regular objects to JavaScript code.

Overall, it looks like a pleasant programming model for asynchronous activities. There is a lot of functionality which is missing when compared to Erlang, like the ability to pattern-match on messages and to make nested calls to the receive primitive, temporarily changing the behavior of an actor (or process in Erlang terms). On the other hand, much of this functionality can be emulated, albeit less elegantly, using regular JavaScript constructs. In principle, it should be possible to use something like Narrative JavaScript, whose compiler runs fine on Phobos, to compile an actor with nested receives to a "flat" one, but this would required some detailed investigation.

The interesting thing about the model I just described (actors as JavaScript functions, named by strings and exchanging JSON-encoded messages) is that it could be applied cross-tier. It should be possible to implement a similar API on top of Google Gears and have actor proxies on the client forward messages over HTTP to the server. Since actors are identified by a symbolic name and messages are by definition in JSON format, it would be easy to move an actor to a remote location without affecting other code on the same tier. I wonder if anyone has prototyped such a system...

This work is licensed under a Creative Commons License.