[NEXUS-19183] Java JDK JRE 11/17 runtime support

[marob]

Original issue: https://issues.sonatype.org/browse/NEXUS-19183 (https://web.archive.org/web/20230517160610/https://issues.sonatype.org/browse/NEXUS-19183)

Java 8 is not supported anymore for more than a year (2022/03/31).
Nexus has to be upgraded to support (at least) Java 11 and ideally Java 17 ASAP.

I'm not sure if any comment from the original issue has to be copied here as most of them are exasperation from the more than 4 years of waiting...

[michael-o]

Original issue: https://issues.sonatype.org/browse/NEXUS-19183

Java 8 is not supported anymore for more than a year (2022/03/31). Nexus has to be upgraded to support (at least) Java 11 and ideally Java 17 ASAP.

I'm not sure if any comment from the original issue has to be copied here as most of them are exasperation from the more than 4 years of waiting...

ASAP? What a bold statement! OpenJDK 8 is supported until 2030. Stop spreading FUD.

[marob]

While OpenJDK 8 may still be maintained, it's no more available in Debian repository since Debian 10.
Because Debian 9 is not maintained anymore, there's no way to have a maintained combination of Debian + OpenJDK 8 to host Nexus today.

Installing OpenJDK manually (not from OS repository) is not an admissible solution as it wouldn't benefit from OpenJDK security patches automatically.

So, current situation forces to choose another linux distribution than Debian (like Ubuntu 22.04 for example), which is an issue in my opinion.

[michael-o]

While OpenJDK 8 may still be maintained, it's no more available in Debian repository since Debian 10. Because Debian 9 is not maintained anymore, there's no way to have a maintained combination of Debian + OpenJDK 8 to host Nexus today.

Installing OpenJDK manually (not from OS repository) is not an admissible solution as it wouldn't benefit from OpenJDK security patches automatically.

So, current situation forces to choose another linux distribution than Debian (like Ubuntu 22.04 for example), which is an issue in my opinion.

Well, then this is a Debian-specific problem and you should complain to the Debian OpenJDK maintainer, no? I consider this as a serious mis-decision from the Debian package maintainer. 8 will survive 11 for sure.

[marob]

Well, IE6 survived a lot of newer browsers. Was staying compatible with it a good decision?

Then, for you, that's OK to stay on old JDK version to not benefit from better performance, better compatibility with new OSs and so on?
Let's wait for 2030 to do a painful upgrade to JDK 35 then if that's the best solution.

[michael-o]

Well, IE6 survived a lot of newer browsers. Was staying compatible with it a good decision?

Then, for you, that's OK to stay on old JDK version to not benefit from better performance, better compatibility with new OSs and so on? Let's wait for 2030 to do a painful upgrade to JDK 35 then if that's the best solution.

You are mixing two issues here:

• Nexus
• Debian

Both overlap to some extend, but do not relate.

[marob]

There's no Debian issue, only a Nexus one.
Instead of debating on how long which version of Nexus/OS is maintained or not, what's the reason NOT to make Nexus compatible with JDK 17?

[nblair]

This item is on our radar and has an internal ticket. Please follow the release notes for updates. Will close the issue here as a duplicate.

[ViliusS]

This item is on our radar and has an internal ticket. Please follow the release notes for updates. Will close the issue here as a duplicate.

Then add internal ticket number here and leave it open. Since GitHub issues are the only way now to provide feedback on Sonatype Nexus Repository features and bugs, or have a discussion, or track tickets, I don't understand why this issue is closed.

Or are you saying that public feedback of OSS users are no longer welcome?

[danischroeter]

@ViliusS fully agree. The way tickets are being handled for oss users does not seem well thought through.
@nblair If oss tickets in github get closed when some invisible internal ticket exists and no direct feedback is provided they are useless. On top of that I assume people will then start creating new issues which will make your job quiet hard 🤔

[nblair]

Thank you @ViliusS and @danischroeter for your suggestions. I’ll start with the last comment first: public feedback of OSS users is absolutely welcome and encouraged.

