From Alan.Bateman at oracle.com Fri Aug 4 15:48:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Aug 2017 08:48:58 -0700 Subject: 8185853: Generate readability graph at link time and other startup improvements Message-ID: This is a patch for jdk10/jdk10 to claw back some of the regression to startup performance in JDK 9 for very short lived applications. The bulk of the changes are to the "system modules" jlink plugin and the related code in the module system initialization. Specifically, the plugin now generates code to create the readability graph for initial modules known at link time This allows resolution to be skipped at startup for common cases, it also avoids needing to reconstitute the module descriptors for modules that will not be resolved (the EE modules when the initial module is the class path for example). The system module finder has been significantly changed as part of this but all the execution scenarios (images, exploded builds, images patched with exploded build, etc.) that are needed in differetnt JDK development scenarios work as before. The patch also includes a few misc. changes to reduce the number of class loaded during startup and also some local tuning. There is also a change to the class path initialization to re-fix JDK-6760902 so that lookup of resources on the boot loader append path (-Xbootclasspath/a) is aligned with class loading in the VM in the way that it skips empty path elements. This follows the restoration of tests that Mandy pushed a few days ago with JDK-8185541. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8185853/webrev/index.html -Alan. From mandy.chung at oracle.com Sun Aug 6 00:37:02 2017 From: mandy.chung at oracle.com (mandy chung) Date: Sat, 5 Aug 2017 17:37:02 -0700 Subject: 8185853: Generate readability graph at link time and other startup improvements In-Reply-To: References: Message-ID: <13e4a9b2-8cf2-b3a5-a85e-f9754fd52adf@oracle.com> On 8/4/17 8:48 AM, Alan Bateman wrote: > This is a patch for jdk10/jdk10 to claw back some of the regression to > startup performance in JDK 9 for very short lived applications. > > The bulk of the changes are to the "system modules" jlink plugin and > the related code in the module system initialization. Specifically, > the plugin now generates code to create the readability graph for > initial modules known at link time This allows resolution to be > skipped at startup for common cases, it also avoids needing to > reconstitute the module descriptors for modules that will not be > resolved (the EE modules when the initial module is the class path for > example). The system module finder has been significantly changed as > part of this but all the execution scenarios (images, exploded builds, > images patched with exploded build, etc.) that are needed in > differetnt JDK development scenarios work as before. > > The patch also includes a few misc. changes to reduce the number of > class loaded during startup and also some local tuning. There is also > a change to the class path initialization to re-fix JDK-6760902 so > that lookup of resources on the boot loader append path > (-Xbootclasspath/a) is aligned with class loading in the VM in the way > that it skips empty path elements. This follows the restoration of > tests that Mandy pushed a few days ago with JDK-8185541. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8185853/webrev/index.html It is good to see more optimization be done at link time that improves the startup. jdk/internal/loader/ClassLoaders.java 79 if (cp.length() == 0) cp = null; Our launcher and hotspot VM always set "java.class.path" system property and so it'll be non-null. It might help the readers to check if (cp != null && cp.length() == 0). jdk/internal/module/SystemModulesMap.java 128 Constructor ctor = Class.forName(cn).getConstructor(); Class.forName(Module, String) will only search the specified module. No performance difference since the class exists in java.base but it may make it clear to the readers. jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java This generates one SystemModules for each module that has a main class. A user may create a launcher at link time but specifies a main class which may be different to the one in the module descriptor. A possible future enhancement is to generate a SystemModules for the main class if the launcher is created by jlink. Otherwise, this patch looks good. Mandy From Alan.Bateman at oracle.com Sun Aug 6 09:31:54 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 Aug 2017 10:31:54 +0100 Subject: 8185853: Generate readability graph at link time and other startup improvements In-Reply-To: <13e4a9b2-8cf2-b3a5-a85e-f9754fd52adf@oracle.com> References: <13e4a9b2-8cf2-b3a5-a85e-f9754fd52adf@oracle.com> Message-ID: On 06/08/2017 01:37, mandy chung wrote: > > It is good to see more optimization be done at link time that improves > the startup. > > jdk/internal/loader/ClassLoaders.java > 79 if (cp.length() == 0) cp = null; > Our launcher and hotspot VM always set "java.class.path" system > property and so it'll be non-null. It might help the readers to check > if (cp != null && cp.length() == 0). Fair point, there is an assumption that the VM is created with either an initial module or a class path and HotSpot masks that to some extent. So yes, clearer if we use the above. > > jdk/internal/module/SystemModulesMap.java > 128 Constructor ctor = Class.forName(cn).getConstructor(); > Class.forName(Module, String) will only search the specified module. > No performance difference since the class exists in java.base but it > may make it clear to the readers. The loaded classes haven't been patched to be members of java.base at this point in the startup so there isn't a Module object to use the 2-arg forName. But yes, a comment might help here. > > jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java > This generates one SystemModules for each module that has a main > class. A user may create a launcher at link time but specifies a main > class which may be different to the one in the module descriptor. A > possible future enhancement is to generate a SystemModules for the > main class if the launcher is created by jlink. Yes, I've been thinking about this too and I think it will require a clean way for jlink to expose the details of launchers to plugins. > Otherwise, this patch looks good. Thanks for spending time on this. -Alan From oliver at siegmar.de Wed Aug 9 14:18:14 2017 From: oliver at siegmar.de (Oliver Siegmar) Date: Wed, 9 Aug 2017 16:18:14 +0200 Subject: setLocationForModule doesn't work as expected Message-ID: Hello Jigsaw-experts, I?m currently struggling with the javax.tools.StandardJavaFileManager#setLocationForModule method and wondering if someone could point me in the right direction. I thought, the setLocationForModule method can be used for referencing a dependent module to compile another one. In an example, I have two modules - api and app. The api module compiles fine. When I try to compile the app module, I?m using this to set the path of the compiled api module: fileManager.setLocationForModule(StandardLocation.MODULE_PATH, NAME_OF_THE_API_MODULE, List.of(PATH_OF_THE_COMPILED_API_MODULE)); Unfortunately the compiler can?t find that dependent module ("error: module not found? when trying to compile module-info.java). Also, I?ve noticed, that it perfectly works, if I use StandardLocation.SYSTEM_MODULES instead of StandardLocation.MODULE_PATH. I?ve created a quick demo at https://github.com/osiegmar/java9-module-path-compile-problem Is it my fault or is it a compiler bug? Bye Oliver From oliver at siegmar.de Wed Aug 9 14:39:49 2017 From: oliver at siegmar.de (Oliver Siegmar) Date: Wed, 9 Aug 2017 16:39:49 +0200 Subject: Allow ModuleInfoExtender to be used externally Message-ID: Hello, I have to create a Java 9 modularized jar file programmatically. I noticed, that the compiled module-info.class file gets modified (main-class, module-version and modules-hash) by the jar command line tool (using jdk.internal.module.ModuleInfoExtender). Unfortunately, neither the ModuleInfoExtender itself nor the used asm-lib is exported to allow external use. Is it planned to change this in the final release of Java 9? I think, it is a bit scary, that the binary version of module-info.class gets manipulated to create a jar file. Having to re-implement this functionality in 3rd party tools (like Ant, Maven, Gradle, etc.) doesn?t make it better ;-) Bye Oliver From jonathan.gibbons at oracle.com Wed Aug 9 15:20:04 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 9 Aug 2017 08:20:04 -0700 Subject: setLocationForModule doesn't work as expected In-Reply-To: References: Message-ID: Oliver, It seems like you're doing something reasonable. We'll have to investigate and get back to you. -- Jon On 8/9/17 7:18 AM, Oliver Siegmar wrote: > Hello Jigsaw-experts, > > I?m currently struggling with the javax.tools.StandardJavaFileManager#setLocationForModule method and wondering if someone could point me in the right direction. > > I thought, the setLocationForModule method can be used for referencing a dependent module to compile another one. > > In an example, I have two modules - api and app. The api module compiles fine. When I try to compile the app module, I?m using this to set the path of the compiled api module: > > fileManager.setLocationForModule(StandardLocation.MODULE_PATH, NAME_OF_THE_API_MODULE, List.of(PATH_OF_THE_COMPILED_API_MODULE)); > > Unfortunately the compiler can?t find that dependent module ("error: module not found? when trying to compile module-info.java). > > Also, I?ve noticed, that it perfectly works, if I use StandardLocation.SYSTEM_MODULES instead of StandardLocation.MODULE_PATH. > > I?ve created a quick demo at https://github.com/osiegmar/java9-module-path-compile-problem > > > Is it my fault or is it a compiler bug? > > > Bye > > Oliver > From mandy.chung at oracle.com Wed Aug 9 17:35:04 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 9 Aug 2017 10:35:04 -0700 Subject: Allow ModuleInfoExtender to be used externally In-Reply-To: References: Message-ID: On 8/9/17 7:39 AM, Oliver Siegmar wrote: > Hello, > > I have to create a Java 9 modularized jar file programmatically. > > I noticed, that the compiled module-info.class file gets modified (main-class, module-version and modules-hash) by the jar command line tool (using jdk.internal.module.ModuleInfoExtender). > > Unfortunately, neither the ModuleInfoExtender itself nor the used asm-lib is exported to allow external use. Is it planned to change this in the final release of Java 9? ModuleInfoExtender is JDK internal API and not planned to be exported/opened. New version of ASM supports module-info.class. You can probably try out ASM 6 alpha version for now. > > I think, it is a bit scary, that the binary version of module-info.class gets manipulated to create a jar file. Having to re-implement this functionality in 3rd party tools (like Ant, Maven, Gradle, etc.) doesn?t make it better ;-) To be clear, the jar tool does not change Module attribute but it may add optional attributes. I don't see how it can be scary to you. Mandy From oliver at siegmar.de Thu Aug 10 07:29:39 2017 From: oliver at siegmar.de (Oliver Siegmar) Date: Thu, 10 Aug 2017 09:29:39 +0200 Subject: Allow ModuleInfoExtender to be used externally In-Reply-To: References: Message-ID: <4FFA34B6-619E-474A-B382-861C37F4A029@siegmar.de> > On 8/9/17 7:35 PM, mandy chung wrote: > ModuleInfoExtender is JDK internal API and not planned to be exported/opened. New version of ASM supports module-info.class. You can probably try out ASM 6 alpha version for now. Thank you for clarifying. So, an external library (ASM) is required to build modularized Jar files ? the JDK offers no built-in support for that (except the JAR command line tool). I?m very surprised as I think it is JDKs job to offer this functionality to 3rd party tools (as it does it with the compiler and other aspects of building and packaging Java applications). >> I think, it is a bit scary, that the binary version of module-info.class gets manipulated to create a jar file. Having to re-implement this functionality in 3rd party tools (like Ant, Maven, Gradle, etc.) doesn?t make it better ;-) > > To be clear, the jar tool does not change Module attribute but it may add optional attributes. I don't see how it can be scary to you. Well, it remembers me of the pre-XML era and all the problems we had that time with binary data and protocols ? this is why it scares me. I bet, that the module-info would be a XML file if Jigsaw would have been released in 2000 :-). Anyway, forcing 3rd party tools to re-implement this mechanism is asking for trouble IMO. - Oliver From stephan.herrmann at berlin.de Thu Aug 10 11:01:55 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Thu, 10 Aug 2017 13:01:55 +0200 Subject: Java Platform Module System - Xlint? In-Reply-To: <1545f23a-eaf9-ae66-dce6-364cca20eac9@berlin.de> References: <20170424091831.557135740@eggemoggin.niobe.net> <58FEAB69.2080008@oracle.com> <58FF812E.1010006@oracle.com> <1b984d15-2056-5860-a0b0-40d85edffe42@berlin.de> <5903CF7D.9060803@oracle.com> <1ef5ce0d-f092-b81a-5fb8-c1ea577064d2@berlin.de> <1184f228-0a6d-b2b3-55c5-6123a68ba196@oracle.com> <5967e898-588d-16dd-b398-831c05ee1766@berlin.de> <1545f23a-eaf9-ae66-dce6-364cca20eac9@berlin.de> Message-ID: From JLS 9.6.4.5: "For other kinds of warnings, compiler vendors should document the strings they support for @SuppressWarnings. Vendors are encouraged to cooperate to ensure that the same names work across multiple compilers." Any suggestions, how we can engage in such cooperation? In particular: where can I read what exactly [1] the new -Xlint tokens of javac mean, and whether or not all -Xlint tokens work the same also for @SuppressWarnings? Stephan [1] I don't think explanations like "Warns about module system related issues" are sufficient for coordination. On 06.06.2017 12:37, Stephan Herrmann wrote: > I didn't see an answer to this question: > > > On 30.04.2017 23:45, Stephan Herrmann wrote: >> On 30.04.2017 17:47, Alan Bateman wrote: >>> On 30/04/2017 12:10, Stephan Herrmann wrote: >>> >>>> : >>>> >>>> Java 9 could make "API leaks" either illegal or ineffective and thus rule out >>>> an entire category of ill-formed programs, which to-date must unfortunately >>>> be accepted by module-unaware compilers: >>>> >>>> (A) Java 9 has the opportunity to say that the declaration of m1 is illegal, >>>> because it publicly exposes a non-accessible type, which is broken in >>>> every regard. >>> FWIW, this is -Xlint:exports when using javac, e.g: public class in a non-exported package: >>> >>> src/m/p/C1.java:4: warning: [exports] class C2 in module m is not exported >>> public q.C2 hello() { return null; } >>> ^ >>> 1 warning >>> >>> or a non-public class in an exported package: >>> >>> src/m/p/C1.java:4: warning: [exports] class C2 in module m is not accessible to clients that require this module >>> public C2 hello() { return null; } >>> ^ >>> 1 warning >>> >>> -Alan >> >> Thanks for the hint. >> >> My obvious question: Is this specified (where?), or javac's own deliberation? >> Even if the latter, it would be great to see a list of jigsaw related lints. > > I see several additions to Xlint in https://docs.oracle.com/javase/9/tools/javac.htm > > Are these Xlint tokens also supported as @SuppressWarnings tokens? If so, we should > definitely coordinate between compilers, which requires more specific descriptions > of the warnings in each of those categories. "Issues regarding ..." is not very > specific :) > > Stephan From stephan.herrmann at berlin.de Thu Aug 10 12:14:25 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Thu, 10 Aug 2017 14:14:25 +0200 Subject: Does --add-exports imply --add-reads? Message-ID: Given: // one/p/C.java package p; public class C {} // one/module-info.java module one {} // two/q/D.java: package q; import p.C; public class D {} // two/module-info.java module two {} javac only needs a --add-exports to accept the code $ javac9 -d bin --module-source-path . --add-exports one/p=two $(find one two -name \*.java) (succeeds) According to latest in JEP 261 this should not work without any form of requires. Which is correct, javac or JEP? It has been discussed elsewhere that the JEP ("Updated 2017/03/08 13:58") may be lagging behind. It, e.g., has no mention of --add-opens. Is there a newer document specifying these things? Additionally, I'm surprised to see that javac documentation mentions --add-exports et al under the heading "Extra Options for javac" *not* "Standard Options for javac". Stephan From oleg.tsalko at gmail.com Mon Aug 14 08:35:35 2017 From: oleg.tsalko at gmail.com (Oleg Tsal-Tsalko) Date: Mon, 14 Aug 2017 11:35:35 +0300 Subject: Jigsaw related questions emerged during Java 9 Jigsaw Hack Day Message-ID: Dear experts, Recently we run Java 9 Jigsaw Hack Day in Kiev, Ukraine and several questions have been raised: 1. When declaring 'exports' in module descriptor why wildcard are not supported like com.abs.*? 2. Why compilation doesn?t fail in case several modules with same name put on module-path, but it only fails in runtime on startup ( https://github.com/AdoptOpenJDK/jdk9-jigsaw/tree/master/session-1-jigsaw-intro/08_ModulesExportConflict )? 3. What is the best practice for using `transitive` dependencies? Where to use them apart of cases when type of one module are used in API of another module like return types, etc.? 4. If there are 3 conflicting modules in module path error says only about 2 first modules conflict only. Why that? Fail fast? Thank you, Oleg From alex.buckley at oracle.com Mon Aug 14 19:47:48 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 14 Aug 2017 12:47:48 -0700 Subject: Jigsaw related questions emerged during Java 9 Jigsaw Hack Day In-Reply-To: References: Message-ID: <5991FE64.1080905@oracle.com> On 8/14/2017 1:35 AM, Oleg Tsal-Tsalko wrote: > Recently we run Java 9 Jigsaw Hack Day in Kiev, Ukraine and several > questions have been raised: > > 1. When declaring 'exports' in module descriptor why wildcard are not > supported like com.abs.*? The packages exported by a module are meant to be a stable API that consumers can rely on. For this reason, we make the module author spell out the exported packages explicitly. This also dials down the likelihood of multiple modules needlessly exporting the same package. Additionally, it avoids the confusion that would occur if com.abs.* was exported without qualification while com.abs.foo was exported with qualification. > 2. Why compilation doesn?t fail in case several modules with same name > put on module-path, but it only fails in runtime on startup ( > https://github.com/AdoptOpenJDK/jdk9-jigsaw/tree/master/session-1-jigsaw-intro/08_ModulesExportConflict > )? When compiling src/com.greetings/module-info.java, javac resolves 'requires org.astro;' by 1) searching the modulepath for a directory called org.astro, then 2) seeking a module-info.class file in that directory which declares a module called org.astro. The directory is found successfully (mods/org.astro), and a module-info.class file is found in that directory which declares 'module org.astro {..}'. javac is disinterested in the existence of another directory (mods/org.astro2) which contains another declaration for a module called org.astro. If we assume that directories are named sensibly, that is, in accordance with the modules they declare, then it's reasonable for javac to ignore mods/org.astro2. javac observes just enough to compile what it was given on the command line -- it does not validate the world. In contrast, the Java runtime is in a good position to validate the world, so it's reasonable for the runtime to detect and complain about duplicate modules called org.astro. This should all be documented in JEP 261. > 3. What is the best practice for using `transitive` dependencies? Where > to use them apart of cases when type of one module are used in API of > another module like return types, etc.? Apart from API dependencies, 'requires transitive' is useful for declaring "aggregator" modules such as java.se. > 4. If there are 3 conflicting modules in module path error says only > about 2 first modules conflict only. Why that? Fail fast? This is really a request for better traceability of which modules are observed and resolved, which is fair. Alex From russell.gold at oracle.com Wed Aug 16 01:09:49 2017 From: russell.gold at oracle.com (Russell Gold) Date: Tue, 15 Aug 2017 21:09:49 -0400 Subject: =?utf-8?Q?Re=3A_trySetAccessible=E2=80=8B?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> Message-ID: <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> I am clearly missing something, here. Using build 180, I have variables: Method method, Class callingClass. I evaluate: callingClass.getModule() - -> java.lang.Module at 2940 ?unnamed module @f973499? method.getDeclaringClass() -> java.lang.Class ?class java.io.ObjectInputStream? method.getDeclaringClass().getModule() -> java.lang.Module @2949 ?module java.base" method.getDeclaringClass().getModule().isOpen("java.io?) -> false // which I read as saying that package ?java.io? in module java.base is NOT open to the unnamed module but: method.getDeclaringClass().getModule().isOpen("java.io", callingClass.getModule()) -> true // which seems to say that it IS open to that particular unnamed module ?! of course, method.setAccessible(true) gives me the warning. What am I missing? Thanks, Russ > On Jul 11, 2017, at 6:11 AM, Alan Bateman wrote: > > On 11/07/2017 10:16, Uwe Schindler wrote: >> : >> Sorry, I mixed up the parameters. So basically the "correct" code to check if something like java.lang.String is open to Groovy would be: >> >> Module groovyModule = CachedClass.class.getModule(); // org.codehaus.groovy.reflection.CachedClass; >> Class clazz = String.class; // to test if open >> return clazz.getModule().isOpen(String.class.getPackage().getName(), groovyModule); >> >> If I do this, it returns "true" for String, Object or any other class. So the behaviour is consistent. > Yes, it has to be consistent. > > As an aside, you can replace getPackage().getName() with getPackageName() - it's more efficient and avoids the NPE when the class is an array or primitive. > > >> >> I implemented this check as a single MethodHandle to a precompiled method that takes a Class and returns true/false if the Class is open to Groovy's module: https://goo.gl/XvdCQK >> By this it's possible to execute this without a Java 9 at compile time. Unfortunately, it doesn't help, because java.base is open to unnamed module > Right, although isOpen("java.lang") will return false because the package is not open to all modules. > > >> >> But now it is impossible for us to check, if something is not open by default. > Module::getDescriptor will return the module descriptor for named modules. So in this case, Object.class.getModule().getDescriptor() returns the ModuleDescriptor for java.base so you can inspect the packages and which are exported and/or opened before being changed by runtime. So there is enough in the API to determine which packages have been opened at runtime (either via CLI options or APIs). > > -Alan From oleg.tsalko at gmail.com Wed Aug 16 13:51:52 2017 From: oleg.tsalko at gmail.com (Oleg Tsal-Tsalko) Date: Wed, 16 Aug 2017 16:51:52 +0300 Subject: Jigsaw related questions emerged during Java 9 Jigsaw Hack Day In-Reply-To: <5991FE64.1080905@oracle.com> References: <5991FE64.1080905@oracle.com> Message-ID: Thank you Alex for detailed answers! 2017-08-14 22:47 GMT+03:00 Alex Buckley : > On 8/14/2017 1:35 AM, Oleg Tsal-Tsalko wrote: > >> Recently we run Java 9 Jigsaw Hack Day in Kiev, Ukraine and several >> questions have been raised: >> >> 1. When declaring 'exports' in module descriptor why wildcard are not >> supported like com.abs.*? >> > > The packages exported by a module are meant to be a stable API that > consumers can rely on. For this reason, we make the module author spell out > the exported packages explicitly. This also dials down the likelihood of > multiple modules needlessly exporting the same package. Additionally, it > avoids the confusion that would occur if com.abs.* was exported without > qualification while com.abs.foo was exported with qualification. > > 2. Why compilation doesn?t fail in case several modules with same name >> put on module-path, but it only fails in runtime on startup ( >> https://github.com/AdoptOpenJDK/jdk9-jigsaw/tree/master/ >> session-1-jigsaw-intro/08_ModulesExportConflict >> )? >> > > When compiling src/com.greetings/module-info.java, javac resolves > 'requires org.astro;' by > > 1) searching the modulepath for a directory called org.astro, then > > 2) seeking a module-info.class file in that directory which declares a > module called org.astro. > > The directory is found successfully (mods/org.astro), and a > module-info.class file is found in that directory which declares 'module > org.astro {..}'. > > javac is disinterested in the existence of another directory > (mods/org.astro2) which contains another declaration for a module called > org.astro. If we assume that directories are named sensibly, that is, in > accordance with the modules they declare, then it's reasonable for javac to > ignore mods/org.astro2. javac observes just enough to compile what it was > given on the command line -- it does not validate the world. In contrast, > the Java runtime is in a good position to validate the world, so it's > reasonable for the runtime to detect and complain about duplicate modules > called org.astro. This should all be documented in JEP 261. > > 3. What is the best practice for using `transitive` dependencies? Where >> to use them apart of cases when type of one module are used in API of >> another module like return types, etc.? >> > > Apart from API dependencies, 'requires transitive' is useful for declaring > "aggregator" modules such as java.se. > > 4. If there are 3 conflicting modules in module path error says only >> about 2 first modules conflict only. Why that? Fail fast? >> > > This is really a request for better traceability of which modules are > observed and resolved, which is fair. > > Alex > From martinrb at google.com Fri Aug 18 01:22:20 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Aug 2017 18:22:20 -0700 Subject: """error: module testng reads package test from both test and testng""" Message-ID: When I run the jtreg test java/lang/ModuleTests/addXXX I fail with direct: error: module testng reads package test from both test and testng In the javac command line I see: --add-modules testng,jcommander but ... testng and jcommander aren't modules; they're just garden variety jar files. Running jtreg 4.2-b07. From mandy.chung at oracle.com Mon Aug 21 19:12:57 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 21 Aug 2017 12:12:57 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: The test itself is a module that depends on testng. So testng.jar is added as an automatic module. This test passes on my setup. I am puzzling how jcommander.jar is added to the module path. Can you send the .jtr file and list what's in JTwork/modules directory? Mandy On 8/17/17 6:22 PM, Martin Buchholz wrote: > When I run the jtreg test > java/lang/ModuleTests/addXXX > I fail with > > direct: > error: module testng reads package test from both test and testng > > In the javac command line I see: > --add-modules testng,jcommander > but ... testng and jcommander aren't modules; they're just garden variety > jar files. > > Running jtreg 4.2-b07. From martinrb at google.com Mon Aug 21 21:14:59 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Aug 2017 14:14:59 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: I just upgraded to 4.2-b08, although without any effect on this problem. jcommander.jar is from jtreg's lib directory code-tools/jtreg/make/Defs.gmk says: """ # TestNG requires jcommander, which may or may not be bundled with TESTNG_JAR. # If it is not, set JCOMMANDER_JAR to an appropriate version """ $ ls -l ./JTwork/modules total 1620 -rw-r--r-- 1 martin martin 63504 Aug 21 12:27 jcommander.jar -rw-r--r-- 1 martin martin 1589287 Aug 21 12:27 testng.jar $ /home/martin/jtreg-binaries/current/bin/jtreg -noreport -v:fail -compilejdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk -testjdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk java/lang/ModuleTests/addXXX -------------------------------------------------- TEST: java/lang/ModuleTests/addXXX/Driver.java TEST JDK: /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk ACTION: build -- Failed. Compilation failed: Compilation failed REASON: User specified action: run build test/* m1/* m2/* m3/* m4/* TIME: 0.943 seconds messages: command: build test/* m1/* m2/* m3/* m4/* reason: User specified action: run build test/* m1/* m2/* m3/* m4/* Test directory: compile: test/module-info, test/test.C, test/test.Service, test/test.Main, m1/module-info, m1/p1.C, m2/module-info, m2/p2.C, m2/p2.internal.C, m3/module-info, m3/p3.C, m4/module-info, m4/p4.C elapsed time (seconds): 0.943 ACTION: compile -- Failed. Compilation failed: Compilation failed REASON: .class file out of date or does not exist TIME: 0.938 seconds messages: command: compile /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Service.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Main.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/p1/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/internal/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/p3/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/p4/C.java reason: .class file out of date or does not exist Mode: othervm elapsed time (seconds): 0.938 configuration: javac compilation environment add modules: testng jcommander module path: /home/martin/ws/jdk10/jdk/test/JTwork/modules rerun: DISPLAY=localhost:10.0 \ HOME=/home/martin \ LANG=en_US.UTF-8 \ PATH=/bin:/usr/bin \ /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/javac \ -J-Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -J-Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -J-Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -J-Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -J-Dtest.vm.opts= \ -J-Dtest.tool.vm.opts= \ -J-Dtest.compiler.opts= \ -J-Dtest.java.opts= \ -J-Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -J-Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -J-Dtest.timeout.factor=1.0 \ @/home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/compile.0.jta STDOUT: STDERR: error: module testng reads package test from both test and testng 1 error TEST RESULT: Failed. Compilation failed: Compilation failed -------------------------------------------------- Test results: failed: 1 On Mon, Aug 21, 2017 at 12:12 PM, mandy chung wrote: > The test itself is a module that depends on testng. So testng.jar is > added as an automatic module. This test passes on my setup. > > I am puzzling how jcommander.jar is added to the module path. Can you send > the .jtr file and list what's in JTwork/modules directory? > > Mandy > > > On 8/17/17 6:22 PM, Martin Buchholz wrote: > >> When I run the jtreg test >> java/lang/ModuleTests/addXXX >> I fail with >> >> direct: >> error: module testng reads package test from both test and testng >> >> In the javac command line I see: >> --add-modules testng,jcommander >> but ... testng and jcommander aren't modules; they're just garden variety >> jar files. >> >> Running jtreg 4.2-b07. >> > > From mandy.chung at oracle.com Mon Aug 21 23:06:53 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 21 Aug 2017 16:06:53 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: I can reproduce it and javac outputs the following errors. javac compiles successfully if jcommander.jar is removed. Will look into it. error: the unnamed module reads package com.beust.jcommander from both jcommander and testng error: the unnamed module reads package com.beust.jcommander.validators from both jcommander and testng error: the unnamed module reads package com.beust.jcommander.internal from both jcommander and testng error: the unnamed module reads package com.beust.jcommander.defaultprovider from both jcommander and testng error: the unnamed module reads package com.beust.jcommander.converters from both jcommander and testng error: module jcommander reads package com.beust.jcommander from both testng and jcommander error: module jcommander reads package com.beust.jcommander.validators from both testng and jcommander error: module jcommander reads package com.beust.jcommander.internal from both testng and jcommander error: module jcommander reads package com.beust.jcommander.defaultprovider from both testng and jcommander error: module jcommander reads package com.beust.jcommander.converters from both testng and jcommander error: module testng reads package com.beust.jcommander from both jcommander and testng error: module testng reads package com.beust.jcommander.validators from both jcommander and testng error: module testng reads package com.beust.jcommander.internal from both jcommander and testng error: module testng reads package com.beust.jcommander.defaultprovider from both jcommander and testng error: module testng reads package com.beust.jcommander.converters from both jcommander and testng /scratch/mchung/ws/jdk10/jdk10-dev/jdk/test/java/lang/ModuleTests/addXXX/test/module-info.java:23: error: module test reads package com.beust.jcommander from both testng and jcommander module test { Mandy On 8/21/17 2:14 PM, Martin Buchholz wrote: > I just upgraded to 4.2-b08, although without any effect on this > problem. jcommander.jar is from jtreg's lib directory > > code-tools/jtreg/make/Defs.gmk says: > """ > # TestNG requires jcommander, which may or may not be bundled with > TESTNG_JAR. > # If it is not, set JCOMMANDER_JAR to an appropriate version > """ > > $ ls -l ./JTwork/modules > total 1620 > -rw-r--r-- 1 martin martin 63504 Aug 21 12:27 jcommander.jar > -rw-r--r-- 1 martin martin 1589287 Aug 21 12:27 testng.jar > > $ /home/martin/jtreg-binaries/current/bin/jtreg -noreport -v:fail > -compilejdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk > -testjdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk > java/lang/ModuleTests/addXXX > -------------------------------------------------- > TEST: java/lang/ModuleTests/addXXX/Driver.java > TEST JDK: > /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk > > ACTION: build -- Failed. Compilation failed: Compilation failed > REASON: User specified action: run build test/* m1/* m2/* m3/* m4/* > TIME: 0.943 seconds > messages: > command: build test/* m1/* m2/* m3/* m4/* > reason: User specified action: run build test/* m1/* m2/* m3/* m4/* > Test directory: > compile: test/module-info, test/test.C, test/test.Service, > test/test.Main, m1/module-info, m1/p1.C, m2/module-info, m2/p2.C, > m2/p2.internal.C, m3/module-info, m3/p3.C, m4/module-info, m4/p4.C > elapsed time (seconds): 0.943 > > ACTION: compile -- Failed. Compilation failed: Compilation failed > REASON: .class file out of date or does not exist > TIME: 0.938 seconds > messages: > command: compile > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/module-info.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/C.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Service.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Main.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/module-info.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/p1/C.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/module-info.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/C.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/internal/C.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/module-info.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/p3/C.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/module-info.java > /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/p4/C.java > reason: .class file out of date or does not exist > Mode: othervm > elapsed time (seconds): 0.938 > configuration: > javac compilation environment > add modules: testng jcommander > module path: /home/martin/ws/jdk10/jdk/test/JTwork/modules > > rerun: > DISPLAY=localhost:10.0 \ > HOME=/home/martin \ > LANG=en_US.UTF-8 \ > PATH=/bin:/usr/bin \ > /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/javac > \ > -J-Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ > -J-Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX > \ > -J-Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d > \ > -J-Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d > \ > -J-Dtest.vm.opts= \ > -J-Dtest.tool.vm.opts= \ > -J-Dtest.compiler.opts= \ > -J-Dtest.java.opts= \ > -J-Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk > \ > -J-Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk > \ > -J-Dtest.timeout.factor=1.0 \ > @/home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/compile.0.jta > STDOUT: > STDERR: > error: module testng reads package test from both test and testng > 1 error > > TEST RESULT: Failed. Compilation failed: Compilation failed > -------------------------------------------------- > Test results: failed: 1 > > On Mon, Aug 21, 2017 at 12:12 PM, mandy chung > wrote: > > The test itself is a module that depends on testng. So testng.jar > is added as an automatic module. This test passes on my setup. > > I am puzzling how jcommander.jar is added to the module path. Can > you send the .jtr file and list what's in JTwork/modules directory? > > Mandy > > > On 8/17/17 6:22 PM, Martin Buchholz wrote: > > When I run the jtreg test > java/lang/ModuleTests/addXXX > I fail with > > direct: > error: module testng reads package test from both test and testng > > In the javac command line I see: > --add-modules testng,jcommander > but ... testng and jcommander aren't modules; they're just > garden variety > jar files. > > Running jtreg 4.2-b07. > > > From mandy.chung at oracle.com Tue Aug 22 18:01:04 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 22 Aug 2017 11:01:04 -0700 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> Message-ID: As described in the javadoc [1], Module::isOpen(String pn) returns true if this module has opened a package unconditionally. It returns true only if the module declares "opens pn;" unconditionally in module-info.java.? Since java.base does not open "java.io" unconditionally, so isOpen("java.io?) returns false. Mandy [1] http://download.java.net/java/jdk9/docs/api/java/lang/Module.html#isOpen-java.lang.String- On 8/15/17 6:09 PM, Russell Gold wrote: > I am clearly missing something, here. Using build 180, I have variables: > > Method method, Class callingClass. > > I evaluate: > > callingClass.getModule() - > -> java.lang.Module at 2940 ?unnamed module @f973499? > method.getDeclaringClass() > -> java.lang.Class ?class java.io.ObjectInputStream? > method.getDeclaringClass().getModule() > -> java.lang.Module @2949 ?module java.base" > method.getDeclaringClass().getModule().isOpen("java.io?) > -> false // which I read as saying that package ?java.io? in module java.base is NOT open to the unnamed module > > but: > > method.getDeclaringClass().getModule().isOpen("java.io", callingClass.getModule()) > -> true // which seems to say that it IS open to that particular unnamed module ?! > > of course, method.setAccessible(true) gives me the warning. > > What am I missing? > > Thanks, > Russ > >> On Jul 11, 2017, at 6:11 AM, Alan Bateman wrote: >> >> On 11/07/2017 10:16, Uwe Schindler wrote: >>> : >>> Sorry, I mixed up the parameters. So basically the "correct" code to check if something like java.lang.String is open to Groovy would be: >>> >>> Module groovyModule = CachedClass.class.getModule(); // org.codehaus.groovy.reflection.CachedClass; >>> Class clazz = String.class; // to test if open >>> return clazz.getModule().isOpen(String.class.getPackage().getName(), groovyModule); >>> >>> If I do this, it returns "true" for String, Object or any other class. So the behaviour is consistent. >> Yes, it has to be consistent. >> >> As an aside, you can replace getPackage().getName() with getPackageName() - it's more efficient and avoids the NPE when the class is an array or primitive. >> >> >>> I implemented this check as a single MethodHandle to a precompiled method that takes a Class and returns true/false if the Class is open to Groovy's module: https://goo.gl/XvdCQK >>> By this it's possible to execute this without a Java 9 at compile time. Unfortunately, it doesn't help, because java.base is open to unnamed module >> Right, although isOpen("java.lang") will return false because the package is not open to all modules. >> >> >>> But now it is impossible for us to check, if something is not open by default. >> Module::getDescriptor will return the module descriptor for named modules. So in this case, Object.class.getModule().getDescriptor() returns the ModuleDescriptor for java.base so you can inspect the packages and which are exported and/or opened before being changed by runtime. So there is enough in the API to determine which packages have been opened at runtime (either via CLI options or APIs). >> >> -Alan From mandy.chung at oracle.com Tue Aug 22 19:38:33 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 22 Aug 2017 12:38:33 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: Hi Martin, "error: module testng reads package test from both test and testng" indicates that a split package is detected.?? Does your testng.jar contain classes of package "test"??? I downloaded testng from maven which does not have the package "test". The testng.jar version I had bundled with jcommander classes and hence the error message reports com.beust.jcommander.* packages from jcommander and testng module.? It was an old version before testng was mavenized.?? If I run jtreg with the testng and jcommander downloaded from maven, the test passes. You can run java -p JTwork/modules --validate-modules to check if any split packages or other conflict. Jon, Jan, ? I think the javac error message could be improved to make it clear that the package is split in multiple module.?? In addition, the test only contains explicit modules.?? It's strange that the javac reports that "the unnamed module reads package xxx from ....".? I will create a JBS issue on improving the error message. Mandy On 8/21/17 4:06 PM, mandy chung wrote: > I can reproduce it and javac outputs the following errors.? javac > compiles successfully if jcommander.jar is removed.?? Will look into it. > > error: the unnamed module reads package com.beust.jcommander from both > jcommander and testng > error: the unnamed module reads package > com.beust.jcommander.validators from both jcommander and testng > error: the unnamed module reads package com.beust.jcommander.internal > from both jcommander and testng > error: the unnamed module reads package > com.beust.jcommander.defaultprovider from both jcommander and testng > error: the unnamed module reads package > com.beust.jcommander.converters from both jcommander and testng > error: module jcommander reads package com.beust.jcommander from both > testng and jcommander > error: module jcommander reads package com.beust.jcommander.validators > from both testng and jcommander > error: module jcommander reads package com.beust.jcommander.internal > from both testng and jcommander > error: module jcommander reads package > com.beust.jcommander.defaultprovider from both testng and jcommander > error: module jcommander reads package com.beust.jcommander.converters > from both testng and jcommander > error: module testng reads package com.beust.jcommander from both > jcommander and testng > error: module testng reads package com.beust.jcommander.validators > from both jcommander and testng > error: module testng reads package com.beust.jcommander.internal from > both jcommander and testng > error: module testng reads package > com.beust.jcommander.defaultprovider from both jcommander and testng > error: module testng reads package com.beust.jcommander.converters > from both jcommander and testng > /scratch/mchung/ws/jdk10/jdk10-dev/jdk/test/java/lang/ModuleTests/addXXX/test/module-info.java:23: > error: module test reads package com.beust.jcommander from both testng > and jcommander > module test { > > Mandy > > On 8/21/17 2:14 PM, Martin Buchholz wrote: >> I just upgraded to 4.2-b08, although without any effect on this >> problem.? jcommander.jar is from jtreg's lib directory >> >> code-tools/jtreg/make/Defs.gmk says: >> """ >> # TestNG requires jcommander, which may or may not be bundled with >> TESTNG_JAR. >> # If it is not, set JCOMMANDER_JAR to an appropriate version >> """ >> >> ?$ ls -l ./JTwork/modules >> total 1620 >> -rw-r--r-- 1 martin martin?? 63504 Aug 21 12:27 jcommander.jar >> -rw-r--r-- 1 martin martin 1589287 Aug 21 12:27 testng.jar >> >> ?$ /home/martin/jtreg-binaries/current/bin/jtreg -noreport -v:fail >> -compilejdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> -testjdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> java/lang/ModuleTests/addXXX >> -------------------------------------------------- >> TEST: java/lang/ModuleTests/addXXX/Driver.java >> TEST JDK: >> /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> >> ACTION: build -- Failed. Compilation failed: Compilation failed >> REASON: User specified action: run build test/* m1/* m2/* m3/* m4/* >> TIME:?? 0.943 seconds >> messages: >> command: build test/* m1/* m2/* m3/* m4/* >> reason: User specified action: run build test/* m1/* m2/* m3/* m4/* >> Test directory: >> ? compile: test/module-info, test/test.C, test/test.Service, >> test/test.Main, m1/module-info, m1/p1.C, m2/module-info, m2/p2.C, >> m2/p2.internal.C, m3/module-info, m3/p3.C, m4/module-info, m4/p4.C >> elapsed time (seconds): 0.943 >> >> ACTION: compile -- Failed. Compilation failed: Compilation failed >> REASON: .class file out of date or does not exist >> TIME:?? 0.938 seconds >> messages: >> command: compile >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/module-info.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/C.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Service.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Main.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/module-info.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/p1/C.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/module-info.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/C.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/internal/C.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/module-info.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/p3/C.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/module-info.java >> /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/p4/C.java >> reason: .class file out of date or does not exist >> Mode: othervm >> elapsed time (seconds): 0.938 >> configuration: >> javac compilation environment >> ? add modules: testng jcommander >> ? module path: /home/martin/ws/jdk10/jdk/test/JTwork/modules >> >> rerun: >> DISPLAY=localhost:10.0 \ >> HOME=/home/martin \ >> LANG=en_US.UTF-8 \ >> PATH=/bin:/usr/bin \ >> /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/javac >> \ >> -J-Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX >> \ >> -J-Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX >> \ >> -J-Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d >> \ >> -J-Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d >> \ >> ??????? -J-Dtest.vm.opts= \ >> ??????? -J-Dtest.tool.vm.opts= \ >> ??????? -J-Dtest.compiler.opts= \ >> ??????? -J-Dtest.java.opts= \ >> -J-Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> \ >> -J-Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> \ >> ??????? -J-Dtest.timeout.factor=1.0 \ >> @/home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/compile.0.jta >> >> STDOUT: >> STDERR: >> error: module testng reads package test from both test and testng >> 1 error >> >> TEST RESULT: Failed. Compilation failed: Compilation failed >> -------------------------------------------------- >> Test results: failed: 1 >> >> On Mon, Aug 21, 2017 at 12:12 PM, mandy chung > > wrote: >> >> ??? The test itself is a module that depends on testng.? So testng.jar >> ??? is added as an automatic module.? This test passes on my setup. >> >> ??? I am puzzling how jcommander.jar is added to the module path. Can >> ??? you send the .jtr file and list what's in JTwork/modules directory? >> >> ??? Mandy >> >> >> ??? On 8/17/17 6:22 PM, Martin Buchholz wrote: >> >> ??????? When I run the jtreg test >> ??????? java/lang/ModuleTests/addXXX >> ??????? I fail with >> >> ??????? direct: >> ??????? error: module testng reads package test from both test and >> testng >> >> ??????? In the javac command line I see: >> ????????? --add-modules testng,jcommander >> ??????? but ... testng and jcommander aren't modules; they're just >> ??????? garden variety >> ??????? jar files. >> >> ??????? Running jtreg 4.2-b07. >> >> >> > From martinrb at google.com Tue Aug 22 21:09:35 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Aug 2017 14:09:35 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: Mandy, thanks for the investigation. On Tue, Aug 22, 2017 at 12:38 PM, mandy chung wrote: > > The testng.jar version I had bundled with jcommander classes and hence the > error message reports com.beust.jcommander.* packages from jcommander and > testng module. It was an old version before testng was mavenized. If I > run jtreg with the testng and jcommander downloaded from maven, the test > passes. > Right. maven and jigsaw are both opinionated "module" systems. Modern testng and jcommander mavenized jar files are cleanly separated, from maven's point of view. > Jon, Jan, > I think the javac error message could be improved to make it clear that > the package is split in multiple module. In addition, the test only > contains explicit modules. It's strange that the javac reports that "the > unnamed module reads package xxx from ....". I will create a JBS issue on > improving the error message. Yes, this message is very confusing. From martinrb at google.com Tue Aug 22 21:55:52 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Aug 2017 14:55:52 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: On Tue, Aug 22, 2017 at 12:38 PM, mandy chung wrote: > Does your testng.jar contain classes of package "test"? I downloaded > testng from maven which does not have the package "test". > Sorry, I missed that question. Yes, for historical reasons we are using testng 6.9.8, and I see: $ ( wget -qOtestng.jar https://search.maven.org/remotecontent?filepath=org/testng/testng/6.9.8/testng-6.9.8.jar && jar tf testng.jar | grep '^test/[^/]*.class$' | tail; rm testng.jar) test/ReturnValueTest.class test/SampleInheritance.class test/SerializationTest.class test/SimpleBaseTest.class test/StaticTest$InnerStaticClass.class test/StaticTest.class test/Test1.class test/Test2.class test/TestHelper.class test/TestListener.class Including test/ is probably a packaging mistake. From mandy.chung at oracle.com Tue Aug 22 22:05:33 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 22 Aug 2017 15:05:33 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: <3bd7b6f0-a62e-d10e-49c3-027ba8d63ba2@oracle.com> On 8/22/17 2:55 PM, Martin Buchholz wrote: > > > On Tue, Aug 22, 2017 at 12:38 PM, mandy chung > wrote: > > Does your testng.jar contain classes of package "test"??? I > downloaded testng from maven which does not have the package "test". > > > Sorry, I missed that question.? Yes, for historical reasons we are > using testng 6.9.8, and I see: > > ? $ ( wget -qOtestng.jar > https://search.maven.org/remotecontent?filepath=org/testng/testng/6.9.8/testng-6.9.8.jar > && jar tf testng.jar | grep '^test/[^/]*.class$' | tail; rm testng.jar) > test/ReturnValueTest.class > test/SampleInheritance.class > test/SerializationTest.class > test/SimpleBaseTest.class > test/StaticTest$InnerStaticClass.class > test/StaticTest.class > test/Test1.class > test/Test2.class > test/TestHelper.class > test/TestListener.class > > Including test/ is probably a packaging mistake. Probably.? test package is not in 6.9.5 and 6.11 which I checked. Mandy From martinrb at google.com Tue Aug 22 22:52:24 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Aug 2017 15:52:24 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: I tried updating my jtreg from testng 6.9.8 to 6.9.9 and got the insufficiently helpful Error occurred during initialization of boot layer java.lang.module.FindException: Module testng not found, required by test even though this new jtreg can run other testng tests successfully. Full log below: $ jtr java/lang/ModuleTests/addXXX/Driver.java /home/martin/jtreg-binaries/current/bin/jtreg -noreport -agentvm -verbose:nopass,fail,error -vmoption:-enablesystemassertions -automatic -ignore:quiet -compilejdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk -testjdk:/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk java/lang/ModuleTests/addXXX/Driver.java -------------------------------------------------- TEST: java/lang/ModuleTests/addXXX/Driver.java TEST JDK: /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk ACTION: build -- Passed. Build successful REASON: User specified action: run build test/* m1/* m2/* m3/* m4/* TIME: 1.481 seconds messages: command: build test/* m1/* m2/* m3/* m4/* reason: User specified action: run build test/* m1/* m2/* m3/* m4/* Test directory: compile: test/module-info, test/test.C, test/test.Service, test/test.Main, m1/module-info, m1/p1.C, m2/module-info, m2/p2.C, m2/p2.internal.C, m3/module-info, m3/p3.C, m4/module-info, m4/p4.C elapsed time (seconds): 1.481 ACTION: compile -- Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 1.477 seconds messages: command: compile /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Service.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Main.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/p1/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/internal/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/p3/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/p4/C.java reason: .class file out of date or does not exist Mode: agentvm Agent id: 0 elapsed time (seconds): 1.477 configuration: Boot Layer (javac runtime environment) class path: /home/martin/jtreg-binaries/4.2-b08/lib/javatest.jar /home/martin/jtreg-binaries/4.2-b08/lib/jtreg.jar patch: java.base /home/martin/ws/jdk10/jdk/test/JTwork/patches/java.base javac compilation environment add modules: testng jcommander module path: /home/martin/ws/jdk10/jdk/test/JTwork/modules rerun: DISPLAY=localhost:10.0 \ HOME=/home/martin \ LANG=en_US.UTF-8 \ PATH=/bin:/usr/bin \ /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/javac \ -J-enablesystemassertions \ -J-Dtest.class.path.prefix=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -J-Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -J-Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -J-Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -J-Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -J-Dtest.vm.opts=-enablesystemassertions \ -J-Dtest.tool.vm.opts=-J-enablesystemassertions \ -J-Dtest.compiler.opts= \ -J-Dtest.java.opts= \ -J-Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -J-Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -J-Dtest.timeout.factor=1.0 \ -d /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules \ --module-source-path /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ --module-path /home/martin/ws/jdk10/jdk/test/JTwork/modules \ --add-modules testng,jcommander /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Service.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/test/test/Main.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/p1/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/p2/internal/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/p3/C.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/module-info.java /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/p4/C.java direct: /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m1/module-info.java:23: warning: [module] module name component m1 should avoid terminal digits module m1 { ^ /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m2/module-info.java:23: warning: [module] module name component m2 should avoid terminal digits module m2 { ^ /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m3/module-info.java:23: warning: [module] module name component m3 should avoid terminal digits module m3 { ^ /home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX/m4/module-info.java:23: warning: [module] module name component m4 should avoid terminal digits module m4 { ^ 4 warnings ACTION: build -- Passed. All files up to date REASON: Named class compiled on demand TIME: 0.0 seconds messages: command: build test/test.Main reason: Named class compiled on demand elapsed time (seconds): 0.0 ACTION: testng -- Failed. Unexpected exit from test [exit code: 1] REASON: User specified action: run testng/othervm test/test.Main TIME: 0.215 seconds messages: command: testng test/test.Main reason: User specified action: run testng/othervm test/test.Main Mode: othervm [/othervm specified] elapsed time (seconds): 0.215 configuration: Boot Layer add modules: test m4 m2 m3 m1 module path: /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules STDOUT: Error occurred during initialization of boot layer java.lang.module.FindException: Module testng not found, required by test STDERR: rerun: DISPLAY=localhost:10.0 \ HOME=/home/martin \ LANG=en_US.UTF-8 \ PATH=/bin:/usr/bin \ CLASSPATH=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX:/home/martin/jtreg-binaries/4.2-b08/lib/testng.jar:/home/martin/jtreg-binaries/4.2-b08/lib/jcommander.jar:/home/martin/jtreg-binaries/4.2-b08/lib/javatest.jar:/home/martin/jtreg-binaries/4.2-b08/lib/jtreg.jar \ /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/java \ -Dtest.class.path.prefix=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -Dtest.vm.opts=-enablesystemassertions \ -Dtest.tool.vm.opts=-J-enablesystemassertions \ -Dtest.compiler.opts= \ -Dtest.java.opts= \ -Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -Dtest.timeout.factor=1.0 \ --module-path /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules \ --add-modules test,m4,m2,m3,m1 \ -enablesystemassertions \ com.sun.javatest.regtest.agent.MainWrapper /home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/testng.0.jta java/lang/ModuleTests/addXXX/Driver.java false test/test.Main TEST RESULT: Failed. Unexpected exit from test [exit code: 1] From mandy.chung at oracle.com Tue Aug 22 23:28:02 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 22 Aug 2017 16:28:02 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: Message-ID: <668c1dee-0c08-6940-a7de-6816de095e63@oracle.com> On 8/22/17 3:52 PM, Martin Buchholz wrote: > : > > ACTION: testng -- Failed. Unexpected exit from test [exit code: 1] > REASON: User specified action: run testng/othervm test/test.Main > TIME: ? 0.215 seconds > messages: > command: testng test/test.Main > reason: User specified action: run testng/othervm test/test.Main > Mode: othervm [/othervm specified] > elapsed time (seconds): 0.215 > configuration: > Boot Layer > ? add modules: test m4 m2 m3 m1 > ? module path: > /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules > > STDOUT: > Error occurred during initialization of boot layer > java.lang.module.FindException: Module testng not found, required by test > STDERR: > rerun: > DISPLAY=localhost:10.0 \ > HOME=/home/martin \ > LANG=en_US.UTF-8 \ > PATH=/bin:/usr/bin \ > CLASSPATH=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX:/home/martin/jtreg-binaries/4.2-b08/lib/testng.jar:/home/martin/jtreg-binaries/4.2-b08/lib/jcommander.jar:/home/martin/jtreg-binaries/4.2-b08/lib/javatest.jar:/home/martin/jtreg-binaries/4.2-b08/lib/jtreg.jar > \ > /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/java > \ > -Dtest.class.path.prefix=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX > \ > -Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ > -Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX > \ > -Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d > \ > -Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d > \ > -Dtest.vm.opts=-enablesystemassertions \ > -Dtest.tool.vm.opts=-J-enablesystemassertions \ > ? ? ? ? -Dtest.compiler.opts= \ > ? ? ? ? -Dtest.java.opts= \ > -Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk > \ > -Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk > \ > ? ? ? ? -Dtest.timeout.factor=1.0 \ > ? ? ? ? --module-path > /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules > \ ====> /home/martin/ws/jdk10/jdk/test/JTwork/modules is not in the module path.? Therefore testng is not found. I can't reproduce this error.? I downloaded testng 6.9.9 and it works for me.? This is the jtreg version I used. $ jtreg -version jtreg, version 4.2 fcs b08 Installed in /java/devtools/jtreg/jtreg-4.2/lib/jtreg.jar Running on platform version 9 from /java/re/jdk-9.jdk/Contents/Home. Built with Java(TM) 2 SDK, Version 1.7.0-b147 on July 21, 2017. Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. JCov 2.0-b18 beta TestNG (testng.jar): version 6.9.9 TestNG (jcommander.jar): version 1.72 Mandy > ? ? ? ? --add-modules test,m4,m2,m3,m1 \ > ? ? ? ? -enablesystemassertions \ > com.sun.javatest.regtest.agent.MainWrapper > /home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/testng.0.jta > java/lang/ModuleTests/addXXX/Driver.java false test/test.Main > > TEST RESULT: Failed. Unexpected exit from test [exit code: 1] From martinrb at google.com Wed Aug 23 01:18:52 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Aug 2017 18:18:52 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: <668c1dee-0c08-6940-a7de-6816de095e63@oracle.com> References: <668c1dee-0c08-6940-a7de-6816de095e63@oracle.com> Message-ID: I also tried upgrading jcommander.jar to 1.72 from 1.48, but get the same error. Debugging hints? On Tue, Aug 22, 2017 at 4:28 PM, mandy chung wrote: > > On 8/22/17 3:52 PM, Martin Buchholz wrote: > > : > > > ACTION: testng -- Failed. Unexpected exit from test [exit code: 1] > REASON: User specified action: run testng/othervm test/test.Main > TIME: 0.215 seconds > messages: > command: testng test/test.Main > reason: User specified action: run testng/othervm test/test.Main > Mode: othervm [/othervm specified] > elapsed time (seconds): 0.215 > configuration: > Boot Layer > add modules: test m4 m2 m3 m1 > module path: /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ > ModuleTests/addXXX/Driver.d/modules > > STDOUT: > Error occurred during initialization of boot layer > java.lang.module.FindException: Module testng not found, required by test > STDERR: > rerun: > DISPLAY=localhost:10.0 \ > HOME=/home/martin \ > LANG=en_US.UTF-8 \ > PATH=/bin:/usr/bin \ > CLASSPATH=/home/martin/ws/jdk10/jdk/test/JTwork/classes/ > java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/ > jdk10/jdk/test/java/lang/ModuleTests/addXXX:/home/ > martin/jtreg-binaries/4.2-b08/lib/testng.jar:/home/martin/ > jtreg-binaries/4.2-b08/lib/jcommander.jar:/home/martin/ > jtreg-binaries/4.2-b08/lib/javatest.jar:/home/martin/ > jtreg-binaries/4.2-b08/lib/jtreg.jar \ > /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/java > \ > -Dtest.class.path.prefix=/home/martin/ws/jdk10/jdk/test/ > JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/ > home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ > -Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX > \ > -Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX > \ > -Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/ > classes/java/lang/ModuleTests/addXXX/Driver.d \ > -Dtest.class.path=/home/martin/ws/jdk10/jdk/test/ > JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ > -Dtest.vm.opts=-enablesystemassertions \ > -Dtest.tool.vm.opts=-J-enablesystemassertions \ > -Dtest.compiler.opts= \ > -Dtest.java.opts= \ > -Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64- > normal-server-release/images/jdk \ > -Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64- > normal-server-release/images/jdk \ > -Dtest.timeout.factor=1.0 \ > --module-path /home/martin/ws/jdk10/jdk/ > test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules \ > > > ====> /home/martin/ws/jdk10/jdk/test/JTwork/modules is not in the module > path. Therefore testng is not found. > > I can't reproduce this error. I downloaded testng 6.9.9 and it works for > me. This is the jtreg version I used. > > $ jtreg -version > jtreg, version 4.2 fcs b08 > Installed in /java/devtools/jtreg/jtreg-4.2/lib/jtreg.jar > Running on platform version 9 from /java/re/jdk-9.jdk/Contents/Home. > Built with Java(TM) 2 SDK, Version 1.7.0-b147 on July 21, 2017. > Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights > reserved. > Use is subject to license terms. > JCov 2.0-b18 beta > TestNG (testng.jar): version 6.9.9 > TestNG (jcommander.jar): version 1.72 > > > Mandy > > --add-modules test,m4,m2,m3,m1 \ > -enablesystemassertions \ > com.sun.javatest.regtest.agent.MainWrapper > /home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ > ModuleTests/addXXX/Driver.d/testng.0.jta java/lang/ModuleTests/addXXX/Driver.java > false test/test.Main > > TEST RESULT: Failed. Unexpected exit from test [exit code: 1] > > > From mandy.chung at oracle.com Wed Aug 23 01:48:51 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 22 Aug 2017 18:48:51 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: <668c1dee-0c08-6940-a7de-6816de095e63@oracle.com> Message-ID: The error message is clear because testng is not found from the module path. Error occurred during initialization of boot layer java.lang.module.FindException: Module testng not found, required by test If you edit the rerun command from jtr file to add JTwork/modules to module path as follows: --module-path /home/martin/ws/jdk10/jdk/ test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules:/home/martin/ws/jdk10/jdk/ test/JTwork/modules If it runs successfully, then the question is why jtreg includes JTwork/modules in javac --module-path but not at run time in your local run but my local jtreg works fine.? Jon may have jtreg debugging tip. Mandy On 8/22/17 6:18 PM, Martin Buchholz wrote: > I also tried upgrading jcommander.jar to 1.72 from 1.48, but get the > same error. > Debugging hints? > > > On Tue, Aug 22, 2017 at 4:28 PM, mandy chung > wrote: > > > On 8/22/17 3:52 PM, Martin Buchholz wrote: >> : >> >> >> ACTION: testng -- Failed. Unexpected exit from test [exit code: 1] >> REASON: User specified action: run testng/othervm test/test.Main >> TIME: ? 0.215 seconds >> messages: >> command: testng test/test.Main >> reason: User specified action: run testng/othervm test/test.Main >> Mode: othervm [/othervm specified] >> elapsed time (seconds): 0.215 >> configuration: >> Boot Layer >> ? add modules: test m4 m2 m3 m1 >> ? module path: >> /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules >> >> STDOUT: >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Module testng not found, required >> by test >> STDERR: >> rerun: >> DISPLAY=localhost:10.0 \ >> HOME=/home/martin \ >> LANG=en_US.UTF-8 \ >> PATH=/bin:/usr/bin \ >> CLASSPATH=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX:/home/martin/jtreg-binaries/4.2-b08/lib/testng.jar:/home/martin/jtreg-binaries/4.2-b08/lib/jcommander.jar:/home/martin/jtreg-binaries/4.2-b08/lib/javatest.jar:/home/martin/jtreg-binaries/4.2-b08/lib/jtreg.jar >> \ >> /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/java >> \ >> -Dtest.class.path.prefix=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX >> \ >> -Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX >> \ >> -Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX >> \ >> -Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d >> \ >> -Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d >> \ >> -Dtest.vm.opts=-enablesystemassertions \ >> -Dtest.tool.vm.opts=-J-enablesystemassertions \ >> -Dtest.compiler.opts= \ >> -Dtest.java.opts= \ >> -Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> \ >> -Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> \ >> -Dtest.timeout.factor=1.0 \ >> ? ? ? ? --module-path >> /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules >> \ > > ====> /home/martin/ws/jdk10/jdk/test/JTwork/modules is not in the > module path.? Therefore testng is not found. > > I can't reproduce this error.? I downloaded testng 6.9.9 and it > works for me.? This is the jtreg version I used. > > $ jtreg -version > jtreg, version 4.2 fcs b08 > Installed in /java/devtools/jtreg/jtreg-4.2/lib/jtreg.jar > Running on platform version 9 from /java/re/jdk-9.jdk/Contents/Home. > Built with Java(TM) 2 SDK, Version 1.7.0-b147 on July 21, 2017. > Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights > reserved. > Use is subject to license terms. > JCov 2.0-b18 beta > TestNG (testng.jar): version 6.9.9 > TestNG (jcommander.jar): version 1.72 > > > Mandy >> ? ? ? ? --add-modules test,m4,m2,m3,m1 \ >> -enablesystemassertions \ >> com.sun.javatest.regtest.agent.MainWrapper >> /home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/testng.0.jta >> java/lang/ModuleTests/addXXX/Driver.java false test/test.Main >> >> TEST RESULT: Failed. Unexpected exit from test [exit code: 1] > > From martinrb at google.com Wed Aug 23 02:26:03 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Aug 2017 19:26:03 -0700 Subject: """error: module testng reads package test from both test and testng""" In-Reply-To: References: <668c1dee-0c08-6940-a7de-6816de095e63@oracle.com> Message-ID: Indeed, when I rerun the command with your suggested module-path, it works (I had never used "rerun" before). So why does my jtreg not make these modules available at runtime? This is a fairly ordinary Ubuntu 14.4 system. $ DISPLAY=localhost:10.0 \ HOME=/home/martin \ LANG=en_US.UTF-8 \ PATH=/bin:/usr/bin \ CLASSPATH=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX:/home/martin/jtreg-binaries/4.2-b08-testng-6.9.9/lib/testng.jar:/home/martin/jtreg-binaries/4.2-b08-testng-6.9.9/lib/jcommander.jar:/home/martin/jtreg-binaries/4.2-b08-testng-6.9.9/lib/javatest.jar:/home/martin/jtreg-binaries/4.2-b08-testng-6.9.9/lib/jtreg.jar \ /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/java \ -Dtest.class.path.prefix=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ -Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d \ -Dtest.vm.opts=-enablesystemassertions \ -Dtest.tool.vm.opts=-J-enablesystemassertions \ -Dtest.compiler.opts= \ -Dtest.java.opts= \ -Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk \ -Dtest.timeout.factor=1.0 \ --module-path /home/martin/ws/jdk10/jdk/test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules:"/home/martin/ws/jdk10/jdk/test/JTwork/modules" \ --add-modules test,m4,m2,m3,m1 \ -enablesystemassertions \ com.sun.javatest.regtest.agent.MainWrapper /home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/testng.0.jta java/lang/ModuleTests/addXXX/Driver.java false test/test.Main [TestNG] Running: java/lang/ModuleTests/addXXX/Driver.java test test.Main.testAddExports(): success test test.Main.testAddOpens(): success test test.Main.testAddReads(): success test test.Main.testAddUses(): success =============================================== java/lang/ModuleTests/addXXX/Driver.java Total tests run: 4, Failures: 0, Skips: 0 =============================================== STATUS:Passed. On Tue, Aug 22, 2017 at 6:48 PM, mandy chung wrote: > The error message is clear because testng is not found from the module > path. > > Error occurred during initialization of boot layer > java.lang.module.FindException: Module testng not found, required by test > > If you edit the rerun command from jtr file to add JTwork/modules to > module path as follows: > > --module-path /home/martin/ws/jdk10/jdk/ > test/JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/mo > dules:/home/martin/ws/jdk10/jdk/ > test/JTwork/modules > > If it runs successfully, then the question is why jtreg includes > JTwork/modules in javac --module-path but not at run time in your local run > but my local jtreg works fine. Jon may have jtreg debugging tip. > > Mandy > > On 8/22/17 6:18 PM, Martin Buchholz wrote: > > I also tried upgrading jcommander.jar to 1.72 from 1.48, but get the same > error. > Debugging hints? > > > On Tue, Aug 22, 2017 at 4:28 PM, mandy chung > wrote: > >> >> On 8/22/17 3:52 PM, Martin Buchholz wrote: >> >> : >> >> >> ACTION: testng -- Failed. Unexpected exit from test [exit code: 1] >> REASON: User specified action: run testng/othervm test/test.Main >> TIME: 0.215 seconds >> messages: >> command: testng test/test.Main >> reason: User specified action: run testng/othervm test/test.Main >> Mode: othervm [/othervm specified] >> elapsed time (seconds): 0.215 >> configuration: >> Boot Layer >> add modules: test m4 m2 m3 m1 >> module path: /home/martin/ws/jdk10/jdk/test >> /JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules >> >> STDOUT: >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Module testng not found, required by test >> STDERR: >> rerun: >> DISPLAY=localhost:10.0 \ >> HOME=/home/martin \ >> LANG=en_US.UTF-8 \ >> PATH=/bin:/usr/bin \ >> CLASSPATH=/home/martin/ws/jdk10/jdk/test/JTwork/classes/java >> /lang/ModuleTests/addXXX/Driver.d:/home/martin/ws/jdk10/jdk/ >> test/java/lang/ModuleTests/addXXX:/home/martin/jtreg- >> binaries/4.2-b08/lib/testng.jar:/home/martin/jtreg- >> binaries/4.2-b08/lib/jcommander.jar:/home/martin/jtreg- >> binaries/4.2-b08/lib/javatest.jar:/home/martin/jtreg-binaries/4.2-b08/lib/jtreg.jar >> \ >> /home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk/bin/java >> \ >> -Dtest.class.path.prefix=/home/martin/ws/jdk10/jdk/test/JTwo >> rk/classes/java/lang/ModuleTests/addXXX/Driver.d:/home/ >> martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX \ >> -Dtest.src=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX >> \ >> -Dtest.src.path=/home/martin/ws/jdk10/jdk/test/java/lang/ModuleTests/addXXX >> \ >> -Dtest.classes=/home/martin/ws/jdk10/jdk/test/JTwork/classes >> /java/lang/ModuleTests/addXXX/Driver.d \ >> -Dtest.class.path=/home/martin/ws/jdk10/jdk/test/JTwork/ >> classes/java/lang/ModuleTests/addXXX/Driver.d \ >> -Dtest.vm.opts=-enablesystemassertions \ >> -Dtest.tool.vm.opts=-J-enablesystemassertions \ >> -Dtest.compiler.opts= \ >> -Dtest.java.opts= \ >> -Dtest.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> \ >> -Dcompile.jdk=/home/martin/ws/jdk10/build/linux-x86_64-normal-server-release/images/jdk >> \ >> -Dtest.timeout.factor=1.0 \ >> --module-path /home/martin/ws/jdk10/jdk/test >> /JTwork/classes/java/lang/ModuleTests/addXXX/Driver.d/modules \ >> >> >> ====> /home/martin/ws/jdk10/jdk/test/JTwork/modules is not in the module >> path. Therefore testng is not found. >> >> I can't reproduce this error. I downloaded testng 6.9.9 and it works for >> me. This is the jtreg version I used. >> >> $ jtreg -version >> jtreg, version 4.2 fcs b08 >> Installed in /java/devtools/jtreg/jtreg-4.2/lib/jtreg.jar >> Running on platform version 9 from /java/re/jdk-9.jdk/Contents/Home. >> Built with Java(TM) 2 SDK, Version 1.7.0-b147 on July 21, 2017. >> Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights >> reserved. >> Use is subject to license terms. >> JCov 2.0-b18 beta >> TestNG (testng.jar): version 6.9.9 >> TestNG (jcommander.jar): version 1.72 >> >> >> Mandy >> >> --add-modules test,m4,m2,m3,m1 \ >> -enablesystemassertions \ >> com.sun.javatest.regtest.agent.MainWrapper >> /home/martin/ws/jdk10/jdk/test/JTwork/java/lang/ModuleTests/addXXX/Driver.d/testng.0.jta >> java/lang/ModuleTests/addXXX/Driver.java false test/test.Main >> >> TEST RESULT: Failed. Unexpected exit from test [exit code: 1] >> >> >> > > From Alan.Bateman at oracle.com Wed Aug 23 05:37:56 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Aug 2017 06:37:56 +0100 Subject: Allow ModuleInfoExtender to be used externally In-Reply-To: <4FFA34B6-619E-474A-B382-861C37F4A029@siegmar.de> References: <4FFA34B6-619E-474A-B382-861C37F4A029@siegmar.de> Message-ID: <25c4dbf8-a9a6-fdf5-1978-fe5b917e9bfb@oracle.com> On 10/08/2017 08:29, Oliver Siegmar wrote: >> On 8/9/17 7:35 PM, mandy chung wrote: >> ModuleInfoExtender is JDK internal API and not planned to be exported/opened. New version of ASM supports module-info.class. You can probably try out ASM 6 alpha version for now. > Thank you for clarifying. So, an external library (ASM) is required to build modularized Jar files ? the JDK offers no built-in support for that (except the JAR command line tool). I?m very surprised as I think it is JDKs job to offer this functionality to 3rd party tools (as it does it with the compiler and other aspects of building and packaging Java applications). > > One thing to point out is that the jar tool CLI is a documented/supported interface so you can use the j.u.spi.ToolProvider API to find the "jar" tool and invoke it with the documented/supported options. That provides another way to build or update modular JARs without needing to use the j.u.jar API. -Alan From Alan.Bateman at oracle.com Wed Aug 23 05:45:26 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Aug 2017 06:45:26 +0100 Subject: Jigsaw related questions emerged during Java 9 Jigsaw Hack Day In-Reply-To: References: Message-ID: On 14/08/2017 09:35, Oleg Tsal-Tsalko wrote: > 2. Why compilation doesn?t fail in case several modules with same name > put on module-path, but it only fails in runtime on startup ( > https://github.com/AdoptOpenJDK/jdk9-jigsaw/tree/master/session-1-jigsaw-intro/08_ModulesExportConflict > )? Just to Alex's comment on this point. The behavior you observe is specific to exploded modules. If the module path is a directory of two JAR files containing modules of the same name then javac will detect the duplicate as you would expect. > 4. If there are 3 conflicting modules in module path error says only > about 2 first modules conflict only. Why that? Fail fast? The java launcher has a `--validate-modules` options which can be useful to report all potential errors without failing fast. It's particularly useful when starting out with a module path that has a lot of automatic modules that may have conflicting packages and other issues. -Alan From Alan.Bateman at oracle.com Wed Aug 23 05:49:39 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Aug 2017 06:49:39 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> Message-ID: <4eefe38e-67d3-7e6d-1185-674814ca551a@oracle.com> On 16/08/2017 02:09, Russell Gold wrote: > : > > but: > > method.getDeclaringClass().getModule().isOpen("java.io", callingClass.getModule()) > -> true // which seems to say that it IS open to that particular unnamed module ?! > > As Mandy points out, isOpen(String) is used to test if a package is open to all modules. In the example,? java.io is open to all unnamed modules but is not open to all modules. Is the context CORBA and IIOP deserialization? I'm curious what is interesting in java.io that isn't provided by the updated ReflectionFactory API. As you know, the JDK's java.corba module was updated to use this and so avoids depending on java.io internals. -Alan From mandy.chung at oracle.com Thu Aug 24 18:05:07 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 24 Aug 2017 11:05:07 -0700 Subject: Review Request: JDK-8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI Message-ID: <6f77b7a7-675f-a7fb-ec09-3261593b786a@oracle.com> java --validate-modules requires only java.base to do the validation and hence the current implementation creates a minimum boot layer with java.base only.? It fails when running with -XX:+EnableJVMCI when VM attempts to load JVMCI class which is not in the boot layer.? This patch changes the minimal boot layer to resolve all system modules that should get --validate-modules to work with some VM options that add some module at runtime. Webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186145/webrev.00/ Mandy From Alan.Bateman at oracle.com Thu Aug 24 18:21:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Aug 2017 19:21:10 +0100 Subject: Review Request: JDK-8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI In-Reply-To: <6f77b7a7-675f-a7fb-ec09-3261593b786a@oracle.com> References: <6f77b7a7-675f-a7fb-ec09-3261593b786a@oracle.com> Message-ID: <757b11b1-2e40-2f83-86c4-d8aee9e0f5af@oracle.com> On 24/08/2017 19:05, mandy chung wrote: > java --validate-modules requires only java.base to do the validation > and hence the current implementation creates a minimum boot layer with > java.base only.? It fails when running with -XX:+EnableJVMCI when VM > attempts to load JVMCI class which is not in the boot layer.? This > patch changes the minimal boot layer to resolve all system modules > that should get --validate-modules to work with some VM options that > add some module at runtime. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186145/webrev.00/ Looks okay except L218 where the comment needs to be updated to say that it starts without an application module path. I also wonder if a test is possible, it could use "@requires vm.jvmci" so that it only runs when that capability is present. -Alan From mandy.chung at oracle.com Thu Aug 24 23:36:04 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 24 Aug 2017 16:36:04 -0700 Subject: Review Request: JDK-8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI In-Reply-To: <757b11b1-2e40-2f83-86c4-d8aee9e0f5af@oracle.com> References: <6f77b7a7-675f-a7fb-ec09-3261593b786a@oracle.com> <757b11b1-2e40-2f83-86c4-d8aee9e0f5af@oracle.com> Message-ID: <12350493-1eb5-e0dc-1bdb-e40ac0a63c70@oracle.com> On 8/24/17 11:21 AM, Alan Bateman wrote: > On 24/08/2017 19:05, mandy chung wrote: >> java --validate-modules requires only java.base to do the validation >> and hence the current implementation creates a minimum boot layer >> with java.base only.? It fails when running with -XX:+EnableJVMCI >> when VM attempts to load JVMCI class which is not in the boot layer. >> This patch changes the minimal boot layer to resolve all system >> modules that should get --validate-modules to work with some VM >> options that add some module at runtime. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186145/webrev.00/ > Looks okay except L218 where the comment needs to be updated to say > that it starts without an application module path. > Good catch. > I also wonder if a test is possible, it could use "@requires vm.jvmci" > so that it only runs when that capability is present. That's a good idea.? I added a new test in hotspot/test/compiler/jvmci.? Updated webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186145/webrev.01/index.html I considered adding this in the jdk/test directory.? @requires vm.jvmci tightly couples with VM and also VM testlibrary and I am hesitated extending jdk/test/TEST.ROOT to set up for this test.? We can revisit this if there is a strong need to move this new test in the jdk/test directory. Mandy [1] http://hg.openjdk.java.net/jdk10/jdk10/file/90cdfe56f154/test/jtreg-ext/requires/VMProps.java From Alan.Bateman at oracle.com Fri Aug 25 07:21:56 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Aug 2017 08:21:56 +0100 Subject: Review Request: JDK-8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI In-Reply-To: <12350493-1eb5-e0dc-1bdb-e40ac0a63c70@oracle.com> References: <6f77b7a7-675f-a7fb-ec09-3261593b786a@oracle.com> <757b11b1-2e40-2f83-86c4-d8aee9e0f5af@oracle.com> <12350493-1eb5-e0dc-1bdb-e40ac0a63c70@oracle.com> Message-ID: <264bc539-da52-4330-bf2c-2dad1308498f@oracle.com> On 25/08/2017 00:36, mandy chung wrote: > : > > That's a good idea.? I added a new test in > hotspot/test/compiler/jvmci.? Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186145/webrev.01/index.html > > > I considered adding this in the jdk/test directory.? @requires > vm.jvmci tightly couples with VM and also VM testlibrary and I am > hesitated extending jdk/test/TEST.ROOT to set up for this test. We can > revisit this if there is a strong need to move this new test in the > jdk/test directory. > The updated webrev looks good. -Alan From russell.gold at oracle.com Sun Aug 27 04:00:50 2017 From: russell.gold at oracle.com (Russell Gold) Date: Sun, 27 Aug 2017 00:00:50 -0400 Subject: =?utf-8?Q?Re=3A_trySetAccessible=E2=80=8B?= In-Reply-To: <4eefe38e-67d3-7e6d-1185-674814ca551a@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> <4eefe38e-67d3-7e6d-1185-674814ca551a@oracle.com> Message-ID: > On Aug 23, 2017, at 1:49 AM, Alan Bateman wrote: > > On 16/08/2017 02:09, Russell Gold wrote: >> : >> >> but: >> >> method.getDeclaringClass().getModule().isOpen("java.io", callingClass.getModule()) >> -> true // which seems to say that it IS open to that particular unnamed module ?! >> >> > As Mandy points out, isOpen(String) is used to test if a package is open to all modules. In the example, java.io is open to all unnamed modules but is not open to all modules. When you say it is open to all unnamed modules, do you mean open with warnings? How do you declare a module open? I don?t see that in the current module documentation. Why is it only open to unnamed modules, and how can we detect that a warning would be given? Our goal is to avoid the manipulations that will result in warnings (and therefore be forbidden in future versions of Java). > Is the context CORBA and IIOP deserialization? I'm curious what is interesting in java.io that isn't provided by the updated ReflectionFactory API. As you know, the JDK's java.corba module was updated to use this and so avoids depending on java.io internals. This is not related to IIOP, but some proprietary deserialization, which was written using some rather nasty manipulations via reflection. The code in question allows us to detect that those tricks won?t work (without warnings), and gracefully degrade to an alternative, albeit slower, implementation. Because of the way it works, ReflectionFactory is insufficient. The goal is to recognize which reflection calls are likely to be permitted, and which are not. It is a step away from the current hack. In practice, it means that it works one way in JDK8 and a different way in JDK9 or later. From Alan.Bateman at oracle.com Sun Aug 27 20:07:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Aug 2017 21:07:22 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> <4eefe38e-67d3-7e6d-1185-674814ca551a@oracle.com> Message-ID: On 27/08/2017 05:00, Russell Gold wrote: > > When you say it is open to all unnamed modules, do you mean open with > warnings? How do you declare a module open? I don?t see that in the > current module documentation. Why is it only open to unnamed modules, > and how can we detect that a warning would be given? Our goal is to > avoid the manipulations that will result in warnings (and therefore be > forbidden in future versions of Java). The packages that existed in JDK 8 and still exist in JDK 9 are open to code on the class path (or more generally all unnamed) modules to allow existing bad code to continue to work. There is a detailed note in JDK 9 release notes [1] on this topic and there will be further details on this in the upcoming JDK 9 docs. There isn't any programmatic way to know in advance if a warning will be printed. It's easy to test if packages are open to only all unnamed modules but this isn't enough - the reason is that packages can be opened explicitly, via --add-opens`, and there won't be warnings there there an otherwise illegal access to a member of the packages opened this way. > > This is not related to IIOP, but some proprietary deserialization, > which was written using some rather nasty manipulations via > reflection. The code in question allows us to detect that those tricks > won?t work (without warnings), and gracefully degrade to an > alternative, albeit slower, implementation. Because of the way it > works, ReflectionFactory is insufficient. The goal is to recognize > which /reflection/ calls are likely to be permitted, and which are > not. It is a step away from the current hack. In practice, it means > that it works one way in JDK8 and a different way in JDK9 or later. Have you looked at using multi-release JARs? -Alan [1] http://jdk.java.net/9/release-notes From russell.gold at oracle.com Mon Aug 28 12:02:39 2017 From: russell.gold at oracle.com (Russell Gold) Date: Mon, 28 Aug 2017 08:02:39 -0400 Subject: =?utf-8?Q?Re=3A_trySetAccessible=E2=80=8B?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> <4eefe38e-67d3-7e6d-1185-674814ca551a@oracle.com> Message-ID: <6A84497E-0286-484A-8E09-7A052D21E4EA@oracle.com> > On Aug 27, 2017, at 4:07 PM, Alan Bateman wrote: > > On 27/08/2017 05:00, Russell Gold wrote: >> >> When you say it is open to all unnamed modules, do you mean open with warnings? How do you declare a module open? I don?t see that in the current module documentation. Why is it only open to unnamed modules, and how can we detect that a warning would be given? Our goal is to avoid the manipulations that will result in warnings (and therefore be forbidden in future versions of Java). > The packages that existed in JDK 8 and still exist in JDK 9 are open to code on the class path (or more generally all unnamed) modules to allow existing bad code to continue to work. There is a detailed note in JDK 9 release notes [1] on this topic and there will be further details on this in the upcoming JDK 9 docs. > > There isn't any programmatic way to know in advance if a warning will be printed. It's easy to test if packages are open to only all unnamed modules but this isn't enough - the reason is that packages can be opened explicitly, via --add-opens`, and there won't be warnings there there an otherwise illegal access to a member of the packages opened this way. That?s unfortunate; I had hoped that one of the real advantages of the warning system was to allow us to degrade gracefully, putting in code that would continue to work the old way in JDK8 but use new mechanisms only when required. > >> >> This is not related to IIOP, but some proprietary deserialization, which was written using some rather nasty manipulations via reflection. The code in question allows us to detect that those tricks won?t work (without warnings), and gracefully degrade to an alternative, albeit slower, implementation. Because of the way it works, ReflectionFactory is insufficient. The goal is to recognize which reflection calls are likely to be permitted, and which are not. It is a step away from the current hack. In practice, it means that it works one way in JDK8 and a different way in JDK9 or later. > Have you looked at using multi-release JARs? I?m using them where I can; the problem is that the tooling isn?t there, yet. I have found numerous temporary solutions, but none of them allow for unit testing against both the old and new code, and most run into compatibility issues with various plugins. I use a multi-release jar in PFL, and am trying to add one to SimpleStub, but the tooling gaps make it very painful; however, the lack of a runtime ability to detect bad accesses means that the advantage of MR jars is diminished in several use cases, and I will look into other approaches. Thanks, Russ From Alan.Bateman at oracle.com Mon Aug 28 13:28:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Aug 2017 14:28:53 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <6A84497E-0286-484A-8E09-7A052D21E4EA@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> <8C32FFD7-107E-4B9C-A067-AD1841CBB021@oracle.com> <4eefe38e-67d3-7e6d-1185-674814ca551a@oracle.com> <6A84497E-0286-484A-8E09-7A052D21E4EA@oracle.com> Message-ID: <9407b143-fd7d-ecf1-3fb7-a45d095e0948@oracle.com> On 28/08/2017 13:02, Russell Gold wrote: > > That?s unfortunate; I had hoped that one of the real advantages of the > warning system was to allow us to degrade gracefully, putting in code > that would continue to work the old way in JDK8 but use new mechanisms > only when required. The purpose of the warnings is to identify bad code that may need to be changed when access to JDK internals is eventually denied.? From your mails it sounds like you attempting to fix some issues (which is good) but the code is still runs when on JDK 9. > >> Have you looked at using multi-release JARs? > > > I?m using them where I can; the problem is that the tooling isn?t > there, yet. I have found numerous temporary solutions, but none of > them allow for unit testing against both the old and new code, If you mean that it's difficult to have several JDKs in the testing environment then I agree. One thing to look at is the jdk.util.jar.version and jdk.util.jar.enableMultiRelease properties (documented in the "Implementation Note" of JarFile) as that should allow you to use one JDK 9 build to exercise the code in different ways. -Alan From nipa at codefx.org Tue Aug 29 05:52:40 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Tue, 29 Aug 2017 07:52:40 +0200 Subject: Proper term for non-automatic modules Message-ID: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> Hi! While describing the difference between automatic and non-automatic modules I often need a term do describe the modules that are not automatic (as I did twice just now). As far as I know there is no such term. There are a few related ones but unless I missed something none describes quite the right set: * named modules include automatic modules * platform modules leave out user-created modules * application modules include automatic modules (if they don't, then `{ platform } ? { application }` is the right set) I think a term for `{ named } ? { automatic }` is important when discussing automatic modules and it would be very helpful if the Jigsaw team coins it. My suggestions are "explicit", "proper", and "manual" modules. so long ... Nicolai -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From Alan.Bateman at oracle.com Tue Aug 29 06:56:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Aug 2017 07:56:44 +0100 Subject: Proper term for non-automatic modules In-Reply-To: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> References: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> Message-ID: On 29/08/2017 06:52, Nicolai Parlog wrote: > Hi! > > While describing the difference between automatic and non-automatic > modules I often need a term do describe the modules that are not > automatic (as I did twice just now). > > As far as I know there is no such term. There are a few related ones but > unless I missed something none describes quite the right set: > > * named modules include automatic modules > * platform modules leave out user-created modules > * application modules include automatic modules > (if they don't, then `{ platform } ? { application }` is > the right set) > > I think a term for `{ named } ? { automatic }` is important when > discussing automatic modules and it would be very helpful if the Jigsaw > team coins it. > > My suggestions are "explicit", "proper", and "manual" modules. > We've been using term "explicit".? You'll see it used in the ModuleFinder.of(Path...) spec for example where it describes a modular JAR as defining an explicit module. -Alan. From sander.mak at luminis.eu Tue Aug 29 06:57:50 2017 From: sander.mak at luminis.eu (Sander Mak) Date: Tue, 29 Aug 2017 06:57:50 +0000 Subject: Proper term for non-automatic modules In-Reply-To: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> References: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> Message-ID: <5D078623-6258-44BD-A80D-4F2DD0A07422@luminis.eu> Hi Nicolai, > On 29 Aug 2017, at 07:52, Nicolai Parlog wrote: > While describing the difference between automatic and non-automatic > modules I often need a term do describe the modules that are not > automatic (as I did twice just now). > > As far as I know there is no such term. We noticed the same issue while going through the copy-edit phase for our manuscript. Ultimately we settled on using the 'nonautomatic' adjective when it's important to stress the difference with automatic modules. A 'proper' may have snuck in at some places as well. Naming things still is hard... Sander From nipa at codefx.org Tue Aug 29 09:23:00 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Tue, 29 Aug 2017 11:23:00 +0200 Subject: Proper term for non-automatic modules In-Reply-To: <5D078623-6258-44BD-A80D-4F2DD0A07422@luminis.eu> References: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> <5D078623-6258-44BD-A80D-4F2DD0A07422@luminis.eu> Message-ID: <0ee70c31-dc24-657e-3cad-96537a1eee94@codefx.org> Hi Sander, I keep calling them "proper" as well, but when using that a lot in one chapter I git sick of it. ;) so long ... Nicolai On 29.08.2017 08:57, Sander Mak wrote: > Hi Nicolai, > >> On 29 Aug 2017, at 07:52, Nicolai Parlog >> wrote: > >> While describing the difference between automatic and >> non-automatic modules I often need a term do describe the modules >> that are not automatic (as I did twice just now). >> >> As far as I know there is no such term. > > We noticed the same issue while going through the copy-edit phase > for our manuscript. Ultimately we settled on using the > 'nonautomatic' adjective when it's important to stress the > difference with automatic modules. A 'proper' may have snuck in at > some places as well. Naming things still is hard... > > > Sander > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From nipa at codefx.org Tue Aug 29 09:24:13 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Tue, 29 Aug 2017 11:24:13 +0200 Subject: Proper term for non-automatic modules In-Reply-To: References: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> Message-ID: <3855f52b-82f5-20d7-cc28-586b451dccd2@codefx.org> Hi Alan, thanks for your quick answer. I shall use "explicit", then. :) so long ... Nicolai On 29.08.2017 08:56, Alan Bateman wrote: > > > On 29/08/2017 06:52, Nicolai Parlog wrote: >> Hi! >> >> While describing the difference between automatic and non-automatic >> modules I often need a term do describe the modules that are not >> automatic (as I did twice just now). >> >> As far as I know there is no such term. There are a few related ones but >> unless I missed something none describes quite the right set: >> >> * named modules include automatic modules >> * platform modules leave out user-created modules >> * application modules include automatic modules >> (if they don't, then `{ platform } ? { application }` is >> the right set) >> >> I think a term for `{ named } ? { automatic }` is important when >> discussing automatic modules and it would be very helpful if the Jigsaw >> team coins it. >> >> My suggestions are "explicit", "proper", and "manual" modules. >> > We've been using term "explicit". You'll see it used in the > ModuleFinder.of(Path...) spec for example where it describes a modular > JAR as defining an explicit module. > > -Alan. > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From mark.reinhold at oracle.com Tue Aug 29 15:10:15 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 29 Aug 2017 08:10:15 -0700 Subject: Proper term for non-automatic modules In-Reply-To: References: <42e87572-d043-d6a6-8146-9018efa4215d@codefx.org> Message-ID: <20170829081015.126564283@eggemoggin.niobe.net> 2017/8/28 23:56:44 -0700, alan.bateman at oracle.com: > ... > > We've been using term "explicit". You'll see it used in the > ModuleFinder.of(Path...) spec for example where it describes a modular > JAR as defining an explicit module. Yes -- "explicit" is the appropriate term here. We've used it not only in the API spec but in the JLS, SotMS, and most of our presentations. I'd avoid "nonautomatic" -- it's not incorrect, but it's a negative definition and therefore harder for a newcomer to grasp. - Mark From nipa at codefx.org Wed Aug 30 10:33:06 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Wed, 30 Aug 2017 12:33:06 +0200 Subject: Automatic module resolution Message-ID: <5e5be5a6-002e-c9ca-a04f-54166e75e46a@codefx.org> Hi! In a year-old comment on StackOverflow[1] Mark Reinhold wrote: > If one automatic module depends upon another automatic module > (i.e., both are on the module path but only the first is required > by an explicit module) then you can cause the second automatic > module to be loaded via the `--add-modules` option. Experiments show that is became unnecessary and once one automatic module gets loaded, so do all others. I couldn't find any references to this in a cursory search of the SotMS and this mailing list - can aynone link to a discussion on this? so long ... Nicolai [1] https://stackoverflow.com/q/38269630/2525313?noredirect=1#comment64036158_38274483 -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From Alan.Bateman at oracle.com Wed Aug 30 10:58:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Aug 2017 11:58:25 +0100 Subject: Automatic module resolution In-Reply-To: <5e5be5a6-002e-c9ca-a04f-54166e75e46a@codefx.org> References: <5e5be5a6-002e-c9ca-a04f-54166e75e46a@codefx.org> Message-ID: <9efbccc8-b4a9-b3f3-bd59-6200271e8e6c@oracle.com> On 30/08/2017 11:33, Nicolai Parlog wrote: > : > Experiments show that is became unnecessary and once one automatic > module gets loaded, so do all others. I couldn't find any references to > this in a cursory search of the SotMS and this mailing list - can aynone > link to a discussion on this? > Yes, this changed in the last year to make automatic modules easier to use.? In the resolution spec [1], look for "If at least one automatic module is enumerated ..." and it has the details. -Alan [1] http://download.java.net/java/jdk9/docs/api/java/lang/module/package-summary.html#resolution From nipa at codefx.org Thu Aug 31 06:43:47 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Thu, 31 Aug 2017 08:43:47 +0200 Subject: No subject Message-ID: <3d12ae67-c990-c0a6-125a-d0ed567343c7@codefx.org> Hi! I guess it's too late to change that now, but I find two of JDeps command line options have really unfortunate names: `--generate-module-info` * module-info is very colloquial, is this term used anywhere else? * it's singular, which is of course grammatically correct but _really_ weird - it generates many module declarations (infos?) after all `--generate-open-module` * this should definitely be plural * where did the "-info" go - is it not needed here? I think `--generate-modules`/`--generate-open-modules` would be nice and comparatively succinct. There is a slight discomfort because nobody is actually creating modules, so `--generate-module-declarations`/`--generate-open-module-declarations` would be more precise, but obviously much longer. so long ... Nicolai -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From daniel.latremoliere at gmail.com Thu Aug 31 17:58:55 2017 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Thu, 31 Aug 2017 19:58:55 +0200 Subject: Jigsaw and containers Message-ID: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> I have a problem to understand new layout of files in JRE/JDK images for the containers use-cases. Containers (Docker, Flatpak) have a notion of single inheritance, where an union FS merge the images of the container with parent containers. This give much smaller images of containers when most of the files are untouched and inherited from a common parent container. The layout of JRE/JDK images, with one big file "/lib/modules" taking most of the size, seems to be completely anti-modular and particularly bad for fast redeployment. Isn't it more modular and space-efficient to have not a file "/lib/modules" but a directory "/lib/modules/" where all available files, like "0", "1", etc. would be loaded. By example, an application suite can have a parent container with the Java standard library and common libraries of the application suite (creating a file "lib/modules/0" with the set of common modules). Each application would be a container inheriting common code from parent and with a file "lib/modules/1" with the own set of modules for the application. Daniel. From Alan.Bateman at oracle.com Thu Aug 31 18:35:15 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Aug 2017 19:35:15 +0100 Subject: Jigsaw and containers In-Reply-To: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> References: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> Message-ID: <2eca2846-c31d-9c66-760b-243eea444531@oracle.com> On 31/08/2017 18:58, Daniel Latr?moli?re wrote: > I have a problem to understand new layout of files in JRE/JDK images > for the containers use-cases. > > Containers (Docker, Flatpak) have a notion of single inheritance, > where an union FS merge the images of the container with parent > containers. This give much smaller images of containers when most of > the files are untouched and inherited from a common parent container. > > The layout of JRE/JDK images, with one big file "/lib/modules" taking > most of the size, seems to be completely anti-modular and particularly > bad for fast redeployment. Isn't it more modular and space-efficient > to have not a file "/lib/modules" but a directory "/lib/modules/" > where all available files, like "0", "1", etc. would be loaded. > > By example, an application suite can have a parent container with the > Java standard library and common libraries of the application suite > (creating a file "lib/modules/0" with the set of common modules). Each > application would be a container inheriting common code from parent > and with a file "lib/modules/1" with the own set of modules for the > application. > Are you using `jlink` to create a run-time image for each application? (just trying to establish if you are actually running into an issue or not). -Alan From mandy.chung at oracle.com Thu Aug 31 18:39:13 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 31 Aug 2017 11:39:13 -0700 Subject: In-Reply-To: <3d12ae67-c990-c0a6-125a-d0ed567343c7@codefx.org> References: <3d12ae67-c990-c0a6-125a-d0ed567343c7@codefx.org> Message-ID: <3d2e18d2-2e90-c301-c16e-bbd353bad48a@oracle.com> Hi Nicolai, The `--generate-module-info` and `--generate-open-module` options take an output directory argument and generates module-info.java (source file) in the output directory, one per each specified JAR file on the command-line. I agree that this is not ideal and `--generate-module-declarations` is a good option name.? Having a second thought, a better alternative might be to add --output option so that --generate-module-declarations could specify an optional argument `open`. We can introduce new option names in a future release. Mandy On 8/30/17 11:43 PM, Nicolai Parlog wrote: > Hi! > > I guess it's too late to change that now, but I find two of JDeps > command line options have really unfortunate names: > > `--generate-module-info` > > * module-info is very colloquial, is this term used anywhere else? > * it's singular, which is of course grammatically correct but > _really_ weird - it generates many module declarations (infos?) > after all > > `--generate-open-module` > > * this should definitely be plural > * where did the "-info" go - is it not needed here? > > I think `--generate-modules`/`--generate-open-modules` would be nice and > comparatively succinct. There is a slight discomfort because nobody is > actually creating modules, so > `--generate-module-declarations`/`--generate-open-module-declarations` > would be more precise, but obviously much longer. > > so long ... Nicolai > > > From daniel.latremoliere at gmail.com Thu Aug 31 18:47:35 2017 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Thu, 31 Aug 2017 20:47:35 +0200 Subject: Jigsaw and containers In-Reply-To: <2eca2846-c31d-9c66-760b-243eea444531@oracle.com> References: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> <2eca2846-c31d-9c66-760b-243eea444531@oracle.com> Message-ID: > Are you using `jlink` to create a run-time image for each application? > (just trying to establish if you are actually running into an issue or > not). With jlink per application, all will be working without problems, but each application will have his own copy of JRE and common libraries (big size). With jlink only for jre and common libraries, these parts can be shared between applications. But specific parts of each application will be only in JAR files (and not be modularized). These two choices works as reasonable targets, but no one is really completely good (big size or no full modularization). Daniel. From forax at univ-mlv.fr Thu Aug 31 19:14:24 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 31 Aug 2017 21:14:24 +0200 (CEST) Subject: Jigsaw and containers In-Reply-To: References: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> <2eca2846-c31d-9c66-760b-243eea444531@oracle.com> Message-ID: <57723896.1898851.1504206864547.JavaMail.zimbra@u-pem.fr> Hi Daniel, several points first, the JRE doesn't exist anymore apart for compatibility (the jre is just a bunch of modules) and a jar can be a modular jar, just have a module-info.class in the jar, so applications that uses jars can be modular, they do not have to use jlink. So you can have a jlink image as small as just java.base and all your applications and their dependencies as modular jars, the modules will be shared by the different applications, or a jlink all applications and have no sharing at all and all the states in between. R?mi ----- Mail original ----- > De: "Daniel Latr?moli?re" > ?: "Alan Bateman" , "jigsaw-dev" > Envoy?: Jeudi 31 Ao?t 2017 20:47:35 > Objet: Re: Jigsaw and containers >> Are you using `jlink` to create a run-time image for each application? >> (just trying to establish if you are actually running into an issue or >> not). > With jlink per application, all will be working without problems, but > each application will have his own copy of JRE and common libraries (big > size). > > With jlink only for jre and common libraries, these parts can be shared > between applications. But specific parts of each application will be > only in JAR files (and not be modularized). > > These two choices works as reasonable targets, but no one is really > completely good (big size or no full modularization). > > Daniel. From Alan.Bateman at oracle.com Thu Aug 31 19:31:29 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Aug 2017 20:31:29 +0100 Subject: Jigsaw and containers In-Reply-To: References: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> <2eca2846-c31d-9c66-760b-243eea444531@oracle.com> Message-ID: <705160b0-b4e2-5a55-7401-fa4d24ed977b@oracle.com> On 31/08/2017 19:47, Daniel Latr?moli?re wrote: > >> Are you using `jlink` to create a run-time image for each >> application? (just trying to establish if you are actually running >> into an issue or not). > With jlink per application, all will be working without problems, but > each application will have his own copy of JRE and common libraries > (big size). If you are using `jlink` then the resulting run-time image will only contain the modules that you specify to the tool and the modules that they recursively require. You should find that it's significantly smaller that the JDK and JRE downloads. > > With jlink only for jre and common libraries, these parts can be > shared between applications. But specific parts of each application > will be only in JAR files (and not be modularized). Modules can be packaged as JAR files too. You can even use most existing JAR files are modules. It does forfeit some of the benefits of creating your own run-time image but maybe that is the trade off that you are looking for. -Alan. From daniel.latremoliere at gmail.com Thu Aug 31 21:05:00 2017 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Thu, 31 Aug 2017 23:05:00 +0200 Subject: Jigsaw and containers In-Reply-To: <57723896.1898851.1504206864547.JavaMail.zimbra@u-pem.fr> References: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> <2eca2846-c31d-9c66-760b-243eea444531@oracle.com> <57723896.1898851.1504206864547.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, Alan I use already jlink to keep only useful (for me) parts of JRE/JDK, and avoid most big thinks (like Java UI, CORBA, RMI, etc). Modular JAR are officially for migration [1] and are not used by modules from OpenJDK, even when they are pure Java. If they are a definitive target, why isn't it in OpenJDK a tool to transform a JMOD in a modular jar (at least when it is pure Java bytecode)? As I understand jlink as an optimizer tool [2], I would try to use it for all modules and expect it to be able to do so. If I can not do it good, because they resulting image format is too much restricted, I will mitigate to have a less bad solution. My problem is that nothing in Jigsaw requires technically to store all modules of an image in a big single file, but new image format has made this choice. Having multiple files, each containing a set of modules would allow much more efficient trade-offs. This is particularly true for containers, and probably also in pure application suite (by making links to a jlink-optimized file containing a shared subset of modules). This is easy to be seen in containers, where the file system is usually the merge of multiples layers, like described in this image (from Docker [3]): https://docs.docker.com/engine/userguide/storagedriver/images/overlay_constructs.jpg Then having multiple files each with a specified set of modules allow some files to be shared between multiples containers. When we have all modules only in a single file, this file will never be the same between all containers and can never be shared. Then sharing common parts requires to convert non-shared modules in non-optimized modular JAR (blurring target of Jigsaw). I understand that it is too late for Java 9 to allow multiple files for modules in jlink-build images, each file storing a subset of the modules of the image (but I think it would be better if the current single file is already named "modules/0" and not "modules"). I would hope that it is not a definitive limitation of Java. Daniel. [1]: http://openjdk.java.net/projects/jigsaw/doc/topics/modularjar.html [2]: http://openjdk.java.net/jeps/282 [3]: https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ Le 31 ao?t 2017 21:14:24 GMT+02:00, Remi Forax a ?crit : >Hi Daniel, >several points first, >the JRE doesn't exist anymore apart for compatibility (the jre is just >a bunch of modules) and a jar can be a modular jar, just have a >module-info.class in the jar, so applications that uses jars can be >modular, they do not have to use jlink. > >So you can have a jlink image as small as just java.base and all your >applications and their dependencies as modular jars, the modules will >be shared by the different applications, or a jlink all applications >and have no sharing at all and all the states in between. > >R?mi > >---------- >Modules can be packaged as JAR files too. You can even use most >existing >JAR files are modules. It does forfeit some of the benefits of creating >your own run-time image but maybe that is the trade off that you are >looking for. > >-Alan. From david.holmes at oracle.com Thu Aug 31 21:36:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Sep 2017 07:36:23 +1000 Subject: wscompile issues In-Reply-To: <277ced79-f3d2-1ae3-1c5e-dfed8ed84d93@forgerock.com> References: <277ced79-f3d2-1ae3-1c5e-dfed8ed84d93@forgerock.com> Message-ID: <11dc4684-6447-7fb9-fbe8-1df6319c755c@oracle.com> Hi Peter, Moving this over to jigsaw-dev. David On 29/08/2017 3:45 PM, Peter Major wrote: > Hi, > > > I'm not quite sure if this is the right mailing list to ask, but I'm > wondering whether there is a bug in wscompile in the build 9+181 version. > > In a project of mine, I have a java ant task calling > com.sun.xml.rpc.tools.wscompile.Main directly to generate some classes, > however it seems like that although I can influence the --add-modules > parameter for the java process itself, when wscompile eventually will > try to compile the classes it generated, it will fail to specify > java.xml.ws module, and as such the compilation fails with something like: > > ???? [java] > /Users/aldaris/projects/foo/target/generated-sources/wscompile/com/mycompany/FooBar_Tie.java:91: > error: cannot access Detail > ???? [java]???????????????? e.getFaultString(), e.getFaultActor(), > e.getDetail()); > > [java]?????????????????????????????????????????????????????????????????? ^ > ???? [java]?? class file for javax.xml.soap.Detail not found > ???? [java] Note: Some input files use unchecked or unsafe operations. > ???? [java] Note: Recompile with -Xlint:unchecked for details. > ???? [java] 1 error > ???? [java] error: compilation failed, errors should have been reported > > > Is this a bug in the JDK or am I just missing something glaringly obvious? > > Thanks for your help. > > > Regards, > > Peter Major > From dalibor.topic at oracle.com Thu Aug 31 21:42:45 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 31 Aug 2017 23:42:45 +0200 Subject: Jigsaw and containers In-Reply-To: References: <5233a7b5-9afc-10ee-4ec6-c87b6390f472@gmail.com> <2eca2846-c31d-9c66-760b-243eea444531@oracle.com> <57723896.1898851.1504206864547.JavaMail.zimbra@u-pem.fr> Message-ID: <84cb453d-efb5-c923-1fd9-37184e9c564a@oracle.com> On 31.08.2017 23:05, Daniel Latr?moli?re wrote: > This is easy to be seen in containers, where the file system is usually the merge of multiples layers, like described in this image (from Docker [3]): > https://docs.docker.com/engine/userguide/storagedriver/images/overlay_constructs.jpg > Then having multiple files each with a specified set of modules allow some files to be shared between multiples containers. When we have all modules only in a single file, this file will never be the same between all containers and can never be shared. Then sharing common parts requires to convert non-shared modules in non-optimized modular JAR (blurring target of Jigsaw). I believe that this behavior can differ from storage driver to storage driver. OverlayFS works on the file level, while the storage drivers for ZFS, btrfs, devicemapper etc. seem to work on the block level. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment