JAX-RS in relation to Jersey and JSRs

Question

I'm trying to get my head around some concepts in Java:

1. JSR(s): describe specifications, but carry no actual implementations. E.g. http://jsr311.java.net/ is the "home" for "Java™ API for RESTful Web Services". It serves as a common reference for all implementations of JSR-311.
2. One can download the interfaces (?) of JSR-311 from http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api, however, unless you are implementing JSR-311 by yourself these have no particular value?
3. JSR(s) will usually/always have a reference implementation. To find it you'll have to google "JSR XXX reference implementation" or see the specifications home page (e.g. http://jsr311.java.net/)
4. For JSR-311 this reference implementation is Jersey. Using maven you can get the jersey server from http://mvnrepository.com/artifact/com.sun.jersey/jersey-server/1.9. Since Jersey provides an implementation according to the interfaces found in http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api, you only need to add Jersey as a dependency in your project and not the jsr311-api itself. (this applies to all JSR technologies?)
5. Putting both http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api and http://mvnrepository.com/artifact/com.sun.jersey/jersey-server/1.9 as dependencies in your project will possibly cause classpath problems?

Am I completely off or onto someting?

Wrongful

Answer 1

1. Yes, this isn't anything new. Think about JDBC, java provides the interfaces (Connection, Statement, ResultSet etc) but it is up to database vendors to provide implementations.

2. If you're using a JSR-311 implementation like Jersey or Apache CXF then you'll annotate your classes with the javax.ws.rs annotations, such as @Path, @GET, @Produces etc. This is why you need to explicitly have JSR-311 as a maven dependency.

3. Yes, usually. Have a look at the JSR list on wiki.

4. You need both the JSR and the implementation. The annotations are in the JSR, the implementation provides supporting classes, such as com.sun.jersey.spi.container.servlet.ServletContainer.

5. No, it is necessary to have both as dependencies (see point 4); you won't get classpath conflicts.

Pallbearer

So perhaps the real question is why doesn't jersey declare jsr-311 as a dependency, instead of duplicating the classes inside its own jar? – Ashtray

Answer 2

1. —
2. One can download files from a variety of sources. To get the most official version of the JSR-311 specification go to its JCP download page. It's quite possible that you can't get a JAR file (with all the interfaces and stuff) from JCP pages, but still, this is the official source. (There are always nice PDFs of public drafts also!)
3. —
4. You're right, because Jersey contains the API defined by JSR-311, however I would add a compile dependency to the jsr311-api JAR file and add Jersey as runtime dependency. This creates a nice separation between API and implementation and you can swap out your JSR-311 implementation anytime [sic]. If you intend to use Jersey all the way include only Jersey. One less dependency in your POM.
5. If Jersey packages the same API as the jsr311-api JAR contains, it won't. If it packages something different, well, that would be awful! Maven will probably bark at compile time if one has a corrupt JSR-311 API on its classpath (I've already seen lots of java.lang.ClassFormatError: Absent Code attribute in method that ... errors, so it won't go unnoticed, that's for sure).

Other than these, you're right.

Reta