From sormuras at gmail.com Tue Jul 2 08:47:41 2019 From: sormuras at gmail.com (Christian Stein) Date: Tue, 2 Jul 2019 10:47:41 +0200 Subject: Add "source of module name" to ModuleDescriptor API Message-ID: Hi, at the moment, class `java.lang.module.ModuleDescriptor` only provides an `isAutomatic()` getter -- which doesn't allow to determine from where the module name actually came from. Program `PresentModule.java` [1] creates a `JarFile` instance to determine the source of an automatic module. As the module name is resolved by the runtime from a specific source, it could be stored as a constant in the `ModuleDescriptor` instance at resolution time. I propose to extend the `ModuleDescriptor` class with a public enum NameSource { FILENAME, MANIFEST, DESCRIPTOR } and an accessor: public NameSource nameSource { return ... } Cheers, Christian [1] https://github.com/sormuras/modules/blob/master/src/PresentModule.java From Alan.Bateman at oracle.com Tue Jul 2 11:14:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jul 2019 12:14:09 +0100 Subject: Add "source of module name" to ModuleDescriptor API In-Reply-To: References: Message-ID: On 02/07/2019 09:47, Christian Stein wrote: > Hi, > > at the moment, class `java.lang.module.ModuleDescriptor` only > provides an `isAutomatic()` getter -- which doesn't allow to > determine from where the module name actually came from. > > Program `PresentModule.java` [1] creates a `JarFile` instance > to determine the source of an automatic module. > > As the module name is resolved by the runtime from a > specific source, it could be stored as a constant in the > `ModuleDescriptor` instance at resolution time. > > I propose to extend the `ModuleDescriptor` class with a > > public enum NameSource { > FILENAME, MANIFEST, DESCRIPTOR > } > > and an accessor: > > public NameSource nameSource { return ... } > ModuleDescriptor just describes a named module and doesn't care how the module name came about when creating an automatic module. Anything working with module locations should use a ModuleReference as it defines the "location" method to get a URI to the module content (if possible). So probably better if tools like this used a ModuleReference and special cased the JAR case? when they want to know if the module name was derived from the JAR file name or came from the value of the Automatic-Module-Name attribute. -Alan From Alan.Bateman at oracle.com Tue Jul 2 14:42:29 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jul 2019 15:42:29 +0100 Subject: Changes to jrt file system provider in JDK 13 Message-ID: For those using the jrt file system provider then please make sure to test with the latest JDK 13 EA builds. One of the changes in JDK 13 is to fix issues encoding paths to files in the jrt file system as jrt URLs and vice versa [1]. The compatibility impact with fixing these issues is that it might expose cases where a tool is (perhaps unknowingly) using URLs that don't conform to the syntax documented in JEP 220. We've heard of one case where something is trying to create a URI to the /packages directory but that is a special directory for sym links and cannot be represented by a jrt URI. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8224946 From sormuras at gmail.com Thu Jul 4 06:40:36 2019 From: sormuras at gmail.com (Christian Stein) Date: Thu, 4 Jul 2019 08:40:36 +0200 Subject: Add "source of module name" to ModuleDescriptor API In-Reply-To: References: Message-ID: On Tue, Jul 2, 2019 at 1:14 PM Alan Bateman wrote: > On 02/07/2019 09:47, Christian Stein wrote: > > Hi, > > > > at the moment, class `java.lang.module.ModuleDescriptor` only > > provides an `isAutomatic()` getter -- which doesn't allow to > > determine from where the module name actually came from. > > > > Program `PresentModule.java` [1] creates a `JarFile` instance > > to determine the source of an automatic module. > > > > As the module name is resolved by the runtime from a > > specific source, it could be stored as a constant in the > > `ModuleDescriptor` instance at resolution time. > > > > I propose to extend the `ModuleDescriptor` class with a > > > > public enum NameSource { > > FILENAME, MANIFEST, DESCRIPTOR > > } > > > > and an accessor: > > > > public NameSource nameSource { return ... } > > > ModuleDescriptor just describes a named module and doesn't care how the > module name came about when creating an automatic module. Anything > working with module locations should use a ModuleReference as it defines > the "location" method to get a URI to the module content (if possible). > So probably better if tools like this used a ModuleReference and special > cased the JAR case when they want to know if the module name was > derived from the JAR file name or came from the value of the > Automatic-Module-Name attribute. > > -Alan > Thank you for the clarification, Alan. Wondering why `isAutomatic()` is part of the API then. Its underlying value is also not declared by the author of the module, but rather determined at/by the runtime. From Pengfei.Li at arm.com Fri Jul 12 03:27:55 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 12 Jul 2019 03:27:55 +0000 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal Message-ID: Hi, Please help review this small fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8227512 Webrev: http://cr.openjdk.java.net/~pli/rfr/8227512/ JTReg javac tests * langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java * langtools/tools/javac/file/LimitedImage.java failed when Graal is used as JVMCI compiler. These cases test javac behavior with the condition that observable modules are limited. But Graal is unable to be found in the limited module scope. This fixes these two tests by adding "jdk.internal.vm.compiler" into the limited modules. -- Thanks, Pengfei From tom.dewolf at aca-it.be Sat Jul 13 12:43:28 2019 From: tom.dewolf at aca-it.be (Tom De Wolf) Date: Sat, 13 Jul 2019 14:43:28 +0200 Subject: More flexibility in providing services from modules? In-Reply-To: <5C7D89D6.4060907@oracle.com> References: <5C7D89D6.4060907@oracle.com> Message-ID: Hi Alex, 1 of the smaller suggestions in my blogpost ( https://devcreativity.wordpress.com/2019/03/02/java-modules-wish-list-provide-services-using-lambda-functions-and-more/) was to pass in the class of the expected service type as a parameter into the provider method if the signature is defined with a Class as single parameter. This little extension of the convention would allow already a lot more flexibility. Would it be possible to consider it? Thanks, Tom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Op ma 4 mrt. 2019 om 21:27 schreef Alex Buckley : > Hi Tom, > > Nice to see thoughts about modular services. > > FYI Jigsaw's goals in this area were quite limited > (http://openjdk.java.net/projects/jigsaw/spec/reqs/#services) and the > static provider method was a relatively late add-on > (http://openjdk.java.net/projects/jigsaw/spec/issues/#services). > > I agree that a static provider method offers a basic level of > indirection (e.g. multiple `provides` directives can employ the same one > if its return type implements multiple services) but it doesn't add much > in the way of abstraction (e.g. over the desired service). This isn't > the only place where ServiceLoader suffers from a lack of abstraction: > you can't parameterize services because there's no way to request an > implementation of a parameterized service (i.e. you can't say > `ServiceLoader.load(ServiceA.class)`). > > Frankly, we are not likely to revisit any of these limitations in the > near future, but I think that ServiceLoader will always be a handy > built-in option for limited use cases. > > Alex > > On 3/2/2019 9:19 AM, Tom De Wolf wrote: > > The current ServiceLoader mechanism and Java Modules have a limited set > of > > options to provide an instance for a service from a module. Or you use > the > > constructor, or you use a static 'provider' method. > > > > When interacting with frameworks like Spring this does not give a lot of > > flexibility. I described the problem statement and some ideas which could > > be considered for evolving the services support in the module system in > > this blog post: > > > > > https://devcreativity.wordpress.com/2019/03/02/java-modules-wish-list-provide-services-using-lambda-functions-and-more/ > > > > > > I would appreciate if some of the oracle contributors that worked on the > > module system could read the post and provide me and the community with > > some feedback if such a change could be a good idea? > > > > Thanks in advance > > > > Tom > > > From Pengfei.Li at arm.com Mon Jul 15 01:38:33 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 15 Jul 2019 01:38:33 +0000 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: CC compiler-dev -- Thanks, Pengfei > Hi, > > Please help review this small fix. > JBS: https://bugs.openjdk.java.net/browse/JDK-8227512 > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227512/ > > JTReg javac tests > * langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java > * langtools/tools/javac/file/LimitedImage.java > failed when Graal is used as JVMCI compiler. > > These cases test javac behavior with the condition that observable modules > are limited. But Graal is unable to be found in the limited module scope. This > fixes these two tests by adding "jdk.internal.vm.compiler" into the limited > modules. > > -- > Thanks, > Pengfei From maurizio.cimadamore at oracle.com Mon Jul 15 15:25:43 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Jul 2019 16:25:43 +0100 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: <808dfddf-1a5f-be51-4078-fccfac3f19f8@oracle.com> Looks good! Thanks Maurizio On 15/07/2019 02:38, Pengfei Li (Arm Technology China) wrote: > CC compiler-dev > > -- > Thanks, > Pengfei > >> Hi, >> >> Please help review this small fix. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227512 >> Webrev: http://cr.openjdk.java.net/~pli/rfr/8227512/ >> >> JTReg javac tests >> * langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java >> * langtools/tools/javac/file/LimitedImage.java >> failed when Graal is used as JVMCI compiler. >> >> These cases test javac behavior with the condition that observable modules >> are limited. But Graal is unable to be found in the limited module scope. This >> fixes these two tests by adding "jdk.internal.vm.compiler" into the limited >> modules. >> >> -- >> Thanks, >> Pengfei From andrea.vacondio at gmail.com Wed Jul 17 12:37:36 2019 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Wed, 17 Jul 2019 14:37:36 +0200 Subject: EXCEPTION_ACCESS_VIOLATION on a jlinked 11.0.3+7 32bits Message-ID: Hi, this was initially posted on AdoptJDK issue tracker here https://github.com/AdoptOpenJDK/openjdk-build/issues/1165 but after verified that it's also affecting Azul's Zulu, I was suggested to post here. On a Windows 10 32 bits I have a script that does a jlink on the 32bits jdk 11.0.3+7. When running 'java' on the resulting runtime I get a EXCEPTION_ACCESS_VIOLATION (attached to the issue in GitHub there is the error log). This doesn't happen if I run 'java' on the jdk. The same script is used in a 64bits environment and everything works fine. Please let me know if you need further information, this constantly happens, I tried running the script multiple times and I got the same result. Andrea From shade at redhat.com Wed Jul 17 14:39:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Jul 2019 16:39:53 +0200 Subject: EXCEPTION_ACCESS_VIOLATION on a jlinked 11.0.3+7 32bits In-Reply-To: References: Message-ID: On 7/17/19 2:37 PM, Andrea Vacondio wrote: > On a Windows 10 32 bits I have a script that does a jlink on the 32bits jdk > 11.0.3+7. When running 'java' on the resulting runtime I get a > EXCEPTION_ACCESS_VIOLATION (attached to the issue in GitHub there is the > error log). This doesn't happen if I run 'java' on the jdk. The same script There are quite a few bugfixes for x86_32 that went into 11.0.4, please try with recent 11u release. Running with fastdebug binaries, if you can get hold of them, would also be a plus. -- Thanks, -Aleksey From Alan.Bateman at oracle.com Thu Jul 18 06:12:50 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Jul 2019 07:12:50 +0100 Subject: EXCEPTION_ACCESS_VIOLATION on a jlinked 11.0.3+7 32bits In-Reply-To: References: Message-ID: <5ef45520-3f9e-ab0b-670b-70854df3e6b7@oracle.com> On 17/07/2019 13:37, Andrea Vacondio wrote: > Hi, > this was initially posted on AdoptJDK issue tracker here > https://github.com/AdoptOpenJDK/openjdk-build/issues/1165 but after > verified that it's also affecting Azul's Zulu, I was suggested to post here. > > On a Windows 10 32 bits I have a script that does a jlink on the 32bits jdk > 11.0.3+7. When running 'java' on the resulting runtime I get a > EXCEPTION_ACCESS_VIOLATION (attached to the issue in GitHub there is the > error log). This doesn't happen if I run 'java' on the jdk. The same script > is used in a 64bits environment and everything works fine. > Please let me know if you need further information, this constantly > happens, I tried running the script multiple times and I got the same > result. > Andrea Where is the script? I'm curious if it runs jlink with --compress=2. If so then you may be running into JDK-8215123[1] which is a calling convention issue specific to Windows 32-bit. It was fixed for JDK 12 so would be good to test with a JDK 12 or JDK 13 EA build to see if you still run into issues. -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8215123 From Alan.Bateman at oracle.com Thu Jul 18 06:27:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Jul 2019 07:27:10 +0100 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: On 12/07/2019 04:27, Pengfei Li (Arm Technology China) wrote: > Hi, > > Please help review this small fix. > JBS: https://bugs.openjdk.java.net/browse/JDK-8227512 > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227512/ > > JTReg javac tests > * langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java > * langtools/tools/javac/file/LimitedImage.java > failed when Graal is used as JVMCI compiler. > > These cases test javac behavior with the condition that observable modules are limited. But Graal is unable to be found in the limited module scope. This fixes these two tests by adding "jdk.internal.vm.compiler" into the limited modules. > I see this has been pushed but it looks like it is missing `@modules jdk.internal.vm.compiler` as the test now requires this module to be in the run-time image under test. As the test is not interesting when testing with the Graal compiler then maybe an alternative is to add `@requires !vm.graal.enabled` so that the test is not selected when exercising Graal - we've done this in a few other tests that run with `--limit-modules`. -Alan. From andrea.vacondio at gmail.com Thu Jul 18 09:19:25 2019 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Thu, 18 Jul 2019 11:19:25 +0200 Subject: EXCEPTION_ACCESS_VIOLATION on a jlinked 11.0.3+7 32bits In-Reply-To: <5ef45520-3f9e-ab0b-670b-70854df3e6b7@oracle.com> References: <5ef45520-3f9e-ab0b-670b-70854df3e6b7@oracle.com> Message-ID: These are the args we use: --add-modules java.base,java.datatransfer,java.logging,java.naming,java.sql,java.desktop,java.xml,java.scripting,jdk.unsupported,java.prefs --compress 2 --no-man-pages --no-header-files --strip-debug Tested with jdk-12.0.1+12 and got: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000377, pid=1052, tid=2008 # # JRE version: (12.0.1+12) (build ) # Java VM: OpenJDK Server VM (12.0.1+12, mixed mode, emulated-client, g1 gc, windows-x86) # Problematic frame: # C 0x00000377 I'll try to find a 11.0.4 fastdebug binaries to test it.. Il giorno gio 18 lug 2019 alle ore 08:12 Alan Bateman < Alan.Bateman at oracle.com> ha scritto: > On 17/07/2019 13:37, Andrea Vacondio wrote: > > Hi, > > this was initially posted on AdoptJDK issue tracker here > > https://github.com/AdoptOpenJDK/openjdk-build/issues/1165 but after > > verified that it's also affecting Azul's Zulu, I was suggested to post > here. > > > > On a Windows 10 32 bits I have a script that does a jlink on the 32bits > jdk > > 11.0.3+7. When running 'java' on the resulting runtime I get a > > EXCEPTION_ACCESS_VIOLATION (attached to the issue in GitHub there is the > > error log). This doesn't happen if I run 'java' on the jdk. The same > script > > is used in a 64bits environment and everything works fine. > > Please let me know if you need further information, this constantly > > happens, I tried running the script multiple times and I got the same > > result. > > Andrea > Where is the script? I'm curious if it runs jlink with --compress=2. If > so then you may be running into JDK-8215123[1] which is a calling > convention issue specific to Windows 32-bit. It was fixed for JDK 12 so > would be good to test with a JDK 12 or JDK 13 EA build to see if you > still run into issues. > > -Alan. > > [1] https://bugs.openjdk.java.net/browse/JDK-8215123 > From shade at redhat.com Thu Jul 18 09:23:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Jul 2019 11:23:08 +0200 Subject: EXCEPTION_ACCESS_VIOLATION on a jlinked 11.0.3+7 32bits In-Reply-To: References: <5ef45520-3f9e-ab0b-670b-70854df3e6b7@oracle.com> Message-ID: <146f7cbd-a8d2-ff4f-1906-32405573db14@redhat.com> On 7/18/19 11:19 AM, Andrea Vacondio wrote: > These are the args we use: > --add-modules > java.base,java.datatransfer,java.logging,java.naming,java.sql,java.desktop,java.xml,java.scripting,jdk.unsupported,java.prefs > --compress 2 --no-man-pages --no-header-files --strip-debug > > Tested with jdk-12.0.1+12 and got: > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000377, pid=1052, > tid=2008 > # > # JRE version: (12.0.1+12) (build ) > # Java VM: OpenJDK Server VM (12.0.1+12, mixed mode, emulated-client, g1 > gc, windows-x86) > # Problematic frame: > # C 0x00000377 > > I'll try to find a 11.0.4 fastdebug binaries to test it.. Just "release" 11.0.4 would be fine to test; it was released yesterday. "fastdebug" would be nice if the error persists. -Aleksey From Alan.Bateman at oracle.com Thu Jul 18 09:50:58 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Jul 2019 10:50:58 +0100 Subject: EXCEPTION_ACCESS_VIOLATION on a jlinked 11.0.3+7 32bits In-Reply-To: References: <5ef45520-3f9e-ab0b-670b-70854df3e6b7@oracle.com> Message-ID: <58522a1d-498e-167a-7521-1d0a3717f5f3@oracle.com> On 18/07/2019 10:19, Andrea Vacondio wrote: > These are the args we use: > ?--add-modules > java.base,java.datatransfer,java.logging,java.naming,java.sql,java.desktop,java.xml,java.scripting,jdk.unsupported,java.prefs > --compress 2 --no-man-pages --no-header-files --strip-debug Can you also check this without `--compress 2` ? -Alan From Alan.Bateman at oracle.com Thu Jul 18 13:24:16 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Jul 2019 14:24:16 +0100 Subject: Add "source of module name" to ModuleDescriptor API In-Reply-To: References: Message-ID: <9e60b3b9-017a-ab7b-c0a8-315606f72a56@oracle.com> On 04/07/2019 07:40, Christian Stein wrote: > : > > ?Thank you for the clarification, Alan. > > Wondering why `isAutomatic()` is part of the API then. Its underlying > value is also not declared by the author of the module, but rather > determined at/by the runtime. > Automatic modules require special treatment so it's very important that the runtime or other programs using the ModuleDescriptor API know if the module is an automatic module or not. This isn't the same thing as knowing how the name was generated as most programs shouldn't care about that, e.g. modules generated at run-time will be named by whatever system generates them. -Alan From andrea.vacondio at gmail.com Thu Jul 18 22:03:42 2019 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Fri, 19 Jul 2019 00:03:42 +0200 Subject: EXCEPTION_ACCESS_VIOLATION on a jlinked 11.0.3+7 32bits In-Reply-To: <58522a1d-498e-167a-7521-1d0a3717f5f3@oracle.com> References: <5ef45520-3f9e-ab0b-670b-70854df3e6b7@oracle.com> <58522a1d-498e-167a-7521-1d0a3717f5f3@oracle.com> Message-ID: Tested the same script with 11.0.4 and everything seems to work correctly. Thanks for the help Il giorno gio 18 lug 2019 alle ore 11:50 Alan Bateman < Alan.Bateman at oracle.com> ha scritto: > On 18/07/2019 10:19, Andrea Vacondio wrote: > > These are the args we use: > > --add-modules > > > java.base,java.datatransfer,java.logging,java.naming,java.sql,java.desktop,java.xml,java.scripting,jdk.unsupported,java.prefs > > > --compress 2 --no-man-pages --no-header-files --strip-debug > Can you also check this without `--compress 2` ? > > -Alan >