Multi release jar support.

[dbalek]

Added test for multi release jar support.

[JaroslavTulach]

The test is passing. Does that mean NetBeans already supports multi release JARs?

[jlahoda]

The test is passing. Does that mean NetBeans already supports multi release JARs?

Did you try to run the test on both JDK 8 and JDK 11? Because, obviously, for a multi-release jar test, one must run on multiple JDKs.

Travis was not running(!) any(!) platform tests on anything newer that JDK 8(!!), so I've added at least o.n.bootstrap on JDK 11. I wonder what this says about NetBeans platform support for JDK 11, 17, ... .

[JaroslavTulach]

Test org.netbeans.JarClassLoaderTest FAILED
Test org.netbeans.nbexec.NbExecPassesCorrectlyQuotedArgsTest FAILED

[oyarzun]

@dbalek I took a stab at implementing muti-release support. https://github.com/oyarzun/netbeans/commit/c879b33c2e3296c33a917a75a4d89d69cfb80675

[oyarzun]

@dbalek @JaroslavTulach any thoughts on getting this into NB15?

[neilcsmith-net]

@dbalek when (re)targetting delivery, please add your reasoning, thanks!

[dbalek]

@dbalek when (re)targetting delivery, please add your reasoning, thanks!

OK - target milestone changed back to NB16.

[neilcsmith-net]

@dbalek that wasn't a request to move it back to NB16. I just wanted to understand the reasoning, pros and cons for getting this into NB15. This will affect library loading I believe? So do we know which dependencies we have are MRJ and therefore might behave differently? Are there related issues this will fix / affect besides the obvious one in the platform?

cc @oyarzun

[oyarzun]

@neilcsmith-net @dbalek Since this changes the class loader, I vote +1 for targeting NB16 to have a longer period of testing. As far as I know the only issue (NETBEANS-3679) it fixes is allowing the platform to use multi-release jars on JDK9+. (e.g. log4j which came up on the dev mailing list.)

https://issues.apache.org/jira/browse/NETBEANS-3679 https://lists.apache.org/thread/plkhc38f5g7cxgv6p53hg5s1k9x3mrvt https://lists.apache.org/thread/sp2ngsp0qmhptvts2rwhprqfrb7f0bpl

[neilcsmith-net]

Thanks @oyarzun - I'd missed that reference on list. We also have MRJs in the IDE.

If my bash-fu is correct, then running this over NB15-rc1

for i in `find . -name "*.jar"`; do jar tvf $i | grep META-INF/versions/ > /dev/null ; if [ $? == 0 ]; then echo "$i"; fi; done

gives us the following files in the IDE that might start behaving differently (well, correctly!) in some fashion?

./enterprise/modules/ext/metro/webservices-tools.jar
./enterprise/modules/ext/metro/webservices-api.jar
./enterprise/modules/ext/metro/webservices-rt.jar
./enterprise/modules/ext/jersey2/jersey-common-2.34.jar
./enterprise/modules/ext/jersey2/jakarta.xml.bind-api-2.3.3.jar
./java/modules/ext/byte-buddy-1.10.6.jar
./java/modules/ext/maven/lucene-core-8.11.1.jar
./java/modules/ext/jaxws22/jaxws-rt.jar
./java/modules/ext/jaxws22/jaxws-tools.jar
./java/modules/ext/nb-javac-jdk-18-api.jar
./platform/modules/ext/flatlaf-2.4.jar
./webcommon/modules/ext/js-20.3.0.jar
./ide/modules/com-jcraft-jsch.jar
./ide/modules/bcpg.jar
./ide/modules/bcprov.jar
./ide/modules/bcpkix.jar
./ide/modules/bcutil.jar
./ide/modules/ext/truffle-api-20.3.0.jar
./ide/modules/ext/jaxb/jaxb-impl.jar
./ide/modules/ext/jaxb/api/jaxb-api.jar
./ide/modules/ext/jaxb/jaxb-xjc.jar
./ide/modules/ext/junixsocket-common-2.4.0.jar
./ide/modules/ext/junixsocket-native-common-2.4.0.jar

[matthiasblaesing]

I just tried to use MR support to see if this fixes #4393. JSch bundles a class that uses the UnixDomainSocket support in JDK 16+, but it requires Multi-Release support. So I thought this PR should fix the issue, turns out, that I was wrong. JSch is loaded by OSGI support (netbinox), which does not support MR jars.

[neilcsmith-net]

@mbien just realised that one of the JARs listed above that has a lot of MRJ affected classes is lucene. Anything of concern? Possible source of any current issues?

[mbien]

@mbien just realised that one of the JARs listed above that has a lot of MRJ affected classes is lucene. Anything of concern? Possible source of any current issues?

@neilcsmith-net i looked into the jar and it has a version 9 in it. And the default is 8. Diffing with the decompiler showed that lucene is doing MRJ to get some extra APIs from java.lang.Objects and similar earlier. If thats all they are using it for, it wouldn't even matter what version is loaded on 11+, since they provided their own "FutureObjects" impl for 8 obviously (looks like unnecessary complexity to me tbh, but I haven't diffed everything).

They don't track the lucene 8.x branch on github anymore, we are using an EOL version and lucene 9+ moved to JDK 11+. We patched a single file https://github.com/mbien/netbeans/commit/35b41f641d1022d05878c848514efcfe691ecca4 in #3558, this file has only one version in lucene-core-8.11.1.jar - nothing can go wrong there either.

I assume you are asking because the "default" jar was loaded before, but after the change the "correct version" will be picked, which would be 9 in lucene's case?

I don't think this will cause problems.

(also holy cow I just edited your post instead of commenting in my own, i need a coffee haha)

[matthiasblaesing]

@dbalek could you please check whether this can be merged now? I looked at the OSGI side and I thought this was already in, we are early in the NB16 cycle, so now would be a good time.

[matthiasblaesing]

There is at least one remaining problem:

The command "hide-logs.sh ant $OPTS -f platform/core.startup test" exited with 1.

[matthiasblaesing]

Changes are merged via #4589