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

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.

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.