In the former world for Sonatype (see #105), we had one Issue Tracker for Sonatype Nexus Repository. https://issues.sonatype.org/browse/NEXUS was accessible by the public at large and Sonatypers. We could have public and private issues coexist in one issue tracker. This served us really well for a long time.

This migration is certainly asking us to change something that was well loved by all parties involved, I’m sorry for that. We believe this to be a positive change for the product and the community of Sonatype Nexus Repository, but know it will take time to adjust our process and communication.

One strong requirement we have is that our product development teams have only one Issue Tracker to focus on. This has many virtues, but primarily helps the team focus in on Sonatype’s priorities for the product. Github Issues is insufficient for our needs in order to effectively manage Sonatype’s products.

We’ve had to take a leap of faith to try something new, and I can’t say enough how thrilled I am to see the community engaging here. We’ll keep improving and iterating to make sure your voices are heard and help improve the product.

Let me take your feedback here and think about how I can provide transparency on how your feedback transforms into ideas internally, and how you can get notified for updates.

[ViliusS]

I've read and understand your motives regarding Jira Server product in #105 and in comments elsewhere. I've done a fair amount of Jira migrations myself in companies where I have worked/work for, and believe me I feel your pain.

But what I constantly see is that companies are misusing issue trackers. Some of them just close issues because they want to reach promised SLA, others are closing because they feel that having a big backlog is not maintainable. However, what most of them need to understand is that these tools would not exist without two parties taking part, i.e. they are not only helping development internaly, but also helping the reporting party in their own plans, implementations, tracking showstoppers, etc.

In one company I have worked for we had a special field in our internal task tracking system for issue IDs from various external providers. This was a very simple, universal and convenient way to track tasks which depend on 3rd party. Such recorded knowledge would never get lost, even after team member changes, for example.

This also works internally if, let's say, you have two issue tracking systems. I don't know what software you are using internally but I do believe GitHub bot which sinchronizes GitHub issue status with you internal system should be pretty simple task.

Hopefully this gives you more feedback into how I have used your old issue tracker.

[mdeggers]

This is certainly disturbing. As one of the commenters of this issue, I find it disturbing that I no longer have visibility into what we consider to be an increasingly important issue. Tracking progress via announcements on Sonatype's blog and release announcements has been troublesome for some time.

I do hope that you will consider leaving an issue open so that some transparency is maintained.

[nblair]

Point taken @mdeggers and @ViliusS, appreciate the feedback. We're learning the ropes with this new engagement tool, so we're bound to make a few mistakes. I'll re-open for visibility.

I think the silver lining I want to express is that all the votes and activity on the source Jira ticket actually mattered. All the votes and customer interest helped make the business case. We made the decision long ago that this is a concept we will take on and have secured budget to perform the work. It's less a matter of if and now a when, and some of the specifics (which versions, what does the migration path look like, etc). I can't advertise the date or expected version at this time.

We're aware of the tooling to link github and Jira, but this project isn't and can't be connected to the development effort, so you won't get the play by play, apologies for that. I'm happy to keep this open and replay the news here when we are ready to take this effort to market.

[laa88rf]

Hello.

I try to install nexus-3.61.0-02-unix.tar.gz

I don't understand how to launch nexus.
You have properties:

`root@nexus3-1:/opt/nexus-3.61.0-02# cat bin/nexus.vmoptions

-Xms2703m
-Xmx2703m
-XX:MaxDirectMemorySize=2703m
-XX:+UnlockDiagnosticVMOptions
-XX:+LogVMOutput
-XX:LogFile=../sonatype-work/nexus3/log/jvm.log
-XX:-OmitStackTraceInFastThrow
-Djava.net.preferIPv4Stack=true
-Dkaraf.home=.
-Dkaraf.base=.
-Dkaraf.etc=etc/karaf
-Djava.util.logging.config.file=etc/karaf/java.util.logging.properties
-Dkaraf.data=../sonatype-work/nexus3
-Dkaraf.log=../sonatype-work/nexus3/log
-Djava.io.tmpdir=../sonatype-work/nexus3/tmp
-Dkaraf.startLocalConsole=false
-Djdk.tls.ephemeralDHKeySize=2048

comment out this vmoption when using Java9+
`

Ok.
I try to uncomment it, and have the following notice:
root@nexus3-1:/opt/nexus-3.61.0-02/bin# ./nexus run No suitable Java Virtual Machine could be found on your system. The version of the JVM must be 1.8. Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.

Java version:
root@nexus3-1:/opt/nexus-3.61.0-02/bin# java --version openjdk 17.0.9 2023-10-17 OpenJDK Runtime Environment (build 17.0.9+9-Debian-1deb12u1) OpenJDK 64-Bit Server VM (build 17.0.9+9-Debian-1deb12u1, mixed mode, sharing)

How to solve it?
Thank you.

Sorry for my .md

[nblair]

Hi @laa88rf - it is not possible to run Nexus Repository on Java 9+ at this time, only 8 is supported.

An update for others on the thread: adding support for a more contemporary version of Java is now actively under development by our teams. Getting past Java 9 requires significant changes due to our reliance on OSGi and internal customizations. We are optimistically looking for releasing a version in the first half of 2024 that supports a more modern Java version.
(edit - thanks @michael-o !)

[michael-o]

Hi @laa88rf - it is not possible to run Nexus Repository on Java 9+ at this time, only 8 is supported.

An update for others on the thread: adding support for a more contemporary version of Java is now actively under development by our teams. Getting past Java 9 requires significant changes due to our reliance on OSGi and internal customizations. We are optimistically looking for releasing a version in the first half of 2023 that supports a more modern Java version.

2024

[somera]

We have 2023 and Java 21 is out.

Will Nexus than run under Java 21?

[laa88rf]

One more question.
Does Nexus Enterprise version support JDK21?

Thank you.

[mhayden-dmatrix]

We are also waiting for Nexus3 to support a newer version of Java than Java8.
Thank you

[goodale]

what's the status on this? Java 1.8 has been end-of-life and yet Sonatype doesn't provide users and customers any update or roadmap as to when Nexus will support Java 17 let alone Java 11?

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

There's a comment above saying, '2024', which from a business perspective is quite vague. Typically at least a quarter is provided (e.g. 1Q2024, 2Q2024, etc). It is concerning why this is taking so long.

[michael-o]

what's the status on this? Java 1.8 has been end-of-life and yet Sonatype doesn't provide users and customers any update or roadmap as to when Nexus will support Java 17 let alone Java 11?

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

There's a comment above saying, '2024', which from a business perspective is quite vague. Typically at least a quarter is provided (e.g. 1Q2024, 2Q2024, etc). It is concerning why this is taking so long.

Stop spreading FUD. Oracle JDK is EOL, not Java 8.

[goodale]

@michael-o My apologies - I stand corrected. still curious when any of the latest LTS's releases (11, 17 or 21) will be supported

[stevesobol]

So, I'm updating to 3.63.01 RIGHT NOW, and I'm looking at nexus.vmoptions, with the commented-out options for people running Java 9 or newer, and suddenly, it hits me... the big showstopper right now is JPMS, isn't it.

Since I'm an OSS user right now, and I can't afford to pay for a license, but I've been using Nexus for a while, I'd be happy to contribute some effort towards getting over this particular hump. How does that work with Sonatype? I've signed CLAs before... it's no big deal to me...

[nblair]

Thanks for the offer @stevesobol - you are right, crossing the JPMS boundary is a big part of the effort. We appreciate the offer but we don't have a facility to accept contributions from the community into Nexus Repository. This effort is underway and did recently complete a key internal milestone. I'm optimistic about support landing in early 2024. Thanks for your patience!

[nblair]

Excited to share here that today's 3.67.0 release includes support to run all versions of Sonatype Nexus Repository on Java 11. The details can be viewed here:

https://help.sonatype.com/en/sonatype-nexus-repository-3-67-0-release-notes.html

We do expect to ship support for running on Java 17 in a subsequent release, but there is a catch. The embedded database used by OSS - OrientDB - won't run on anything later than Java 11.
We do have an alternative embedded database for OSS deployments that we will be announcing soon along with tooling to help you migrate.

Thanks for your patience!

[danshome]

@nblair I just downloaded 3.67.0.

However, if you try to use JDK 11 and then uncomment out the section

additional vmoptions needed for Java9+

in nexus.vmoptions you will get the following error...

./nexus run
Unrecognized option: --patch-module java.base=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.locator-4.3.9.jar
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Here is what the nexus.vmoptions looks like...

`-Xms2703m
-Xmx2703m
-XX:MaxDirectMemorySize=2703m
-XX:+UnlockDiagnosticVMOptions
-XX:+LogVMOutput
-XX:LogFile=../sonatype-work/nexus3/log/jvm.log
-XX:-OmitStackTraceInFastThrow
-Djava.net.preferIPv4Stack=true
-Dkaraf.home=.
-Dkaraf.base=.
-Dkaraf.etc=etc/karaf
-Djava.util.logging.config.file=etc/karaf/java.util.logging.properties
-Dkaraf.data=../sonatype-work/nexus3
-Dkaraf.log=../sonatype-work/nexus3/log
-Djava.io.tmpdir=../sonatype-work/nexus3/tmp
-Dkaraf.startLocalConsole=false
-Djdk.tls.ephemeralDHKeySize=2048

additional vmoptions needed for Java9+

--add-reads=java.xml=java.logging
--add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED
--patch-module java.base=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.locator-4.3.9.jar
--patch-module java.xml=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.java.xml-4.3.9.jar
--add-opens java.base/java.security=ALL-UNNAMED
--add-opens java.base/java.net=ALL-UNNAMED
--add-opens java.base/java.lang=ALL-UNNAMED
--add-opens java.base/java.util=ALL-UNNAMED
--add-opens java.naming/javax.naming.spi=ALL-UNNAMED
--add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED
--add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED
--add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED
--add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED
--add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
--add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED
--add-exports java.security.sasl/com.sun.security.sasl=ALL-UNNAMED

comment out this vmoption when using Java9+

-Djava.endorsed.dirs=lib/endorsed`

BTW...The only reason I'm even attempting JDK11 is because LDAP seems to be broke on 3.67.0 with JDK 8, so I'm trying JDK 11 with hopes that LDAP will work again.

[danshome]

@nblair I figured it out, looks like someone made a change to the nexus.vmoptions on your end and forgot to add the "=" to a number of the properties, once I fixed that it at least starts but there are a lot of ClassNotFound exceptions thrown.

For example:

2024-04-02 15:06:32,012-0500 ERROR [FelixStartLevel] *SYSTEM Felix - Bundle org.apache.felix.framework [0] EventDispatcher: Error during dispatch. (java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator)
java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator
at org.apache.karaf.specs.activator.Activator.register(Activator.java:125)
at org.apache.karaf.specs.activator.Activator.bundleChanged(Activator.java:97)
at org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915)
at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4817)
at org.apache.felix.framework.StatefulResolver.fireResolvedEvents(StatefulResolver.java:1300)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:512)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4363)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2281)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1539)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.base/java.lang.Thread.run(Thread.java:834)

