Marek Potociar'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.