Re: Loading an automatic module from an exploded directory
On 10/04/2020 17:48, Eirik Bjørsnøs wrote: I once had the pleasure of debugging a system which after running in production for a few days would suddenly start returning 404 errors. Turned out someone (me) had forgotten to specify where Jetty should unpack its WAR files. So they ended up on shared temp space where a weekly Centos cron job cleaned them up. After this experience I pledged to never unpack code to temp again :-) Also, the performance implications seems not very appealing. If MultiModuleJARs [1] is re-visited then it would need to explore this topic a bit more. For now, the only case where the JDK implementation unpacks is when ModuleFinder.of is created with a file path to JAR file in a custom file system or to a directory in a custom file system that contains JAR files. These JAR files might be signed so this is why JarFile (with the JAR verifier support) is used. It would be possible to do the verification without support for the JarFile infrastructure, it just wasn't a priority in JDK 9. -Alan [1] https://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs
Re: RFR (T): 8242846: removed an empty file test/jdk/tools/jlink/plugins/OrderResourcesPluginTest.java
Sundar - do you recognize this? I assume truncating this test to 0 bytes was a mistake but I can't tell if the test should be brought back or not (to ensure that`jlink --order-resources` is tested). -Alan On 17/04/2020 11:34, Ao Qi wrote: 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
Re[2]: Classloading with multiple parent layers JDK11 vs JDK14
Hi Alan, Thank you for your answer. Yes, moduleB is an automatic module and there is also no problem when I use JDK12. So it seems to be that bug. I will report if I see problem with JDK12+. Best regards >Суббота, 18 апреля 2020, 10:06 +03:00 от Alan Bateman >: > >On 17/04/2020 21:11, Alex Sviridov wrote: >> 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. >> Is moduleB an automatic module? If so then you are probably running into >JDK-8211825 [1]. > >-Alan. > >[1] https://bugs.openjdk.java.net/browse/JDK-8211825 -- Alex Sviridov
Re: Classloading with multiple parent layers JDK11 vs JDK14
On 17/04/2020 21:11, Alex Sviridov wrote: 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. Is moduleB an automatic module? If so then you are probably running into JDK-8211825 [1]. -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8211825