[danshome]

@nblair Here is the OOB nexus.vmoptions from the Linux/Unix distribution. You probably want to have your developers review it because not only are their missing "=", but the second line with the --add-exports seems wrong as well.

`

--add-reads=java.xml=java.logging

--add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED

--patch-module java.base=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.locator-4.3.9.jar

--patch-module java.xml=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.java.xml-4.3.9.jar

--add-opens java.base/java.security=ALL-UNNAMED

--add-opens java.base/java.net=ALL-UNNAMED

--add-opens java.base/java.lang=ALL-UNNAMED

--add-opens java.base/java.util=ALL-UNNAMED

--add-opens java.naming/javax.naming.spi=ALL-UNNAMED

--add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED

--add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED

--add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED

--add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED

--add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED

--add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED

--add-exports java.security.sasl/com.sun.security.sasl=ALL-UNNAMED

`

[danshome]

@nblair I grabbed the binaries earlier today and it was named nexus-3.67.0-03-unix.tar.gz, but it looks like someone just updated the downloads for UNIX and there is now a nexus-3.67.0-03-java11-unix.tar.gz. I'm going to try that and see if that fixes the issue.

[danshome]

@nblair nexus-3.67.0-03-java11-unix.tar.gz works, hopefully I was the only one that downloaded the bad version :)

