First milestone build of Jersey 2.0

I am excited to announce that we have just released Jersey 2.0-m01, the first milestone build of the next major release of Jersey based on a completely new code base, fresh core design and implementing the upcoming JAX-RS 2.0 API (currently in it’s early draft version). Jersey Jira issue tracker contains the full Jersey 2.0-m01 release notes.

As mentioned above, the Jersey 2 is not just an update of the existing Jersey 1.x code, it is a completely new code. The main aspects of the new Jersey 2 code include:

Injection-enabled and injection-aware Jersey core that uses HK2 framework for dependency injection. The new Jersey code not only provides user level injection, but the code itself is written to leverage the injection capabilities. Additionally, the decision to use a dedicated dependency injection solution means we will need to spend less time on maintaining a proprietary Jersey 1.x injection framework and focus more on providing new RESTful features.

New asynchronous internal request processing API. The core request processing flow has been completely redesigned with asynchronous client and server-side features in mind. This will not only help us unify the processing logic on the client and server, but will let us provide a natural and very efficient support for the new JAX-RS 2.0 asynchronous features.

New programmatic server-side resource builder and application configuration API. Ability to programmatically define JAX-RS resources is an often-requested feature that provides a complementary API to the JAX-RS annotation-based resource definitions. In fact, with the new API in place, the Jersey 2 core server-side processing is using the API to translate annotated resource definitions into the internal Jersey runtime model. Check the latest version of the programmatic server-side API javadoc to find out more.

JAX-RS 2.0 Client API support. In Jersey 2 we are abandoning and deprecating the proprietary Jersey 1.x Client API in favour of the standard JAX-RS Client API. All the existing examples and tests in Jersey 2 as well as all the tests ported from Jersey 1.x code base are using the new JAX-RS API backed by the Jersey 2 client API implementation.

Revamped Jersey test framework and API. In Jersey 2 the goal is to bring more pluggability and flexibility into the test framework API.

For an complete overview of the new Jersey API, please have a look at the Jersey 2.0-m01 API documentation. Note that this is an early development preview release and the parts of the API are moving frequently so you can still expect significant changes in the API. You may want to bookmark the Jersey 2.0 snapshot API documentation link instead to make sure you look at the latest version of the API. Also feel free to browse Jersey 2 source code and check out the new examples that leverage JAX-RS 2.0 Client API as well as Jersey 2 server-side programmatic API.

The second early draft of JAX-RS 2.0 specification is available at the JCP web site. The latest version of JAX-RS 2.0 API documentation is also available for browsing here. This link and more information about the JAX-RS project can be found on the JAX-RS project web site.

Currently, this first early milestone release supports Grizzly 2 HTTP container as well as basic Servlet-based deployments on the server side and provides HTTPURLConnection-based client API implementation. All the 2.0-m01 milestone binaries including the source & apidocs jars are available for download under a new Jersey maven root group identifier org.glassfish.jersey from the central maven repository as well as in the java.net maven repository.

And by the way, for those of you who are more conservative and prefer playing with a production-quality software, we’ve also released Jersey 1.12. You can find more information about the Jersey 1.12 release on Jakub’s blog.

What is the plan for supporting @Singleton Jersey 1.x style scoping for resources? JSR 330 defines a @Singleton for a similar purpose, will this be part of the standard JAX-RS or would still remain as an implementation feature? Is there a way to achieve similar functionality in the current milestone release?

We haven’t discuss this in EG yet. There is an open issue for it, but right now I cannot give you a definitive answer on your question. Also, this functionality is not yet available in Jersey 2. We’ll be adding it in one of the coming development sprints.

In general singleton JAX-RS resources can be implemented portable way in a Java EE container if the resources are defined as EJBs, Managed beans or CDI-managed beans.

Good question. I assume you are asking about those apps that are using some proprietary Jersey 1.x extension APIs, as all applications using only JAX-RS API should run on Jersey 2.0 without any change.

As for the proprietary Jersey API, the new API will not be compatible with Jersey 1.x. We have changed the package scheme as well as replaced the internal injection module. Also, JAX-RS 2.0 comes with a standard client and filtering API that effectively replaces the proprietary APIs provided by Jersey 1.x. All of these have significant impact on a potential BW compatibility with apps using Jersey 1.x proprietary APIs.

That said, our plan is to either provide a migration guide or, if possible and as time permits, we also consider implementing a compatibility bridge module that would allow run Jersey 1.x apps on Jersey 2.x runtime.