5

I am currently porting an open source library to be JDK9+ compliant, and it depends on some of the Java EE Modules that have been deprecated in Java 9 and removed in Java 11: specifically, JAXB, JAX-WS and javax.annotation.

I added explicit dependencies to the third party implementations as suggested here:

<dependency>
  <groupId>com.sun.xml.ws</groupId>
  <artifactId>jaxws-ri</artifactId>
  <version>2.3.0.1</version>
</dependency>
<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-ri</artifactId>
  <version>2.3.0.1</version>
</dependency>
<dependency>
  <groupId>com.sun.activation</groupId>
  <artifactId>javax.activation</artifactId>
  <version>1.2.0</version>
</dependency>

However, I'd like my library to use them only if necessary (i.e., on JDK9+) and keep using the endorsed implementations on JDK8.

I can do so by adding the dependencies in a Maven profile to be activated only on JDK 9 and above, but what if I wanted to publish the jar file for my library on Maven Central? Should I publish two different jars, one with the Java EE third party implementations included, for JDK9+ and one without for JDK8?

Is there a way to produce a jar file that will use the third party implementations on JDK9+ and the endorsed ones on JDK8?

I have looked into multi-release jars, but looks like they are intended for jdk version-dependent implementations among project classes, not among dependencies.

Also, in case it's not possible to use the endorsed implementations on JDK 8, is there a way to reliably test that using the third party implementations does not introduce any regressions?

Raibaz
  • 9,280
  • 10
  • 44
  • 65
  • 4
    Can you please detail out the step *but I'd like my library to use them only if necessary and keep using the endorsed implementations on JDK8*? .. *Should I publish two different jars*.. yes you can. – Naman Jan 02 '19 at 16:05
  • 3
    *is there a way to reliably test that using the third party implementations does not introduce any regressions?*.. that would be users(you) trying it out, isn't that the way open source community works? – Naman Jan 02 '19 at 16:07
  • 2
    Maybe you can be specific about what implementations you're using and get to solve it using the MR-JARs. But cannot comment further on them unless one gets to know for what are you depending on the (which)JavaEE modules. – Naman Jan 02 '19 at 16:09
  • 2
    You can leave the dependencies optional, and recommend which one to add for Java 11 onwards. – Thorbjørn Ravn Andersen Jan 02 '19 at 20:30
  • Create 2 separate version for both java 8 and java 9+. That is what we did when we upgrade our framework from java 8 to java 10. – Keaz Jan 13 '19 at 07:05
  • @Raibaz - Please take a look at the answer and comment so we can find the right solution for your needs. – John Camerin Jan 15 '19 at 21:04

1 Answers1

1

Is there a way to produce a jar file that will use the third party implementations on JDK9+ and the endorsed ones on JDK8?

Unfortunately, no. When distributing a library via jar file, you cannot control how other jars and libraries will be listed in the classpath. This makes class loading non-deterministic for you. What that means for your situation is that if the aforementioned libraries are included in the classpath in a JDK8 environment, there is no way to determine or control which version of the classes get loaded.

Also, in case it's not possible to use the endorsed implementations on JDK 8, is there a way to reliably test that using the third party implementations does not introduce any regressions?

As the author, it would be up to you to execute tests across the different runtime environments to check for regressions.

Should I publish two different jars, one with the Java EE third party implementations included, for JDK9+ and one without for JDK8?

This is a perfectly reasonable solution which others have used before as well. Take for example the sqlserver jdbc jars, which have different versions based on jre: https://learn.microsoft.com/en-us/sql/connect/jdbc/using-the-jdbc-driver?view=sql-server-2017 For the case described here, the JDK9+ version of the jar could declare the additional dependencies you mentioned in the question, whereas the JDK8 version would not.

One other option would be to have a single jar and to declare the dependecies you mentioned as provided. This would signal to the consumer that the runtime environment must include the classes in the declared dependencies. Some documentation would be called for to direct the consumer of the library as to when to they must explicitly add the jars declared as provided to their classpath.

IMHO, the clearest solution is two jars with a reference to the JRE version in the jar name and differing dependencies. It requires very little documentation (which most dont look at anyway). And it allows you to make changes in your library more freely.

John Camerin
  • 677
  • 5
  • 15