Classloading with multiple parent layers JDK11 vs JDK14
Hi all, I have the following layers: LayerA (moduleA) LayerB (moduleB) |_| | LayerC(moduleC) LayerC has two parent layers layerA and LayerB and moduleC requires moduleA and moduleB. When I start my application with JDK 11/14 I get no resolving errors and everything is ok. However, when I use JDK 11 in moduleC when I use application I get java.lang.NoClassDefFoundError moduleB.Foo.class, when I run with JDK 14 I don’t get such exception. The JDK I use listed below. Could anyone say — the behavior differs because of the different JDKs, or the problem is that when multiple layers are parent there is possibility that class won’t be found, or the problem is in my application? JDK 14: openjdk version "14" 2020-03-17 OpenJDK Runtime Environment (build 14+36-1461) OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing) JDK 11: openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) pavel@pc1:~/WorkAndShow/Server/bin$ -- Alex Sviridov
Re: RFR: 8242452: During module definition, move conversion of packages from native to VM
Hi Harold,
On 2020-04-17 15:32, Harold Seigel wrote:
Hi Claes,
The change looks good. Just a couple of minor things.
thank you for reviewing!
In JavaClasses.cpp, line 652, does length need to be initialized to zero?
Good point, most of the length variables passed by reference to retrieve
the length can be left uninitialized.
The indentation looks wrong at line 658.
Hmm, yeah. Not sure how to make it look right, though.
The changes in modules.cpp look good! Maybe as_symbol() could
eventually be moved to symbolTable.hpp.
Seems reasonable, but as I want to avoid Handle'ing the oop I felt more
comfortable with a local utility method for now.
Very minor typos in modules.hpp ("to to").
Fixed both places.
http://cr.openjdk.java.net/~redestad/8242452/open.02/
Have verified VM module tests locally and re-running a sanity tier1
before push.
I don't need to see another webrev.
One change that we looked at but did not do is to have one call from the
JDK to the JVM to, for example, add all of a module's qualified
exports. Currently, each export is a separate call from the JDK to the
VM. I'm not sure if this is worth doing.
Could be, but I think we'd have to refactor the interaction more to be
able to turn it into a real gain.
A less granular API might be better suited for archiving optimizations,
which I know Ioi has been giving some thought to. That is: we're able to
archive the java object model for module descriptors and the default
model graph - why not also the VM model? Not today, but let's keep the
door open. :-)
/Claes
Re: RFR 8242859: test/jdk/tools/jlink/JLinkTest.java uses nashorn module
+1 > On Apr 17, 2020, at 7:06 AM, sundararajan.athijegannat...@oracle.com wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242859 > > Webrev: http://cr.openjdk.java.net/~sundar/8242859/webrev.00/ > > Relevant JLinkTest.java section deleted as part of nashorn removal is as > follows: > > http://cr.openjdk.java.net/~sundar/8241749/webrev.00/test/jdk/tools/jlink/JLinkTest.java.udiff.html > > It was using nashorn module as an example. Using jdk.jshell with the current > change. > > Thanks > > -Sundar > > > >
Re: RFR (T): 8242846: removed an empty file test/jdk/tools/jlink/plugins/OrderResourcesPluginTest.java
Hi, The original email is waiting for moderator approval. Subscribed to jigsaw-dev and resent the RFR (cc'ed core-libs-dev). Thanks, Ao Qi On Wed, Apr 15, 2020 at 10:11 PM Ao Qi wrote: > > Hi all, > > test/jdk/tools/jlink/plugins/OrderResourcesPluginTest.java was changed > to an empty file by JDK-8162538, but not removed. I think we should > remve this file. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242846 > webrev: http://cr.openjdk.java.net/~aoqi/8242846/webrev.00/ > > Thanks, > Ao Qi
RFR 8242859: test/jdk/tools/jlink/JLinkTest.java uses nashorn module
Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8242859 Webrev: http://cr.openjdk.java.net/~sundar/8242859/webrev.00/ Relevant JLinkTest.java section deleted as part of nashorn removal is as follows: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/test/jdk/tools/jlink/JLinkTest.java.udiff.html It was using nashorn module as an example. Using jdk.jshell with the current change. Thanks -Sundar
Re: RFR 8242860: test/jdk/tools/jlink/ModuleNamesOrderTest.java uses nashorn module
On 17/04/2020 07:21, sundararajan.athijegannat...@oracle.com wrote: Hi, nashorn modules were used only as an example in this test. Using jdk.jshell module instead to test known module dependencies in jlink produced images. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8242860 Webrev: http://cr.openjdk.java.net/~sundar/8242860/webrev.00/ Looks okay.
RFR 8242860: test/jdk/tools/jlink/ModuleNamesOrderTest.java uses nashorn module
Hi, nashorn modules were used only as an example in this test. Using jdk.jshell module instead to test known module dependencies in jlink produced images. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8242860 Webrev: http://cr.openjdk.java.net/~sundar/8242860/webrev.00/ Thanks, -Sundar
