Earthly Powers

Jersey 0.4 is released

We have just released version 0.4 of Jersey (see the stable download directory). This aligns with the 0.4 release of the JAX-RS API and the early draft recently published for review.

See here for an overview of the changes.

Not a lot of outside visible changes have occurred between 0.3 and 0.4 (the API is very similar) so it should be a relative smooth transition. At various points all the main developers have been away or busy with other things, but we still managed to do a lot of things under the covers and in branches. What follows is a summary of the goings on.

Frank used Japex to compare the performance of the linear URI matching algorithm and the automata-based matching algorithm (originally based on the Trie algorithm).

The scatter graph above shows the number of transactions per-second on the Y axis and the number of URI templates on the X axis (notice that both the X and Y axes are log-scale). The results were obtained by measuring the time it took to match a collection of URIs given a collection of URI templates. The points that are blue circles are the results for the Trie (automata) matching algorithm and the points that are the red squares are the results for the linear matching algorithm. Although there is variability in the test data which causes some variance between tests it can be observed that the scalability of the linear algorithm degrades as the number of URI templates to be matched increases. Where as for the Trie algorithm it stays reasonably flat and shows good scalability characteristics. In addition the Trie algorithm is always faster. We are going to work to get this algorithm into the trunk (hopefully for 0.5) but the URI matching in the runtime requires some refactoring and i want to pull in some aspects learned from Phobos. See this email for a general plan of action.

Florian provided a patch for an entity provider that serializes Collection<T> where T is a the type of a JAXB bean. I would like to include this in the 0.5 stable release as an optional entity provider.

Jakub and Marc have been working on a resource model API and implementation (see this branch). This API/impl will allow us to validate a resource class (producing clear and meaningful sets of warnings/errors) and create runtime reflection meta-data and WADL at runtime. Currently the former directly uses the Java reflection APIs and the latter uses APT APIs in a pre-compile step. So not only will this enable us to generate WADL on the fly dynamically it will enable us to experiment with different meta-data sources for describing resource classes to those of annotations (for example in an XML document).

Frank has also been working on a mechanism to completely remove the pre-compile step currently required to detect root resource classes and instead to detect these dynamically at runtime (see this branch) using ASM. This is a very significant step forward to simplifying the configuration of Jersey. By default no pre-compile step or configuration options will be required when using the Servlet or light weight HTTP container, so for the latter it will be possible to do this:

HttpHandler handler = ContainerFactory.createContainer(HttpHandler.class)

and the run time works out the root resource classes from analyzing the classes present in the class path. (It also means that root resource classes can be detected in third party jars.) This feature will be in the 0.5 release.

A new example was added showing how Jersey can be used with Scala for creating Mandelbrot sets.

The testing infrastructure was over-hauled, as described here. Depending on how much time is available the client-side API used for testing may be exposed as a Jersey API in 0.5.

As you can see we have our work cut out for the 0.5 release! We are not sure we should release at the end of December or the start of January. My preference would be for January. If you have any views on this let us know.

Posted at 12:40PM Nov 02, 2007 by Paul Sandoz in REST  |  Comments[0]