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.
To run Jersey 2 you'll need the core artifacts:
org.glassfish.jersey.core:jersey-common org.glassfish.jersey.core:jersey-server org.glassfish.jersey.core:jersey-client
Additionally, you'll need a Jersey container implementation, e.g. Jersey Grizzly2 HTTP container:
org.glassfish.jersey.containers:jersey-container-grizzly2-http
Have fun looking around, running examples, playing with Jersey 2. To provide feedback send us an email to our users mailing list
or log discovered bugs & new feature requests in Jersey Jira issue tracker.
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.
On JAX-RS 2.0 from Devoxx
Yesterday I gave a talk at Devoxx on what's coming in JAX-RS 2.0 that is planned to go final in the middle of the 2012. On the stage it was hard to see the people because of the spot lights beaming at me, however I could notice that the cinema room for about 450 people was quite full, despite the hard competition from Brian Goetz who was talking about Java SE 8 next door. I did a poll and it turned out that about a third of the people have not worked with JAX-RS before. It was nice to see that JAX-RS is a technology that people care about and that attracts new developers. In fact, today in the morning I ran into a Silicon Valley JUG and GTUG lead in the tram on the way to the conference venue who told me that in his opinion JAX-RS is the technology with perhaps the biggest potential from all current Java EE technologies. Cool, right? 
I was little bit nervous with the talk as typically I have at most 15 slides for an hour long talk, but since I wanted to show a lot of code without the danger of spending too much time switching back and forth between slides and IDE, I have put the code into the slides and ended up with a pretty large pile of slides. Also, the night before I took part in an interesting technical discussion that ended up around midnight in a local pub . Not sure about the exact correlation ratio, but in the morning I woke up just to realize that I got cold and lost my voice. It got better over the day, but I still could not speak too loud before my talk. Luckily the audio technician was skilled and managed to set up the mic in a way that, although it still did hurt, I could at least speak in a low voice (the only disadvantage was that after the talk two people tweeted that the content was great just the speaker had a sleepy/dry voice). Despite these technical problems I received a very positive feedback overall and I was answering JAX-RS related questions for the next 30 minutes after the talk.
So what did I talk about? See the slides yourself.
Perhaps the most wanted addition to the JAX-RS is the Client API, that would complete the JAX-RS story, that is currently server-side only. In JAX-RS 2.0 we are adding a completely interface-based and fluent client API that blends nicely in with the existing fluent response builder pattern on the server-side. When we started with the client API, the first proposal contained around 30 classes. Thanks to the feedback from our Expert Group we managed to reduce the number of API classes to 14 (2 of them being exceptions)! The resulting is compact while at the same time we still managed to create an API that reflects the method invocation context flow (e.g. once you decide on the target URI and start setting headers on the request, your IDE will not try to offer you a URI setter in the code completion). This is a subtle but very important usability aspect of an API. And if you ever tried to create a (real) fluent API you surely know how hard it is to achieve the result without an explosion of API class/interface numbers. At present the client API is in a draft phase. You can still expect some minor changes in method signatures here and there as we make progress with the underlying API implementation, but the main parts of the client API can be generally considered stable.
The next big feature addition that you can expect from JAX-RS are Filters an Handlers. Filters are essentially reusable providers for Request pre-processing and Response post-processing. The filters are non-wrapping, which means that the filter chain is completely managed by the JAX-RS runtime, including the execution of the filters in the chain. Filters have the way to influence the the chain execution by returning the "next action value", but they do not directly invoke the next filter in the chain (which is where the term non-wrapping comes from). Handlers on the other hand are wrapping (directly invoking the next handler as part of their handle method) interceptors of the message data marshalling and un-marshaling. Whenever a message entity is read or written the request always goes through the handler chain. By default both filters an handlers are applied globally when registered as providers, but JAX-RS 2.0 is going to provide a mechanisms for static as well as dynamic binding of a filter or handler to a particular resource or resource method as well as for specifying a relative order in the filter/handler chain. Dynamic binding is enable via implementing an interface. Static "named" binding is provided via designated named binding annotations.
Since JAX-RS 1.0 came out, many JAX-RS users have requested support for data validation. If you are one of these users, we have a good news for you: JAX-RS 2.0 will provide data validation support by integrating with the standard Bean Validation API. I won't go into too much details here, as the Bean Validation API would itself easily make several blog entries on it's own. The important for us is that by integrating Bean Validation API support into JAX-RS we are providing the JAX-RS users with a very powerful and standard Java API for data validation instead of re-inventing the wheel in JAX-RS spec.
Another notable update in JAX-RS 2.0 is the improved support for working with hyper-links. Current proposal is focused on improved support HTTP link headers. We are extending the existing API as well as making sure the new API additions (client, filters...) are designed with link support in mind. That said, I had two interesting discussions earlier this week with a couple of web client developers who independently pointed out that for them accessing links in HTTP headers is quite difficult and their preferred model is to include all the links in the HTTP entity, typically represented as JSON. I have to admit that we have completely missed this fact in our considerations within JAX-RS EG and this area is something we may still want to look at an revisit the current proposal.
I concluded my talk by a short update on plan to integrate the Java Dependency Injection API (JSR-330) into the JAX-RS. The idea is to slowly move away from the JAX-RS specific @Context injection annotation towards the standard JSR-330 Dependency Injection API. In the first phase we would like to make sure we support @Context and @Inject interchangeably. We would also like to add support for qualified injection (see @Qualifier in DI) as well as think about how to support dependency injection Providers and scopes. The proposal for this area is not finalized yet so I cannot provide more details on the final solution for JAX-RS 2.0 at the moment. We expect to close this task in a month or so.
There are few requested features that are most likely not going to make into JAX-RS 2.0, namely MVC support an high-level client API. In both cases the reasons behind include the lack of consensus in the EG caused primarily by the fact that these areas are still not explored well enough in the proprietary API space to make us feel confident about doing any standardisation work there.
In case you are interested in more details, you can check out the early draft of the specification that was made available for a public review couple of weeks back. You can also check out our JAX-RS Specification Project site on java.net that contains wiki with API proposals as well as (yet to be completed) API javadoc draft. Feel free also to brows through the expert group mailing list archives. Don't forget to subscribe to the users mailing list where all the EG communication is replicated if you want to keep yourself up-to-date with the most recent work in the spec. And most importantly, if you have any feedback, please don't hesitate and send it to the JAX-RS users mailing list.
Notes from Jazoon 2011
I have just returned from the Jazoon 2011 Conference in Zurich that finished yesterday. Zurich is a beautiful city and I always enjoy my stay there because of it's atmosphere, location and nice people. Everything seems to work well there, including the great system of public transport (how many cities include boats in their public transportation networks?). I only wish they did something about the public smoking which can be particularly annoying under a tram stop shelter on rainy days.
The Jazoon conference was traditionally held in the Arena Filmcity, Zurich's multiplex cinema, with halls featuring 150, 300 and 500 comfortable seats. This year I was presenting a talk about SOAP and REST services looking at the two from a perspective of several typical use case scenarios. The talk was originally submitted a colleague of mine, who could not travel due to a conflict in his schedule, so I can say I got to Jazoon with some portion of luck this year You can find the final slides from my presentation here.
Overall the conference was smaller in attendance and quieter compared previous years. My estimate is around 500 attendees. This was in contrast with the large amount of sessions. Session quality varied both in content and speaker, yet during all three days I was almost always able to choose a good session. From the Java technical sessions, I found particularly interesting the talks on the future of Java by Danny Coward, Using Graddle, Play! web framework, Jazoon Rookie talk on boosting productivity with Hudson/Jenkins, Gerrit and Mylyn as well as the Web security talk by Frank Kim. The Animated Java Concurency presentation by Victor Grazi from Credit Suisse was worth watching too. You can checkout his animation project here.
From the SET track (SET = "Software Engineering Today", whatever that means) I really enjoyed the talk on Self-organizing teams by Joseph Pelrine. Also opening keynote on IaaS and PaaS by David Chapell and closing keynote on JavaSE/EE by Simon Ritter for the Jazoon, Day One were interesting, and - as one would expect - exceptionally well delivered. I was a bit disappointed by the opening keynote for the Jazoon, Day Two delivered by Linda Rising. Linda is a great speaker but I found her talk somewhat shallow in content this time, maybe I just had my expectations set too high. Also, I may be nitpicking here, but if a keynote speaker does not bother using the official conference presentation template, who should?
The closing keynote for the whole conference by Pouline Middleton was, despite somewhat prosy title, surprisingly refreshing. If you don't know Pouline and never heard of her fiction diary One Woman Three Men, which - interestingly - is based on her own personal life experience, you should check it out.
Jazoon.next
As I said earlier, the Jazoon conference was despite the large number of talks and a new track focused on Microsoft technology smaller in attendance compared to previous years. I can only speculate about the reasons, but hey, this is my blog, so here are my thoughts:
Jazoon organisers need to decide who is their target audience. Zurich is an expensive location and the conference fee is not particularly low either. With that, the conference should IMO retain a narrow focus to be able to provide quality that would justify the premium price. Broadening the scope may not be the best strategy for such conference. I am not sure that adding Microsoft track to a conference with a name suggesting a Java related content was necessarily a good decision. (And I say that despite the fact that I won a really cool mouse and an XBox game in the Kinect-powered virtual Wheel of Fortune at Microsoft booth.) For one reason or another, the sessions on the Microsoft track were poorly attended. Obviously this track did not attract many new attendees to Jazoon.
The amount of sessions this year was astonishing. If my calculations are correct, there were 112 (!) sessions delivered at Jazoon this year. That's a huge number compared to the number of attendees. The problem with the number is that the high number seemed to be achieved at the expense of the quality of the talks and/or speakers. In future, the Jazoon organisers should do better job in reviewing quality of the submitted talks AND the quality of speakers. The way I see it, much smaller amount of high(er)-quality speakers and sessions could attract many more people. Sometimes simply less is more.
On a similar note, I was surprised that organisers still did not implement any means for collecting an immediate feedback from attendees on the quality of the sessions and speakers. Such data would help them in their submission reviews in the coming years. Also, using just a single twitter aggregation page as the only dynamic content element is just not enough for a technical conference these days anymore.
At last, I find it somewhat unreasonable to host a conference for 500 people in a venue with capacity to host simultaneously 10 sessions for more than 2000 attendees in total. It seems to me that smaller venue could help to reduce the costs of the conference and as such make the fees more affordable.
All right, enough ranting. I would like to state that despite all of the above I had a good time and I found the conference refreshing and inspiring. I hope the conference organisers will be successful in helping Jazoon to regain its former momentum, so that it remains a relevant international Java conference for the years to come. Good luck, Jazoon!