Selectively using third-party implementation for deprecated JavaEE modules

Multi tool use
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?
java maven java-ee java-9 java-11
|
show 1 more comment
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?
java maven java-ee java-9 java-11
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 2 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 2 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 2 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 2 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 at 7:05
|
show 1 more comment
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?
java maven java-ee java-9 java-11
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?
java maven java-ee java-9 java-11
java maven java-ee java-9 java-11
edited Jan 3 at 10:23
Raibaz
asked Jan 2 at 16:01
RaibazRaibaz
4,19863147
4,19863147
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 2 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 2 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 2 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 2 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 at 7:05
|
show 1 more comment
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 2 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 2 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 2 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 2 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 at 7:05
4
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 2 at 16:05
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 2 at 16:05
3
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 2 at 16:07
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 2 at 16:07
2
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 2 at 16:09
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 2 at 16:09
2
2
You can leave the dependencies optional, and recommend which one to add for Java 11 onwards.
– Thorbjørn Ravn Andersen
Jan 2 at 20:30
You can leave the dependencies optional, and recommend which one to add for Java 11 onwards.
– Thorbjørn Ravn Andersen
Jan 2 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 at 7:05
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 at 7:05
|
show 1 more comment
1 Answer
1
active
oldest
votes
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://docs.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.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54009434%2fselectively-using-third-party-implementation-for-deprecated-javaee-modules%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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://docs.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.
add a comment |
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://docs.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.
add a comment |
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://docs.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.
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://docs.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.
answered Jan 13 at 2:33


John CamerinJohn Camerin
446212
446212
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54009434%2fselectively-using-third-party-implementation-for-deprecated-javaee-modules%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
SQxGc7ehUwe8,oKkojA3i0uUWnnLm3K57nMczWj1xElb3Hy,Lw V
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 2 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 2 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 2 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 2 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 at 7:05