12

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?

Mads Mobæk
  • 34,762
  • 20
  • 71
  • 78

2 Answers2

9

  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.

Qwerky
  • 18,217
  • 6
  • 44
  • 80
  • 1
    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? – Daniel Flower Apr 01 '16 at 08:41
3
  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.

Kohányi Róbert
  • 9,791
  • 4
  • 52
  • 81