Jersey 2.0-m08 is out (and so is 2.0-m07…)

I’ve been pretty busy lately preparing JAX-RS 2.0 specification for a Public Review release as well as updating Jersey to accomodate recent JAX-RS 2.0 API changes in areas of server-side asynchronous API, client and URI builder API as well as some other minor changes. Preparing for my JavaOne presentations that’s just round the corner also took a significant chunk of my spare time. FYI, JavaOne 2012 is happening next week so if you wanted to go and you still don’t have your pass, you should get one now.

Anyway, so much for the excuses of why I’ve been quiet lately. Today I’d like to announce that we’ve recently released Jersey 2.0-m08. For those of you who watch my blog and wonder what happened to Jersey 2.0-m07, well, the good news is that we’ve released that one too about a month ago, the bad news is that I shamefully didn’t find enough time to blog about it. In any case, things move quickly, and Jersey 2.0-m07 is the past now so today I’ll be focusing on the latest milestone 08 release, however I’ll be cover all important changes between milestone 06 to milestone 08, including the features delivered in milestone 07 of Jersey 2.0.

Let’s look at the main changes now:

ResourceContext API (a similar one to the Jersey 1.x ResourceContext) has been introduced in JAX-RS 2.0 and support for it has been implemented in Jersey. Based on the feedback we received form JAX-RS 2.0 Expert Group, we decided to remove the resource and URI matching methods from the standard API and just keep the API focused on providing resource injection support independent of the underlying injection manager. You can now use the API with Jersey 2.0 to provision and/or inject your sub-resource instances in a standard way.

Support for application WADL generation. As it is possible in Jersey 1.x, Jersey 2.0 runtime now also supports automatically generate WADL descriptors for your JAX-RS applications.

Support for the new JAX-RS @BeanParam annotation. This injection annotation is a nice addition to the JAX-RS API that should help to make your resource method signatures more readable. See the linked annotation API documentation for more details.

Support for the revised JAX-RS asynchronous server-side API. The revamped JAX-RS async API looks much better, is more consistent and even simpler to use that the previous version. We managed to identify and drop some redundant pieces from the old API as well as add new interesting features such as callbacks and timeout handler in the new version of the API. Of course, this change meant that a significant effort had to be invested in refactoring the existing Jersey implementation. Now we’re proud to say that we made it. Jersey 2.0-m08 supports the new JAX-RS async API.

Performance and internal design improvements. In the last 2 milestones we started to focus more also on the performance side of Jersey 2.0. We have also identified a few design issues in the client as well as server-side runtime code that we addressed in order to improve the maintainability of Jersey code in the future. In other words, while as a user you may never notice it, the main difference between Jersey 2.0 milestone 06 and 08 is that the latest Jersey 2.0 milestone had undergone a major runtime engine overhauling and now runs better than ever. For instance, we ditched the idea of a common client & server, sync & async processing engine that suffered from high increase in code complexity over time. Instead, we introduced specific client and server side processing engines tailored for the specific needs of the client and server. Also, we now make sure that requests that do not involve any async processing use code paths optimized for synchronous executions that do not involve any thread context switching or other tasks specific for the asynchronous request processing.

Lot of bug fixes. And I mean really LOT of fixed bugs. In fact, the main theme of the milestone 08 was bug fixing to make sure the Jersey 2.0 is in the best possible shape to be used in JavaOne demos. Now I do not want you to think that Jersey 2.0 was not stable before. Many of the bugs that we have fixed recently were mostly in the category of strict compliance to the JAX-RS 2.0 API and specification and involved mostly corner-case situations. Still, it’s a good feeling to know that Jersey now much more precisely adheres to the spec much even in these rare use case scenarios.

If you are interested in more details, check out the Jersey Jira for the list of all the resolved feature requests, tasks and issues in the milestone 07 and milestone 08.

For a complete overview of the updates in the Jersey API, please have a look at the Jersey 2.0-m08 API documentation. Note that we are still in the middle of a development cycle and Jersey 2.0-m08 is an early development preview release so you can still expect significant changes in the API since the parts of the API are moving every now and then. You may want to also bookmark the Jersey 2.0 snapshot API documentation link to if you want to see the latest development version of the API. Also feel free to browse Jersey 2 source code on GitHub and check out the Jersey examples.

In the last sprint we also continued work on an updated user guide that also contains an initial draft of a migration guide for your Jersey 1.x code.

Jersey 2.0 provides support for Java SE HTTP Server, Grizzly 2 HTTP server, Servlet 2.5 or higher containers as well as OSGi containers on the server side and HTTPURLConnection-based or Grizzly asynchronous client transport connectors. To leverage JAX-RS/Jersey server-side async features in a Servlet container, you need a container that supports Servlet 3.0 at least. Jersey supports asynchronous resource invocations on Grizzly 2 HTTP server too.

All the 2.0-m08 milestone binaries, including the source & apidocs jars, are available for download under the Jersey 2.0 maven root group identifier org.glassfish.jersey from the central maven repository as well as from the java.net maven repository.

Chances are you are using maven on your project. If you do, there is a very easy and convenient way to start playing with Jersey 2.0 by generating the skeleton application from one of the Jersey 2.0 maven archetypes that we provide. For instance, to create a Jersey 2.0 application using the Grizzly 2 HTTP server container, use

4 thoughts on “Jersey 2.0-m08 is out (and so is 2.0-m07…)”

Hi Marek, I have been experimenting with the latest SNAPSHOT. We have multiple web services written using jersey and we provide a web service client for each service which are also written using jersey. Some services talk to others and often have multiple web service clients embedded in them. As attempting to migrate all service consumers at once is never an option in my company a direction where web service clients written in Jersey 1.X and those written in Jersey 2.X will need to co-exist in the JVM classloader.

As a use case:
A Web Service A written in Jersey 1.X has client’s of two other services B and C, one written in Jersey 2.0 and the second in Jersey 1.X. When running the application I noticed the following –
java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;
It looks like UriBuilder in jaxrs 2.0 adds the new method for uri but if the jersey 1.X RuntimeDelegate gets used to create the Builder, it will not necessary provide one that has the method mentioned. In addition the jersey-core 1.14 maven jar includes references javax.rs.core.UriBuilder so excluding the same mean re-bundling without the package.

I understand in my service “A” which is on Jersey 1.X, I can specify the RuntimeDelegate to be org.glassfish.jersey.internal.RuntimeDelegateImpl via META-INF/services which will factory a JerseyUriBuilder that has the method. This seems to work but is not bullet proof IMHO as one cannot control the version of UriBuilder that gets loaded which might lead to problems.

Am I missing something here or is this a known problem that will be addressed? Thanks in advance.
In most other cases, the compatibility or co-existence seems to work great.

The problem is that currently it is not possible to run multiple different JAX-RS API versions in a single JVM. I’m not sure we’ll be able to do anything about that. For your case it would be best to have 2 separate production environments and migrate your services and/or clients from the old setup to a new setup.

Under the assumption that the JAX-RS 2.0 is backward compatible in that no methods have been removed, no signatures changed then using JAX-RS 2.0 API always and excluding JAX-RS 1.X API from the class loader should function. I sadly do not know whether that is the case but should be simple enough to find out.