From alex.buckley at oracle.com Mon May 6 19:06:22 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 06 May 2019 12:06:22 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CB0E11D.8070801@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> Message-ID: <5CD085AE.4050008@oracle.com> On 4/12/2019 12:03 PM, Alex Buckley wrote: > On 4/12/2019 5:34 AM, Jan Lahoda wrote: >> I've started with the CSR here: >> https://bugs.openjdk.java.net/browse/JDK-8222396 > > Looks pretty good. I made some edits to record both of your > single-module and multi-module invocations of javac. > > The use case of injecting test code is clear, but the exact connection > between automatic modules and test code is pretty opaque. Is the goal to > make the automatic test module read the explicit test module so that the > former module's code can access the latter module's code? Is the goal to > make the automatic module read (and therefore test) at least the same > set of modules as the explicit modules `requires`? Reviewing the CSR again, it seemed like the key scenario is multiple named modules, where for each named module: 1. We don't really care about its relationship with the other named modules; but 2. We do care about injecting it with test code, and letting that test code read other, completely arbitrary, modules (say, an assertion-building library that's been placed on the module path). I have refactored the CSR to more strongly separate the problem (patching an automatic module is possible, but readability is sub-par) from the solution (precedent for ALL-MODULE-PATH from the unnamed module scenario). JEP 261 should be updated to explain the awesome power of --patch-module at compile time, and that is progressing behind the scenes, but I don't think it needs to block JDK-8220702 -- the CSR is "good enough" documentation for now. Alex From Alan.Bateman at oracle.com Mon May 6 19:03:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 May 2019 20:03:46 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <943de46787b3c70af8582b638f1850dab4cbb0de.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> <3bf9d0cc-23b0-d4fb-7432-ea6f4998ba6a@oracle.com> <943de46787b3c70af8582b638f1850dab4cbb0de.camel@redhat.com> Message-ID: <234040a5-b8cc-3172-74f1-5d371a9cebb4@oracle.com> On 09/04/2019 10:06, Severin Gehwolf wrote: > : >> Hi Severin, >> >> This is my initial set of comments. > Thanks for the review! Latest webrev with the updates: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/09/webrev/ > > I went through 09/webrev and just have a few comments, mostly on StripNativeDebugSymbolsPlugin. stripBinary uses ProcessBuilder to launch objdump but it doesn't redirect or read from the process streams. This could make diagnosing problems difficult so I think it should minimally use redirectOutput(INHERIT) and redirectError(INHERIT) so that any output/errors can be seen by the jlink user. At L180 there is a question to the reader on whether arg can be null. It could be good to answer that if possible and avoid needing to think about that. At L357 there mix of old and new - I assume you can be replaced with inFile.toAbsolutePath().toString(); Can you explain the mocking in DefaultStripDebugPluginTest? I think I've missed the reason for this test. In passing, we try to avoid the @author tag as it's so difficult to remove them (even if a test is completely re-worked). -Alan From sgehwolf at redhat.com Wed May 8 14:37:18 2019 From: sgehwolf at redhat.com (sgehwolf at redhat.com) Date: Wed, 08 May 2019 16:37:18 +0200 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <234040a5-b8cc-3172-74f1-5d371a9cebb4@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> <3bf9d0cc-23b0-d4fb-7432-ea6f4998ba6a@oracle.com> <943de46787b3c70af8582b638f1850dab4cbb0de.camel@redhat.com> <234040a5-b8cc-3172-74f1-5d371a9cebb4@oracle.com> Message-ID: <813cdff4ea699c8186da370d7e11379039d462cd.camel@redhat.com> Hi Alan, Thank you very much for the review! New webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/10/webrev/ Answers to your comments below. On Mon, 2019-05-06 at 20:03 +0100, Alan Bateman wrote: > On 09/04/2019 10:06, Severin Gehwolf wrote: > > : > > > Hi Severin, > > > > > > This is my initial set of comments. > > Thanks for the review! Latest webrev with the updates: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/09/webrev/ > > > > > I went through 09/webrev and just have a few comments, mostly on > StripNativeDebugSymbolsPlugin. > > stripBinary uses ProcessBuilder to launch objdump but it doesn't > redirect or read from the process streams. This could make diagnosing > problems difficult so I think it should minimally use > redirectOutput(INHERIT) and redirectError(INHERIT) so that any > output/errors can be seen by the jlink user. OK. Done. > At L180 there is a question to the reader on whether arg can be null. It > could be good to answer that if possible and avoid needing to think > about that. Answered. It must never be null currently. Once it is, it's a bug. Hence, IllegalStateException being thrown. > At L357 there mix of old and new - I assume you can be replaced with > inFile.toAbsolutePath().toString(); OK. Fixed. > Can you explain the mocking in DefaultStripDebugPluginTest? I think I've > missed the reason for this test. So StripNativeDebugSymbolsPlugin is the first platform specific plugin. Currently Linux only. DefaultStripDebugPlugin (-G or --strip-debug), on the other hand, is available everywhere. On Linux, --strip-debug does native *and* java debug attributes stripping. On other platforms it only strips java debug attributes. The test verifies both cases irrespective of the plaform it runs on. I've opted for mocking here since running the real plugins isn't needed for these simple tests: "two plugins run on platform X", "one plugin runs on platform Y". Does that answer your question? FWIW, since DefaultStripDebugPlugin is being run via IntegrationTest running the real plugins is covered too. > In passing, we try to avoid the @author tag as it's so difficult to > remove them (even if a test is completely re-worked). Sure. I've removed all @author tags I could find. Thanks, Severin From Alan.Bateman at oracle.com Sun May 12 08:35:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 May 2019 09:35:46 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <813cdff4ea699c8186da370d7e11379039d462cd.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> <3bf9d0cc-23b0-d4fb-7432-ea6f4998ba6a@oracle.com> <943de46787b3c70af8582b638f1850dab4cbb0de.camel@redhat.com> <234040a5-b8cc-3172-74f1-5d371a9cebb4@oracle.com> <813cdff4ea699c8186da370d7e11379039d462cd.camel@redhat.com> Message-ID: <7c850546-1727-09bc-0d1c-e13e3c697e31@oracle.com> On 08/05/2019 15:37, sgehwolf at redhat.com wrote: > : >> stripBinary uses ProcessBuilder to launch objdump but it doesn't >> redirect or read from the process streams. This could make diagnosing >> problems difficult so I think it should minimally use >> redirectOutput(INHERIT) and redirectError(INHERIT) so that any >> output/errors can be seen by the jlink user. > OK. Done. Good, that should help in the event that objdump produces an error. > >> At L180 there is a question to the reader on whether arg can be null. It >> could be good to answer that if possible and avoid needing to think >> about that. > Answered. It must never be null currently. Once it is, it's a bug. > Hence, IllegalStateException being thrown. It might be better to throw InternalError as ISE suggests there is a state where it could succeed. > : > FWIW, since DefaultStripDebugPlugin is being run via IntegrationTest > running the real plugins is covered too. > Thanks for the explanation. I looked through 10/webrev and I think this patch is ready to go. -Alan From sgehwolf at redhat.com Mon May 13 08:06:17 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 13 May 2019 10:06:17 +0200 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <7c850546-1727-09bc-0d1c-e13e3c697e31@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> <3bf9d0cc-23b0-d4fb-7432-ea6f4998ba6a@oracle.com> <943de46787b3c70af8582b638f1850dab4cbb0de.camel@redhat.com> <234040a5-b8cc-3172-74f1-5d371a9cebb4@oracle.com> <813cdff4ea699c8186da370d7e11379039d462cd.camel@redhat.com> <7c850546-1727-09bc-0d1c-e13e3c697e31@oracle.com> Message-ID: On Sun, 2019-05-12 at 09:35 +0100, Alan Bateman wrote: > On 08/05/2019 15:37, sgehwolf at redhat.com wrote: > > : > > > stripBinary uses ProcessBuilder to launch objdump but it doesn't > > > redirect or read from the process streams. This could make diagnosing > > > problems difficult so I think it should minimally use > > > redirectOutput(INHERIT) and redirectError(INHERIT) so that any > > > output/errors can be seen by the jlink user. > > OK. Done. > Good, that should help in the event that objdump produces an error. > > > > > At L180 there is a question to the reader on whether arg can be null. It > > > could be good to answer that if possible and avoid needing to think > > > about that. > > Answered. It must never be null currently. Once it is, it's a bug. > > Hence, IllegalStateException being thrown. > It might be better to throw InternalError as ISE suggests there is a > state where it could succeed. > OK. I'll update this to throw InternalError before I push and jdk/submit comes back clean. > > : > > FWIW, since DefaultStripDebugPlugin is being run via IntegrationTest > > running the real plugins is covered too. > > > Thanks for the explanation. I looked through 10/webrev and I think this > patch is ready to go. Excellent, thank you! Cheers, Severin From jan.lahoda at oracle.com Mon May 13 13:02:18 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 13 May 2019 15:02:18 +0200 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CD085AE.4050008@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> <5CD085AE.4050008@oracle.com> Message-ID: Thanks Alex! Could I please get a review on the CSR? https://bugs.openjdk.java.net/browse/JDK-8222396 And also on the patch: http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ Thanks! Jan On 06. 05. 19 21:06, Alex Buckley wrote: > On 4/12/2019 12:03 PM, Alex Buckley wrote: >> On 4/12/2019 5:34 AM, Jan Lahoda wrote: >>> I've started with the CSR here: >>> https://bugs.openjdk.java.net/browse/JDK-8222396 >> >> Looks pretty good. I made some edits to record both of your >> single-module and multi-module invocations of javac. >> >> The use case of injecting test code is clear, but the exact connection >> between automatic modules and test code is pretty opaque. Is the goal to >> make the automatic test module read the explicit test module so that the >> former module's code can access the latter module's code? Is the goal to >> make the automatic module read (and therefore test) at least the same >> set of modules as the explicit modules `requires`? > > Reviewing the CSR again, it seemed like the key scenario is multiple > named modules, where for each named module: > > 1. We don't really care about its relationship with the other named > modules; but > > 2. We do care about injecting it with test code, and letting that test > code read other, completely arbitrary, modules (say, an > assertion-building library that's been placed on the module path). > > I have refactored the CSR to more strongly separate the problem > (patching an automatic module is possible, but readability is sub-par) > from the solution (precedent for ALL-MODULE-PATH from the unnamed module > scenario). > > JEP 261 should be updated to explain the awesome power of --patch-module > at compile time, and that is progressing behind the scenes, but I don't > think it needs to block JDK-8220702 -- the CSR is "good enough" > documentation for now. > > Alex From alex.buckley at oracle.com Mon May 13 16:02:45 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 13 May 2019 09:02:45 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> <5CD085AE.4050008@oracle.com> Message-ID: <5CD99525.10501@oracle.com> On 5/13/2019 6:02 AM, Jan Lahoda wrote: > Could I please get a review on the CSR? > > https://bugs.openjdk.java.net/browse/JDK-8222396 Added myself as a reviewer. Alex > And also on the patch: > http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ > > Thanks! > > Jan > > On 06. 05. 19 21:06, Alex Buckley wrote: >> On 4/12/2019 12:03 PM, Alex Buckley wrote: >>> On 4/12/2019 5:34 AM, Jan Lahoda wrote: >>>> I've started with the CSR here: >>>> https://bugs.openjdk.java.net/browse/JDK-8222396 >>> >>> Looks pretty good. I made some edits to record both of your >>> single-module and multi-module invocations of javac. >>> >>> The use case of injecting test code is clear, but the exact connection >>> between automatic modules and test code is pretty opaque. Is the goal to >>> make the automatic test module read the explicit test module so that the >>> former module's code can access the latter module's code? Is the goal to >>> make the automatic module read (and therefore test) at least the same >>> set of modules as the explicit modules `requires`? >> >> Reviewing the CSR again, it seemed like the key scenario is multiple >> named modules, where for each named module: >> >> 1. We don't really care about its relationship with the other named >> modules; but >> >> 2. We do care about injecting it with test code, and letting that test >> code read other, completely arbitrary, modules (say, an >> assertion-building library that's been placed on the module path). >> >> I have refactored the CSR to more strongly separate the problem >> (patching an automatic module is possible, but readability is sub-par) >> from the solution (precedent for ALL-MODULE-PATH from the unnamed >> module scenario). >> >> JEP 261 should be updated to explain the awesome power of >> --patch-module at compile time, and that is progressing behind the >> scenes, but I don't think it needs to block JDK-8220702 -- the CSR is >> "good enough" documentation for now. >> >> Alex From sormuras at gmail.com Thu May 16 04:02:12 2019 From: sormuras at gmail.com (Christian Stein) Date: Thu, 16 May 2019 06:02:12 +0200 Subject: Nashorn on the module-path Message-ID: Hi everybody, although I'm aware of Nashorn being deprecated for removal and that the JUnit team also tends to remove the experimental support for script-based test execution [2] in the near future, I'd like to learn the reason for why a global script binding behaves differently when running on the module-path or on the class-path. I guess(!), it boils down to swallowed illegal access exception that happens when a simple Java object is put into a Binding. Running on the class-path, an instance of SimpleDynamicMethod from package "jdk.dynalink.beans" is wrap around a method of the bound object. When running on the module-path, the type within the Nashorn is reported as: "undefined". I compiled a small example project [1] that describes and demonstrates the issue. Please view the README.md file for details. You may reproduce the issue by launching `jshell build.jsh` on any platform having JDK 11+ installed within the root directory of the project. Thanks in advance for any hint and clue. Cheers, Christian [1] https://github.com/sormuras/junit5-class-vs-module-path [2] https://junit.org/junit5/docs/current/user-guide/#writing-tests-conditional-execution-scripts From Alan.Bateman at oracle.com Thu May 16 13:21:59 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2019 14:21:59 +0100 Subject: Nashorn on the module-path In-Reply-To: References: Message-ID: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> On 16/05/2019 05:02, Christian Stein wrote: > : > > I guess(!), it boils down to swallowed illegal access exception > that happens when a simple Java object is put into a Binding. > Running on the class-path, an instance of SimpleDynamicMethod > from package "jdk.dynalink.beans" is wrap around a method > of the bound object. When running on the module-path, the > type within the Nashorn is reported as: "undefined". > Can you run with -Dsun.reflect.debugModuleAccessChecks and see if anything is printed? This can be useful to locate exception swallowing. Given that Nashorn is using method handles it might not help but would be useful to try. -Alan From sormuras at gmail.com Thu May 16 14:02:42 2019 From: sormuras at gmail.com (Christian Stein) Date: Thu, 16 May 2019 16:02:42 +0200 Subject: Nashorn on the module-path In-Reply-To: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: On Thu, May 16, 2019 at 3:23 PM Alan Bateman wrote: > Can you run with -Dsun.reflect.debugModuleAccessChecks and see if > anything is printed? This can be useful to locate exception swallowing. > Given that Nashorn is using method handles it might not help but would > be useful to try. > It didn't emit any new line. Is there another debug switch I can enable? From jonathan.gibbons at oracle.com Thu May 23 21:31:09 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 23 May 2019 14:31:09 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> <5CD085AE.4050008@oracle.com> Message-ID: CSR and patch look good to me. -- Jon On 05/13/2019 06:02 AM, Jan Lahoda wrote: > Thanks Alex! > > Could I please get a review on the CSR? > > https://bugs.openjdk.java.net/browse/JDK-8222396 > > And also on the patch: > http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ > > Thanks! > > Jan > > On 06. 05. 19 21:06, Alex Buckley wrote: >> On 4/12/2019 12:03 PM, Alex Buckley wrote: >>> On 4/12/2019 5:34 AM, Jan Lahoda wrote: >>>> I've started with the CSR here: >>>> https://bugs.openjdk.java.net/browse/JDK-8222396 >>> >>> Looks pretty good. I made some edits to record both of your >>> single-module and multi-module invocations of javac. >>> >>> The use case of injecting test code is clear, but the exact connection >>> between automatic modules and test code is pretty opaque. Is the >>> goal to >>> make the automatic test module read the explicit test module so that >>> the >>> former module's code can access the latter module's code? Is the >>> goal to >>> make the automatic module read (and therefore test) at least the same >>> set of modules as the explicit modules `requires`? >> >> Reviewing the CSR again, it seemed like the key scenario is multiple >> named modules, where for each named module: >> >> 1. We don't really care about its relationship with the other named >> modules; but >> >> 2. We do care about injecting it with test code, and letting that >> test code read other, completely arbitrary, modules (say, an >> assertion-building library that's been placed on the module path). >> >> I have refactored the CSR to more strongly separate the problem >> (patching an automatic module is possible, but readability is >> sub-par) from the solution (precedent for ALL-MODULE-PATH from the >> unnamed module scenario). >> >> JEP 261 should be updated to explain the awesome power of >> --patch-module at compile time, and that is progressing behind the >> scenes, but I don't think it needs to block JDK-8220702 -- the CSR is >> "good enough" documentation for now. >> >> Alex From sormuras at gmail.com Sun May 26 05:45:00 2019 From: sormuras at gmail.com (Christian Stein) Date: Sun, 26 May 2019 07:45:00 +0200 Subject: =?UTF-8?Q?Why_doesn=E2=80=99t_jdk=2Einternal=2Eloader=2ELoader_implement_A?= =?UTF-8?Q?utoCloseable=3F?= Message-ID: Hi, following the documentation of ModulLayer [1] to create a temporary layer for testing, results in a FileSystemException when trying to delete the modular jar file after tests are finished. On Windows, at least. Find more details and a minimal working example here: [2] An implementation of a `Loader.close()` method similar to the one found URLClassLoader [3] would solve the problem. Shall I open an issue over at https://bugs.openjdk.java.net? Cheers, Christian [1] https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/ModuleLayer.html [2] https://sormuras.github.io/blog/2019-05-26-jdk-module-layer-class-loader [3] https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/net/URLClassLoader.html#close() From Alan.Bateman at oracle.com Sun May 26 08:31:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 May 2019 09:31:55 +0100 Subject: =?UTF-8?Q?Re=3a_Why_doesn=e2=80=99t_jdk=2einternal=2eloader=2eLoade?= =?UTF-8?Q?r_implement_AutoCloseable=3f?= In-Reply-To: References: Message-ID: On 26/05/2019 06:45, Christian Stein wrote: > Hi, > > following the documentation of ModulLayer [1] to create a > temporary layer for testing, results in a FileSystemException > when trying to delete the modular jar file after tests are finished. Can you create a WeakReference to the module layer and do the cleanup when the reference is queued? When a module layer is GC'ed then you should find the JAR files containing modules will be closed and you can delete them. As this is testing then maybe the test finish can null out the reference to the module layer (and the class loaders if you have references to those), call System.gc, and wait for the weak reference to be cleaned. That said, it might be time to change the Windows sharing mode that JarFile/ZipFile uses to open JAR files. I'll create an issue for that. -Alan From Alan.Bateman at oracle.com Sun May 26 08:33:38 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 May 2019 09:33:38 +0100 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: On 16/05/2019 15:02, Christian Stein wrote: > : > > ?It didn't emit any new line. Is there another debug switch I can enable? Have you brought this up on nashorn-dev as this might require digging into the dynalink linker and how method handles are used. -Alan From sormuras at gmail.com Sun May 26 09:09:17 2019 From: sormuras at gmail.com (Christian Stein) Date: Sun, 26 May 2019 11:09:17 +0200 Subject: =?UTF-8?Q?Re=3A_Why_doesn=E2=80=99t_jdk=2Einternal=2Eloader=2ELoader_impleme?= =?UTF-8?Q?nt_AutoCloseable=3F?= In-Reply-To: References: Message-ID: On Sun, May 26, 2019 at 10:31 AM Alan Bateman wrote: > On 26/05/2019 06:45, Christian Stein wrote: > > Hi, > > > > following the documentation of ModulLayer [1] to create a > > temporary layer for testing, results in a FileSystemException > > when trying to delete the modular jar file after tests are finished. > Can you create a WeakReference to the module layer and do the cleanup > when the reference is queued? When a module layer is GC'ed then you > should find the JAR files containing modules will be closed and you can > delete them. As this is testing then maybe the test finish can null out > the reference to the module layer (and the class loaders if you have > references to those), call System.gc, and wait for the weak reference to > be cleaned. > Only tried to null out the loader, yet. So I added the layer and the reference to a class loaded by the layers' loader to the "to be nulled out ensemble" [1]: layer = null; loader = null; mainClass = null; System.gc(); Thread.sleep(2000); ...et voil?, the jar file is unlocked a can be deleted. Many thanks for the hint. > That said, it might be time to change the Windows sharing mode that > JarFile/ZipFile uses to open JAR files. I'll create an issue for that. > Sounds great! Still early enough for JDK 13? ;-) [1] https://github.com/sormuras/sormuras.github.io/blob/master/demo/test/jdk/JarLock.java#L69 From sormuras at gmail.com Sun May 26 09:17:32 2019 From: sormuras at gmail.com (Christian Stein) Date: Sun, 26 May 2019 11:17:32 +0200 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: > Have you brought this up on nashorn-dev... No, but cc-ed that list now. > ...as this might require digging into the dynalink linker > and how method handles are used. Do you think it's still worth the effort in regard of Nashorn being deprecated for removal? Perhaps the underlying reason may show up on/in a different module, soon. Said that, the JUnit 5 team decided to remove "script- based conditions" from Jupiter. So, "we" won't be affected by this issue in the near future anymore. [1] https://github.com/junit-team/junit5/issues/1882 On Sun, May 26, 2019 at 10:35 AM Alan Bateman wrote: > On 16/05/2019 15:02, Christian Stein wrote: > > : > > It didn't emit any new line. Is there another debug switch I can enable? > > Have you brought this up on nashorn-dev as this might require digging into > the dynalink linker and how method handles are used. > > -Alan > From james.laskey at oracle.com Sun May 26 10:02:00 2019 From: james.laskey at oracle.com (James Laskey) Date: Sun, 26 May 2019 07:02:00 -0300 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: <75B5DE9B-BB22-48E7-BC37-458C3FBAD1C1@oracle.com> Christian, I can?t see the rest of the thread so I don?t have a context. Sent from my iPhone On May 26, 2019, at 6:17 AM, Christian Stein wrote: >> Have you brought this up on nashorn-dev... > > No, but cc-ed that list now. > >> ...as this might require digging into the dynalink linker >> and how method handles are used. > > Do you think it's still worth the effort in regard of Nashorn > being deprecated for removal? Perhaps the underlying > reason may show up on/in a different module, soon. > > Said that, the JUnit 5 team decided to remove "script- > based conditions" from Jupiter. So, "we" won't be affected > by this issue in the near future anymore. > > [1] https://github.com/junit-team/junit5/issues/1882 > > > > On Sun, May 26, 2019 at 10:35 AM Alan Bateman > wrote: > >> On 16/05/2019 15:02, Christian Stein wrote: >> >> : >> >> It didn't emit any new line. Is there another debug switch I can enable? >> >> Have you brought this up on nashorn-dev as this might require digging into >> the dynalink linker and how method handles are used. >> >> -Alan >> From sundararajan.athijegannathan at oracle.com Mon May 27 09:18:11 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 27 May 2019 14:48:11 +0530 Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path Message-ID: <5CEBAB53.9020307@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8216553 Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/ Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Mon May 27 09:42:01 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 27 May 2019 15:12:01 +0530 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: <5CEBB0E9.1040903@oracle.com> How can this be reproduced at out end? Thanks -Sundar On 26/05/19, 2:47 PM, Christian Stein wrote: >> Have you brought this up on nashorn-dev... > No, but cc-ed that list now. > >> ...as this might require digging into the dynalink linker >> and how method handles are used. > Do you think it's still worth the effort in regard of Nashorn > being deprecated for removal? Perhaps the underlying > reason may show up on/in a different module, soon. > > Said that, the JUnit 5 team decided to remove "script- > based conditions" from Jupiter. So, "we" won't be affected > by this issue in the near future anymore. > > [1] https://github.com/junit-team/junit5/issues/1882 > > > > On Sun, May 26, 2019 at 10:35 AM Alan Bateman > wrote: > >> On 16/05/2019 15:02, Christian Stein wrote: >> >> : >> >> It didn't emit any new line. Is there another debug switch I can enable? >> >> Have you brought this up on nashorn-dev as this might require digging into >> the dynalink linker and how method handles are used. >> >> -Alan >> From sormuras at gmail.com Mon May 27 09:40:33 2019 From: sormuras at gmail.com (Christian Stein) Date: Mon, 27 May 2019 11:40:33 +0200 Subject: Nashorn on the module-path In-Reply-To: <5CEBB0E9.1040903@oracle.com> References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > How can this be reproduced at out end? I compiled a small example project at [1] that describes and demonstrates the issue. Please view the README.md file for details. You may reproduce the issue by launching `jshell build.jsh` within the root directory of the project -- having JDK 11+ installed. [1] https://github.com/sormuras/junit5-class-vs-module-path From sundararajan.athijegannathan at oracle.com Mon May 27 09:47:48 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 27 May 2019 15:17:48 +0530 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: <5CEBB244.1050909@oracle.com> Thanks. I'll check it out. -Sundar On 27/05/19, 3:10 PM, Christian Stein wrote: > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan > > wrote: > > How can this be reproduced at out end? > > > I compiled a small example project at [1] that describes and > demonstrates the issue. Please view the README.md file for > details. > > You may reproduce the issue by launching `jshell build.jsh` > within the root directory of the project -- having JDK 11+ installed. > > [1] https://github.com/sormuras/junit5-class-vs-module-path From james.laskey at oracle.com Mon May 27 11:58:50 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 27 May 2019 08:58:50 -0300 Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path In-Reply-To: <5CEBAB53.9020307@oracle.com> References: <5CEBAB53.9020307@oracle.com> Message-ID: <95D3E742-AE89-4C6F-9AE3-97128ECC4F3E@oracle.com> +1 > On May 27, 2019, at 6:18 AM, Sundararajan Athijegannathan wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216553 > Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/ > > Thanks, > -Sundar > > From Alan.Bateman at oracle.com Mon May 27 12:07:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 May 2019 13:07:23 +0100 Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path In-Reply-To: <5CEBAB53.9020307@oracle.com> References: <5CEBAB53.9020307@oracle.com> Message-ID: <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com> On 27/05/2019 10:18, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216553 > Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/ This addresses the points we discussed in the JIRA issue so I think it looks good. -Alan From hannes.wallnoefer at oracle.com Mon May 27 13:28:21 2019 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 27 May 2019 15:28:21 +0200 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: Hi Christian, I cloned and tried your example project. When I run the project, I get one successful and one aborted tests in both cases: Module path output: ?? JUnit Jupiter ? ?? CheckTests ? ?? test() ? ?? emitStringRepresentationOfTestModule() ? Assumption failed: module check Class path output: ?? JUnit Jupiter ? ?? CheckTests ? ?? test() ? ?? emitStringRepresentationOfTestModule() ? Assumption failed: unnamed module @306f16f3 Unfortunately it?s quite hard for me to understand what?s going on from there. Your Main class is quite complex with over 800 lines of code, and it seems like the interesting code is in junit-jupiter, which is included in binary form only. Do you think it?s possible to reduce the problem further, ideally to a plain java class? Hannes > Am 27.05.2019 um 11:40 schrieb Christian Stein : > > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> How can this be reproduced at out end? > > > I compiled a small example project at [1] that describes and > demonstrates the issue. Please view the README.md file for > details. > > You may reproduce the issue by launching `jshell build.jsh` > within the root directory of the project -- having JDK 11+ installed. > > [1] https://github.com/sormuras/junit5-class-vs-module-path From sormuras at gmail.com Mon May 27 14:35:21 2019 From: sormuras at gmail.com (Christian Stein) Date: Mon, 27 May 2019 16:35:21 +0200 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: Hi Hannes, what you see is the expected output. Those assumptions are meant to fail ... perhaps a not so intuitive form of printing the test module name to console. The interesting lines are printed prior to the test run tree: Running the tests on the `--module-path` yields: >> org.junit.jupiter.engine.script.ScriptAccessor$SystemPropertyAccessor at 4716be8b undefined << Compare to what is printed when running on the `--class-path`: >> org.junit.jupiter.engine.script.ScriptAccessor$SystemPropertyAccessor at 275bf9b3 [jdk.dynalink.beans.SimpleDynamicMethod String org.junit.jupiter.engine.script.ScriptAccessor.SystemPropertyAccessor.get(String)] << The "undefined" type is what makes/breaks the script. That said, I'll try to destill it down two or three files... later this week. Cheers, Christian On Mon, May 27, 2019 at 3:30 PM Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > Hi Christian, > > I cloned and tried your example project. When I run the project, I get one > successful and one aborted tests in both cases: > > Module path output: > > ?? JUnit Jupiter ? > ?? CheckTests ? > ?? test() ? > ?? emitStringRepresentationOfTestModule() ? Assumption failed: > module check > > Class path output: > > ?? JUnit Jupiter ? > ?? CheckTests ? > ?? test() ? > ?? emitStringRepresentationOfTestModule() ? Assumption failed: > unnamed module @306f16f3 > > > Unfortunately it?s quite hard for me to understand what?s going on from > there. Your Main class is quite complex with over 800 lines of code, and it > seems like the interesting code is in junit-jupiter, which is included in > binary form only. > > Do you think it?s possible to reduce the problem further, ideally to a > plain java class? > > > Hannes > > > > Am 27.05.2019 um 11:40 schrieb Christian Stein : > > > > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com> wrote: > > > >> How can this be reproduced at out end? > > > > > > I compiled a small example project at [1] that describes and > > demonstrates the issue. Please view the README.md file for > > details. > > > > You may reproduce the issue by launching `jshell build.jsh` > > within the root directory of the project -- having JDK 11+ installed. > > > > [1] https://github.com/sormuras/junit5-class-vs-module-path > > From sundararajan.athijegannathan at oracle.com Tue May 28 09:48:33 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 28 May 2019 15:18:33 +0530 Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path In-Reply-To: <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com> References: <5CEBAB53.9020307@oracle.com> <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com> Message-ID: <5CED03F1.7020908@oracle.com> Updated for java test failures: https://cr.openjdk.java.net/~sundar/8216553/webrev.01/ PS. Test framework used wrong jrt: URI pattern. Fixed it. -Sundar On 27/05/19, 5:37 PM, Alan Bateman wrote: > On 27/05/2019 10:18, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216553 >> Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/ > This addresses the points we discussed in the JIRA issue so I think it > looks good. > > -Alan From james.laskey at oracle.com Tue May 28 11:30:12 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 28 May 2019 08:30:12 -0300 Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path In-Reply-To: <5CED03F1.7020908@oracle.com> References: <5CEBAB53.9020307@oracle.com> <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com> <5CED03F1.7020908@oracle.com> Message-ID: +1 > On May 28, 2019, at 6:48 AM, Sundararajan Athijegannathan wrote: > > Updated for java test failures: > > https://cr.openjdk.java.net/~sundar/8216553/webrev.01/ > > PS. Test framework used wrong jrt: URI pattern. Fixed it. > > -Sundar > > On 27/05/19, 5:37 PM, Alan Bateman wrote: >> On 27/05/2019 10:18, Sundararajan Athijegannathan wrote: >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216553 >>> Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/ >> This addresses the points we discussed in the JIRA issue so I think it looks good. >> >> -Alan From sundararajan.athijegannathan at oracle.com Thu May 30 10:55:35 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 30 May 2019 16:25:35 +0530 Subject: RFR 8224946: jrtfs URI to Path and Path to URI conversions are wrong Message-ID: <5CEFB6A7.60008@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8224946 Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/ Earlier attempt for the fix of the same bug resulted in test failures and so the fix was reverted. The current webrev has the same fix - but fixes 2 jlink tests that used wrong jrt: URI. With this change, internal mach5 test run is fine. Related email threads of earlier fix attempt & reversal: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060434.html https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060459.html Thanks, -Sundar From Alan.Bateman at oracle.com Thu May 30 10:51:31 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 May 2019 11:51:31 +0100 Subject: RFR 8224946: jrtfs URI to Path and Path to URI conversions are wrong In-Reply-To: <5CEFB6A7.60008@oracle.com> References: <5CEFB6A7.60008@oracle.com> Message-ID: <6a59c895-ac3d-91fa-2092-ceb2d33409df@oracle.com> On 30/05/2019 11:55, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224946 > Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/ > > Earlier attempt for the fix of the same bug resulted in test failures > and so the fix was reverted. The current webrev has the same fix - but > fixes 2 jlink tests that used wrong jrt: URI. With this change, > internal mach5 test run is fine. The update to the two jlink tests missed in the original push looks fine. -Alan From sundararajan.athijegannathan at oracle.com Thu May 30 17:12:28 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 30 May 2019 22:42:28 +0530 Subject: RFR 8216535: tools/jimage/JImageExtractTest.java timed out Message-ID: <5CF00EFC.1070200@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8216535 Webrev: https://cr.openjdk.java.net/~sundar/8216535/webrev.00/ I'm creating a small jre image with just java.base and jdk.zipfs modules it. The lib/modules of that small jre is extracted for the test purpose. This reduces time taken - elapsed time in jtreg log is 26656 vs 83445 (earlier). I hope this should solve timeout issues seen in the test runs. Thanks, -Sundar From james.laskey at oracle.com Thu May 30 17:30:25 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 30 May 2019 14:30:25 -0300 Subject: RFR 8216535: tools/jimage/JImageExtractTest.java timed out In-Reply-To: <5CF00EFC.1070200@oracle.com> References: <5CF00EFC.1070200@oracle.com> Message-ID: +1 > On May 30, 2019, at 2:12 PM, Sundararajan Athijegannathan wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216535 > Webrev: https://cr.openjdk.java.net/~sundar/8216535/webrev.00/ > > I'm creating a small jre image with just java.base and jdk.zipfs modules it. The lib/modules of that small jre is extracted for the test purpose. This reduces time taken - elapsed time in jtreg log is 26656 vs 83445 (earlier). I hope this should solve timeout issues seen in the test runs. > > Thanks, > -Sundar From mandy.chung at oracle.com Fri May 31 02:43:40 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 30 May 2019 19:43:40 -0700 Subject: RFR 8216535: tools/jimage/JImageExtractTest.java timed out In-Reply-To: <5CF00EFC.1070200@oracle.com> References: <5CF00EFC.1070200@oracle.com> Message-ID: Hi Sundar, On 5/30/19 10:12 AM, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216535 > Webrev: https://cr.openjdk.java.net/~sundar/8216535/webrev.00/ > Looks okay. It seems cleaner to have a new JImageCliTest constructor that takes the path to ${java.home} for jimage tests and this JImageExtractTest to call this superclass constructor. > I'm creating a small jre image with just java.base and jdk.zipfs > modules it. The lib/modules of that small jre is extracted for the > test purpose. This reduces time taken -? elapsed time in jtreg log is > 26656 vs 83445 (earlier). I hope this should solve timeout issues seen > in the test runs. > It might be useful to instrument and print the jimage execution time to prepare for the future diagnosis. Mandy From sundararajan.athijegannathan at oracle.com Fri May 31 03:00:48 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 31 May 2019 08:30:48 +0530 Subject: RFR 8216535: tools/jimage/JImageExtractTest.java timed out In-Reply-To: References: <5CF00EFC.1070200@oracle.com> Message-ID: <5CF098E0.1080000@oracle.com> Hi Mandy, Sorry I pushed the change. I'll take care of these suggestions in future change in this area. Thanks, -Sundar On 31/05/19, 8:13 AM, Mandy Chung wrote: > Hi Sundar, > > On 5/30/19 10:12 AM, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216535 >> Webrev: https://cr.openjdk.java.net/~sundar/8216535/webrev.00/ >> > > Looks okay. > > It seems cleaner to have a new JImageCliTest constructor that takes > the path to ${java.home} for jimage tests and this JImageExtractTest > to call this superclass constructor. > >> I'm creating a small jre image with just java.base and jdk.zipfs >> modules it. The lib/modules of that small jre is extracted for the >> test purpose. This reduces time taken - elapsed time in jtreg log is >> 26656 vs 83445 (earlier). I hope this should solve timeout issues >> seen in the test runs. >> > > It might be useful to instrument and print the jimage execution time > to prepare for the future diagnosis. > > Mandy