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.

12 thoughts on “On JAX-RS 2.0 from Devoxx

  1. javajoe

    really disappointed to see you dropping the MVC support for JAX-RS 2.0. Other platforms like .net have both component based web framework (webforms) and action based framework like ASP.NET mvc. We need to keep up with our competitors. JSF is not a once size fits all web framework. We need a mvc framework that tightly integrates with all the javascript frameworks of the day.

  2. Marek Potociar Post author

    While I understand that you may not find it ideal, dropping MVC from JAX-RS means only we are not going to standardise anything as part of the spec (at the moment). It does not however preclude any proprietary extensions or integrations with any other existing MVC frameworks out there.

  3. amsellem yves

    Those are great news and I’m glad you look deeper into adding links to the HTTP body. Without them, HATEOAS will still be Fielding’s foolish dream: but it deserves more. Navigating through links helps hiding most of the resources which uncouple clients from server. With HATEOAS, REST APIs can be reduce in the same fashion your experts reduce the number of JAX-RS 2 API classes to 14.

  4. amsellem yves

    The client API seems more complicated than Jersey’s existing one: ClientFactory.newClient().target(location).request(mediatype).post(body, result) seems less accurate than Client.create().resource(location).type(mediatype).post(result, body). Your post() arguments seem right – the body before – but request() to set the mediatype is very confusing and target to set the endpoint do not seems as accurate as location() or resource().

    Besides, there’s something not clear to me about Transition Links/Structural Links. Can you please explain where those Transition Links will be set? The HTTP body can have a structure with transitions IMO.

    Thanks a lot.

  5. javajoe

    And that’s the problem. Lets give a conservative estimate that 60% of projects will NOT choose JSF as there preferred web framework. Instead, we now have to go and download say Spring to use its MVC framework. The one stop shop (Java EE 1.6/1.7) is no longer a one stop shop. Now that we have Spring in our project should we just forget about JAX-RS and use the Spring’s Rest support ? The same problem occurred when we needed a simple IOC container. If we were using Java EE 1.5 and wanted descent IOC we had to use Spring. Now that we have CDI we no longer have to use Spring. But wait, we do …. because we can’t stand JSF and using a Servlet and JSP solution is rather antiquated. Ok, lets just bring in Spring and it’s million dependencies. We are back to square one. Even worse should we use EE or Spring since EE does not provide the things we are looking for.

  6. Marek Potociar Post author

    I would argue that the new client API is more accurate. But it’s definitely a matter of taste. Also, the JAX-RS API is about half-size in terms of classes. That said, we’re still in the EDR phase, so thinks can still get renamed and updated to optimise. Feel free to send concrete suggestions to the JAX-RS-SPEC users mailing list.

  7. Marek Potociar Post author

    Not sure what you expected from the MVC support in JAX-RS, but if you expected JAX-RS to evolve into yet another presentation framework, that was actually never our goal. The idea was to look at JAX-RS resources as controllers and provide a direct integration layer for view frameworks, starting with JSP, but enabling others as well. Look at the original proposal: http://jcp.org/en/jsr/detail?id=339

    From that perspective we are not adding any magic to make life of developers easier, but we certainly do not prevent developers from using a presentation framework of their choice. And again, coming up with an alternative to JSF was never our goal.

  8. javajoe

    I would argue that what you just said is largely what 90% of these MVC frameworks do. They are just controllers that can integrate with various view technologies. In some cases a pure JavaScript front end. So yes I believe there is still a need for that. Large organizations like the one I work for (PAYING ORACLE CUSTOMERS) are forced to shop around for “YET another” framework to provide this functionality.

    FYI – we did not need “YET another” IOC container but we did it anyway with EE 1.6.

  9. Pingback: Distributed Weekly 130 — Scott Banwart's Blog

  10. Pingback: Java EE versus Spring: retomando a discussão | blog.caelum.com.br

  11. Pingback: Duchess | Blog | Devoxx:The present and the future of JAX-RS and Jersey, Marek Potociar

Leave a Reply

Your email address will not be published. Required fields are marked *