[danshome]

@nblair Just opened a new ticket #372 about LDAP being broken in the new release.

[ViliusS]

@nblair can you shed some light on what is the exact difference between https://download.sonatype.com/nexus/3/nexus-3.67.1-01-java8-unix.tar.gz and https://download.sonatype.com/nexus/3/nexus-3.67.1-01-java11-unix.tar.gz ? Is it only --add-export configuration mentioned above or also something else?
I'm looking to adjust Nexus Repository RPM package so that it is allowed to run with Java 11.

[nblair]

@ViliusS the changes are quite small and focused just in the launcher.

[ViliusS]

@nblair I need to know exactly, by "launcher" you mean options in nexus.vmoptions file or something else?

[ViliusS]

@nblair could you or somebody else from the team answer a question above? We really need to know the exact different between Java8 and Java11 version so that we can provide RPM package for the community.

[fbacchella]

When you says that OrientDB doesn’t run on Java 17, is that because of that: orientechnologies/orientdb#9426 ? But Nashon is still available, as a separate download: https://mvnrepository.com/artifact/org.openjdk.nashorn/nashorn-core

[eirnym]

@nblair

We do expect to ship support for running on Java 17 in a subsequent release, but there is a catch. The embedded database used by OSS - OrientDB - won't run on anything later than Java 11.

Java 17 is default java to build and target based on their source code.

https://github.com/orientechnologies/orientdb/blob/47196c80130ce0a39b0a29bc18bcdfff3e4e51f0/pom.xml#L149

[nblair]

@eirnym the link you reference above is for an in-development version of orientdb (4.0.x) which has no releases yet. The latest released version of OrientDB, 3.2.x, still targets Java 8.

Nexus Repository is using a far older version - 2.2.x. The path to update to a more contemporary version is not trivial and something we are not going to invest in. Keep an eye out for July's 3.70 release, expected July 9. We expect to make an announcement about availability for an alternative database that will support OSS users and is compatible with Java 17.

[eirnym]

Thanks for keeping us in the loop, I'm looking forward for this release

[mohideen]

@nblair I figured it out, looks like someone made a change to the nexus.vmoptions on your end and forgot to add the "=" to a number of the properties, once I fixed that it at least starts but there are a lot of ClassNotFound exceptions thrown.

For example:

2024-04-02 15:06:32,012-0500 ERROR [FelixStartLevel] *SYSTEM Felix - Bundle org.apache.felix.framework [0] EventDispatcher: Error during dispatch. (java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator) java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator at org.apache.karaf.specs.activator.Activator.register(Activator.java:125) at org.apache.karaf.specs.activator.Activator.bundleChanged(Activator.java:97) at org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915) at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834) at org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4817) at org.apache.felix.framework.StatefulResolver.fireResolvedEvents(StatefulResolver.java:1300) at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:512) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4363) at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1539) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) at java.base/java.lang.Thread.run(Thread.java:834)

I had the same issue, and the following changes helped resolve it.

 -# --add-reads=java.xml=java.logging
-# --add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED
-# --patch-module java.base=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.locator-4.3.9.jar
-# --patch-module java.xml=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.java.xml-4.3.9.jar
-# --add-opens java.base/java.security=ALL-UNNAMED
-# --add-opens java.base/java.net=ALL-UNNAMED
-# --add-opens java.base/java.lang=ALL-UNNAMED
-# --add-opens java.base/java.util=ALL-UNNAMED
-# --add-opens java.naming/javax.naming.spi=ALL-UNNAMED
-# --add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED
-# --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED
-# --add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED
-# --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED
-# --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
-# --add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED
-# --add-exports java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
+--add-reads=java.xml=java.logging
+--add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED
+--patch-module=java.base=./lib/endorsed/org.apache.karaf.specs.locator-4.3.9.jar
+--patch-module=java.xml=./lib/endorsed/org.apache.karaf.specs.java.xml-4.3.9.jar
+--add-opens=java.base/java.security=ALL-UNNAMED
+--add-opens=java.base/java.net=ALL-UNNAMED
+--add-opens=java.base/java.lang=ALL-UNNAMED
+--add-opens=java.base/java.util=ALL-UNNAMED
+--add-opens=java.naming/javax.naming.spi=ALL-UNNAMED
+--add-opens=java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED
+--add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED
+--add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED
+--add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED
+--add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
+--add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED
+--add-exports=java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
 #
 # comment out this vmoption when using Java9+
 #
--Djava.endorsed.dirs=lib/endorsed
+#-Djava.endorsed.dirs=lib/endorsed

@danshome, In addition to commenting/uncommenting the recommended section, and after fixing the missing = as you mentioned. I also had to fix these two lines to set the correct karaf home dir to get rid of the NoClassDefFoundError

-# --patch-module java.base=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.locator-4.3.9.jar
-# --patch-module java.xml=${KARAF_HOME}/lib/endorsed/org.apache.karaf.specs.java.xml-4.3.9.jar
+--patch-module=java.base=./lib/endorsed/org.apache.karaf.specs.locator-4.3.9.jar
+--patch-module=java.xml=./lib/endorsed/org.apache.karaf.specs.java.xml-4.3.9.jar

[ViliusS]

@nblair I know that you are probably busy, but could you or somebody else from the team answer a question, what is the difference between different Sonatype Nexus Repository versions for Java 8/11/17? Only in the mentioned options in nexus.vmoptions file or also something else?
We really need to know the exact specific difference so that we can add them to and provide Sonatype Nexus Repository RPM package for the community.

[eirnym]

@ViliusS the most important thing about difference between these Java versions are module access. The rest improvements doesn't hurt so much during migration, so if your app (including all third party dependencies) doesn't closed modules, it will work as it were.

Java 9 bring project Jigsaw in life. That means a program might not have access to some modules. This could provide deep refactoring in the future for internals without affecting backward compatibility.

Java 11 is an LTS which slightly closed access.

Java 17 closed access to private JVM modules even more.

Java 21 is even more restrictive.

[ViliusS]

@eirnym I know that, that's not what and why I'm asking.

[eirnym]

In pom.xml it's explicitly written that compile and target version is 8, so I expect no other differences than vmoptions.