From paul.bakker.nl at gmail.com Wed Oct 4 00:44:01 2017 From: paul.bakker.nl at gmail.com (Paul Bakker) Date: Tue, 3 Oct 2017 17:44:01 -0700 Subject: issue deriving automatic module name Message-ID: <31DAF693-79AC-4880-8243-F797A718F0EE@gmail.com> Hi, I ran into an issue testing some migration scenarios. When using jboss-transaction-api_1.2_spec-1.0.1.Final.jar as an automatic module, startup fails with: Caused by: java.lang.IllegalArgumentException: jboss.transaction.api.1.2.spec: Invalid module name: '1' is not a Java identifier This is clearly a strange JAR name, and can be fixed by providing a module name, but it should probably not prevent startup. Best, Paul From forax at univ-mlv.fr Wed Oct 4 07:18:06 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 Oct 2017 09:18:06 +0200 (CEST) Subject: issue deriving automatic module name In-Reply-To: <31DAF693-79AC-4880-8243-F797A718F0EE@gmail.com> References: <31DAF693-79AC-4880-8243-F797A718F0EE@gmail.com> Message-ID: <1095003569.2494627.1507101486154.JavaMail.zimbra@u-pem.fr> Hi Paul, the whole idea of jigsaw is that if you pass the startup check of the module graph, there will be not surprise anymore, so preventing the VM to boot is by design. Here, you will not be able to reference the jar in another module-info so there is no point to start with a wrong configuration. R?mi ----- Mail original ----- > De: "Paul Bakker" > ?: "jigsaw-dev" > Envoy?: Mercredi 4 Octobre 2017 02:44:01 > Objet: issue deriving automatic module name > Hi, > > I ran into an issue testing some migration scenarios. When using > jboss-transaction-api_1.2_spec-1.0.1.Final.jar as an automatic module, startup > fails with: > > Caused by: java.lang.IllegalArgumentException: jboss.transaction.api.1.2.spec: > Invalid module name: '1' is not a Java identifier > > This is clearly a strange JAR name, and can be fixed by providing a module name, > but it should probably not prevent startup. > > Best, > > Paul From Alan.Bateman at oracle.com Wed Oct 4 13:07:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Oct 2017 06:07:03 -0700 Subject: issue deriving automatic module name In-Reply-To: <31DAF693-79AC-4880-8243-F797A718F0EE@gmail.com> References: <31DAF693-79AC-4880-8243-F797A718F0EE@gmail.com> Message-ID: <42c4bbc4-6a4d-cf6a-57ac-2945be5cd9f3@oracle.com> On 03/10/2017 17:44, Paul Bakker wrote: > Hi, > > I ran into an issue testing some migration scenarios. When using jboss-transaction-api_1.2_spec-1.0.1.Final.jar as an automatic module, startup fails with: > > Caused by: java.lang.IllegalArgumentException: jboss.transaction.api.1.2.spec: Invalid module name: '1' is not a Java identifier > > This is clearly a strange JAR name, and can be fixed by providing a module name, but it should probably not prevent startup. > I assume you've put this JAR file on the module path because some code in an automatic module has references to classes in this JAR file. So catching this at startup seem right, you will otherwise risk a failure at runtime (NoClassDefFoundError) if the module system were to ignore the oddly named JAR file. As an aside, the contents of this JAR file are also problematic because it contains classes from the java.transaction and java.sql modules. This is something that we hope the owners of the Java Transaction API JSR will resolve soon, maybe by splitting the spec into two so that Java SE can define a java.transaction.xa module (in conjunction with jettisoning the java.transaction module from Java SE and the JDK). -Alan From tom.dewolf at aca-it.be Wed Oct 4 15:17:09 2017 From: tom.dewolf at aca-it.be (Tom De Wolf) Date: Wed, 04 Oct 2017 15:17:09 +0000 Subject: javax.inject module? Message-ID: Hi, Does someone know why the javax.inject annotations contained in for example the following maven dependency are not part of the jdk? javax.inject javax.inject 1 Who or which dependency/jar can be used to depend on this set of injection annotations as an explicit module or a module with a reserved automatic module name? Who is responsible to tackle this for javax.inject? Thanks, Tom De Wolf Architect ACA-IT Solutions Belgium From Lance.Andersen at oracle.com Wed Oct 4 16:37:53 2017 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 4 Oct 2017 12:37:53 -0400 Subject: javax.inject module? In-Reply-To: References: Message-ID: <9ACCAC37-9233-4DE8-95ED-A83B2C5AE7DC@oracle.com> You can grab the jar from maven central https://mvnrepository.com/artifact/javax.inject/javax.inject/1 The JSR can be found here https://jcp.org/en/jsr/detail?id=330. I am hoping to try and get the JSR 330 spec leads to support updating the implementation jar with an automatic module name if at all possible. The proposed module name is java.inject Best Lance On Oct 4, 2017, at 11:17 AM, Tom De Wolf wrote: > Hi, > > Does someone know why the javax.inject annotations contained in for example > the following maven dependency are not part of the jdk? > > > > javax.inject > javax.inject > 1 > > > Who or which dependency/jar can be used to depend on this set of injection > annotations as an explicit module or a module with a reserved automatic > module name? Who is responsible to tackle this for javax.inject? > > Thanks, > > Tom De Wolf > Architect > ACA-IT Solutions > Belgium Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.bakker.nl at gmail.com Wed Oct 4 17:11:43 2017 From: paul.bakker.nl at gmail.com (paul.bakker.nl at gmail.com) Date: Wed, 4 Oct 2017 10:11:43 -0700 Subject: issue deriving automatic module name In-Reply-To: <42c4bbc4-6a4d-cf6a-57ac-2945be5cd9f3@oracle.com> References: <31DAF693-79AC-4880-8243-F797A718F0EE@gmail.com> <42c4bbc4-6a4d-cf6a-57ac-2945be5cd9f3@oracle.com> Message-ID: <7559CBC7-7517-4B5B-A5B5-79D652F912D2@gmail.com> My point is that the module name resolver that generates a module name from the file name should not choke on this file pattern. Failing at startup if there is a problem is of course the right thing to do. Yes, this jar has indeed another problem. I only ran into these problems testing some of my existing migration demos in IntelliJ, which puts all jars on the module path for a modular application. I?m going to open an issue with them for better control over this. Putting the jar on the CP is fine in this scenario, it is only a transitive dependency of another automatic module (Hibernate). Paul > On Oct 4, 2017, at 6:07 AM, Alan Bateman wrote: > >> On 03/10/2017 17:44, Paul Bakker wrote: >> Hi, >> >> I ran into an issue testing some migration scenarios. When using jboss-transaction-api_1.2_spec-1.0.1.Final.jar as an automatic module, startup fails with: >> >> Caused by: java.lang.IllegalArgumentException: jboss.transaction.api.1.2.spec: Invalid module name: '1' is not a Java identifier >> >> This is clearly a strange JAR name, and can be fixed by providing a module name, but it should probably not prevent startup. >> > I assume you've put this JAR file on the module path because some code in an automatic module has references to classes in this JAR file. So catching this at startup seem right, you will otherwise risk a failure at runtime (NoClassDefFoundError) if the module system were to ignore the oddly named JAR file. > > As an aside, the contents of this JAR file are also problematic because it contains classes from the java.transaction and java.sql modules. This is something that we hope the owners of the Java Transaction API JSR will resolve soon, maybe by splitting the spec into two so that Java SE can define a java.transaction.xa module (in conjunction with jettisoning the java.transaction module from Java SE and the JDK). > > -Alan From forax at univ-mlv.fr Wed Oct 4 18:13:58 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 Oct 2017 20:13:58 +0200 (CEST) Subject: javax.inject module? In-Reply-To: <9ACCAC37-9233-4DE8-95ED-A83B2C5AE7DC@oracle.com> References: <9ACCAC37-9233-4DE8-95ED-A83B2C5AE7DC@oracle.com> Message-ID: <1174475881.4954039.1507140838513.JavaMail.zimbra@u-pem.fr> Hi Lance, i'm not sure you have the right to use java or jdk as prefix for your module, or do you mean "javax.inject" ? R?mi ----- Mail original ----- > De: "Lance Andersen" > ?: "Tom De Wolf" > Cc: "jigsaw-dev" > Envoy?: Mercredi 4 Octobre 2017 18:37:53 > Objet: Re: javax.inject module? > You can grab the jar from maven central > https://mvnrepository.com/artifact/javax.inject/javax.inject/1 > > The JSR can be found here https://jcp.org/en/jsr/detail?id=330. > > I am hoping to try and get the JSR 330 spec leads to support updating the > implementation jar with an automatic module name if at all possible. The > proposed module name is java.inject > > Best > Lance > On Oct 4, 2017, at 11:17 AM, Tom De Wolf wrote: > >> Hi, >> >> Does someone know why the javax.inject annotations contained in for example >> the following maven dependency are not part of the jdk? >> >> >> >> javax.inject >> javax.inject >> 1 >> >> >> Who or which dependency/jar can be used to depend on this set of injection >> annotations as an explicit module or a module with a reserved automatic >> module name? Who is responsible to tackle this for javax.inject? >> >> Thanks, >> >> Tom De Wolf >> Architect >> ACA-IT Solutions >> Belgium > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Wed Oct 4 18:25:41 2017 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 4 Oct 2017 14:25:41 -0400 Subject: javax.inject module? In-Reply-To: <1174475881.4954039.1507140838513.JavaMail.zimbra@u-pem.fr> References: <9ACCAC37-9233-4DE8-95ED-A83B2C5AE7DC@oracle.com> <1174475881.4954039.1507140838513.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, Sorry if my message was confusing. JEP 200, http://openjdk.java.net/jeps/200, defines that: ?????????????? Standard modules, whose specifications are governed by the JCP, have names starting with the string "java.". ----------------------------------------- JSR 330 specifies the javax.inject package. The suggested module name would be java.inject. The hope is that the spec leads for JSR 330, will at a minimum update their API jar to include the MANIFEST attribute Automatic-Module-Name Automatic-Module-Name: java.inject This will help developers in the migration to modules. Best Lance On Oct 4, 2017, at 2:13 PM, Remi Forax wrote: > Hi Lance, > i'm not sure you have the right to use java or jdk as prefix for your module, or do you mean "javax.inject" ? > > R?mi > > ----- Mail original ----- >> De: "Lance Andersen" >> ?: "Tom De Wolf" >> Cc: "jigsaw-dev" >> Envoy?: Mercredi 4 Octobre 2017 18:37:53 >> Objet: Re: javax.inject module? > >> You can grab the jar from maven central >> https://mvnrepository.com/artifact/javax.inject/javax.inject/1 >> >> The JSR can be found here https://jcp.org/en/jsr/detail?id=330. >> >> I am hoping to try and get the JSR 330 spec leads to support updating the >> implementation jar with an automatic module name if at all possible. The >> proposed module name is java.inject >> >> Best >> Lance >> On Oct 4, 2017, at 11:17 AM, Tom De Wolf wrote: >> >>> Hi, >>> >>> Does someone know why the javax.inject annotations contained in for example >>> the following maven dependency are not part of the jdk? >>> >>> >>> >>> javax.inject >>> javax.inject >>> 1 >>> >>> >>> Who or which dependency/jar can be used to depend on this set of injection >>> annotations as an explicit module or a module with a reserved automatic >>> module name? Who is responsible to tackle this for javax.inject? >>> >>> Thanks, >>> >>> Tom De Wolf >>> Architect >>> ACA-IT Solutions >>> Belgium >> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Wed Oct 4 18:36:01 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 4 Oct 2017 20:36:01 +0200 (CEST) Subject: javax.inject module? In-Reply-To: References: <9ACCAC37-9233-4DE8-95ED-A83B2C5AE7DC@oracle.com> <1174475881.4954039.1507140838513.JavaMail.zimbra@u-pem.fr> Message-ID: <1795325616.5006727.1507142161625.JavaMail.zimbra@u-pem.fr> > De: "Lance Andersen" > ?: "Remi Forax" > Cc: "Tom De Wolf" , "jigsaw-dev" > > Envoy?: Mercredi 4 Octobre 2017 20:25:41 > Objet: Re: javax.inject module? > Hi Remi, > Sorry if my message was confusing. it's not, it's my mind which is confused :) > JEP 200, [ http://openjdk.java.net/jeps/200 | http://openjdk.java.net/jeps/200 ] > , defines that: >> ?????????????? >> Standard modules, whose specifications are governed by the JCP, have names >> starting with the string "java." . >> ----------------------------------------- > JSR 330 specifies the javax.inject package. The suggested module name would be > java.inject. > The hope is that the spec leads for JSR 330, will at a minimum update their API > jar to include the MANIFEST attribute Automatic-Module-Name > Automatic-Module-Name: java.inject > This will help developers in the migration to modules. thanks for the answer, R?mi > Best > Lance > On Oct 4, 2017, at 2:13 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> Hi Lance, >> i'm not sure you have the right to use java or jdk as prefix for your module, or >> do you mean "javax.inject" ? >> R?mi >> ----- Mail original ----- >>> De: "Lance Andersen" < [ mailto:Lance.Andersen at oracle.com | >>> Lance.Andersen at oracle.com ] > >>> ?: "Tom De Wolf" < [ mailto:tom.dewolf at aca-it.be | tom.dewolf at aca-it.be ] > >>> Cc: "jigsaw-dev" < [ mailto:jigsaw-dev at openjdk.java.net | >>> jigsaw-dev at openjdk.java.net ] > >>> Envoy?: Mercredi 4 Octobre 2017 18:37:53 >>> Objet: Re: javax.inject module? >>> You can grab the jar from maven central >>> [ https://mvnrepository.com/artifact/javax.inject/javax.inject/1 | >>> https://mvnrepository.com/artifact/javax.inject/javax.inject/1 ] >>> The JSR can be found here https://jcp.org/en/jsr/detail?id=330. >>> I am hoping to try and get the JSR 330 spec leads to support updating the >>> implementation jar with an automatic module name if at all possible. The >>> proposed module name is java.inject >>> Best >>> Lance >>> On Oct 4, 2017, at 11:17 AM, Tom De Wolf wrote: >>>> Hi, >>>> Does someone know why the javax.inject annotations contained in for example >>>> the following maven dependency are not part of the jdk? >>>> >>>> >>>> javax.inject >>>> javax.inject >>>> 1 >>>> >>>> Who or which dependency/jar can be used to depend on this set of injection >>>> annotations as an explicit module or a module with a reserved automatic >>>> module name? Who is responsible to tackle this for javax.inject? >>>> Thanks, >>>> Tom De Wolf >>>> Architect >>>> ACA-IT Solutions >>>> Belgium >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com > [ http://oracle.com/us/design/oracle-email-sig-198324.gif | Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037Oracle?Java Engineering?1 > Network Drive?Burlington, MA 01803 ] [ mailto:Lance.Andersen at oracle.com | > Lance.Andersen at oracle.com ] From Lance.Andersen at oracle.com Wed Oct 4 19:05:03 2017 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 4 Oct 2017 15:05:03 -0400 Subject: javax.inject module? In-Reply-To: References: <9ACCAC37-9233-4DE8-95ED-A83B2C5AE7DC@oracle.com> <1174475881.4954039.1507140838513.JavaMail.zimbra@u-pem.fr> <1795325616.5006727.1507142161625.JavaMail.zimbra@u-pem.fr> Message-ID: <09EAA4CE-B1BF-496F-AA11-E832AF4A35BB@oracle.com> yes, I will be reaching out to them in the near future? On Oct 4, 2017, at 2:54 PM, Tom De Wolf wrote: > Indeed it looks like the @Inject api is quite an important jar to get migrated into an explicit module as other frameworks downstream will need it to be able to correctly migrate themselves. Can someone contact the spec leads or is there another communication channel on which the request is should be launched? > > Best regards, > > Tom > Op wo 4 okt. 2017 om 20:36 schreef > > > De: "Lance Andersen" > ?: "Remi Forax" > Cc: "Tom De Wolf" , "jigsaw-dev" > Envoy?: Mercredi 4 Octobre 2017 20:25:41 > Objet: Re: javax.inject module? > Hi Remi, > Sorry if my message was confusing. > > it's not, it's my mind which is confused :) > > > JEP 200, http://openjdk.java.net/jeps/200, defines that: > > ?????????????? > Standard modules, whose specifications are governed by the JCP, have names starting with the string "java.". > ----------------------------------------- > > JSR 330 specifies the javax.inject package. The suggested module name would be java.inject. > > The hope is that the spec leads for JSR 330, will at a minimum update their API jar to include the MANIFEST attribute Automatic-Module-Name > Automatic-Module-Name: java.inject > > This will help developers in the migration to modules. > > thanks for the answer, > R?mi > > > Best > Lance > > > On Oct 4, 2017, at 2:13 PM, Remi Forax wrote: > > Hi Lance, > i'm not sure you have the right to use java or jdk as prefix for your module, or do you mean "javax.inject" ? > > R?mi > > ----- Mail original ----- > De: "Lance Andersen" > ?: "Tom De Wolf" > Cc: "jigsaw-dev" > Envoy?: Mercredi 4 Octobre 2017 18:37:53 > Objet: Re: javax.inject module? > > You can grab the jar from maven central > https://mvnrepository.com/artifact/javax.inject/javax.inject/1 > > The JSR can be found here https://jcp.org/en/jsr/detail?id=330. > > I am hoping to try and get the JSR 330 spec leads to support updating the > implementation jar with an automatic module name if at all possible. The > proposed module name is java.inject > > Best > Lance > On Oct 4, 2017, at 11:17 AM, Tom De Wolf wrote: > > Hi, > > Does someone know why the javax.inject annotations contained in for example > the following maven dependency are not part of the jdk? > > > > javax.inject > javax.inject > 1 > > > Who or which dependency/jar can be used to depend on this set of injection > annotations as an explicit module or a module with a reserved automatic > module name? Who is responsible to tackle this for javax.inject? > > Thanks, > > Tom De Wolf > Architect > ACA-IT Solutions > Belgium > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jonathan.gibbons at oracle.com Fri Oct 6 23:57:22 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 06 Oct 2017 16:57:22 -0700 Subject: setLocationForModule doesn't work as expected In-Reply-To: References: Message-ID: <59D81862.9090706@oracle.com> Oliver, This looks like: JDK-8188035: JavaFileManager.listLocationsForModules does not always reflect values set through tandardJavaFileManager.setLocationForModule. https://bugs.openjdk.java.net/browse/JDK-8188035 -- Jon On 08/09/2017 07: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 cowwoc at bbs.darktech.org Thu Oct 12 04:01:26 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 11 Oct 2017 21:01:26 -0700 (MST) Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <575EDB5C.5060601@oracle.com> References: <575EDB5C.5060601@oracle.com> Message-ID: <1507780886910-0.post@n5.nabble.com> Hi Jan, I've got a specific use-case I'd like your feedback on: * My library exports an enum. * Users must be able to pass enum values into exported API methods. * The enum contains a method to ensure that each possible value defines a different implementation. * The method is only meant to be invoked by non-exported implementation classes; however, seeing as those classes reside in other packages the method is public. So I'm left with a public method that I don't want users to be able to invoke. Ideally I don't want them to see the method either, but I don't think there is much I can do about that. Does this represent a legitimate case for public, non-exported methods? Or is there a better design that would meet the requirements? Thank you, Gili -- Sent from: http://jigsaw-dev.1059479.n5.nabble.com/ From Alan.Bateman at oracle.com Thu Oct 12 08:49:36 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Oct 2017 09:49:36 +0100 Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <1507780886910-0.post@n5.nabble.com> References: <575EDB5C.5060601@oracle.com> <1507780886910-0.post@n5.nabble.com> Message-ID: <176dfee6-060b-ceae-291c-dc26264f3db8@oracle.com> On 12/10/2017 05:01, cowwoc wrote: > Hi Jan, > > I've got a specific use-case I'd like your feedback on: > > * My library exports an enum. > * Users must be able to pass enum values into exported API methods. > * The enum contains a method to ensure that each possible value defines a > different implementation. > * The method is only meant to be invoked by non-exported implementation > classes; however, seeing as those classes reside in other packages the > method is public. > > So I'm left with a public method that I don't want users to be able to > invoke. Ideally I don't want them to see the method either, but I don't > think there is much I can do about that. > > Does this represent a legitimate case for public, non-exported methods? Or > is there a better design that would meet the requirements? Your library is a module that exports a package with a public enum. The enum defines a method that is not intended to be directly used outside of the module and so needs to be non-public. One approach is to put a helper class in a non-exported package that calls the non-public method on the enum reflectively (code in a module can do deep reflection on any member of any class in its own module). Using reflection, even on oneself, is brittle of course. A type safe approach would be to define a helper interface in a non-exported package and have the enum register an implementation. Static methods on the interface, or a separate helper, would provide consumers in the module a way to obtain the implementation. We uses this approach in the java.base module where it known as the "shared secrets mechanism". As regards "seeing the method" then there is nothing to prevent nosy parkers from reflecting on the enum class and discovering all its declared methods, including non-public methods. They can't invoke the methods but they will know they exist. -Alan From Alan.Bateman at oracle.com Thu Oct 12 21:11:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Oct 2017 22:11:19 +0100 Subject: 8186738: (sl) ServiceLoader::stream doesn't update cache Message-ID: <89c5feb1-7c74-9b0a-3e4a-5b17fee78649@oracle.com> There are are two issues in ServiceLoader that we crept in with re-write here in JDK 9. One is with the new stream method where the Provider elements are specified to be cached but the implementation dropped it in the final version. The second is specific to the security manager scenario where? errors encountered loading? or initializing providers (a static initializer throws an error for example) aren't wrapped with the ServiceConfigurationError. The changes to address these issues are trivial and I'd like to get them fixed in jdk10/master: ?? http://cr.openjdk.java.net/~alanb/8186738/webrev/index.html -Alan From cowwoc at bbs.darktech.org Thu Oct 12 22:10:08 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 12 Oct 2017 15:10:08 -0700 (MST) Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <176dfee6-060b-ceae-291c-dc26264f3db8@oracle.com> References: <575EDB5C.5060601@oracle.com> <1507780886910-0.post@n5.nabble.com> <176dfee6-060b-ceae-291c-dc26264f3db8@oracle.com> Message-ID: <1507846208752-0.post@n5.nabble.com> Alan Bateman wrote > A type safe approach would be to define a helper interface in a > non-exported package and have the enum register an implementation. > Static methods on the interface, or a separate helper, would provide > consumers in the module a way to obtain the implementation. We uses this > approach in the java.base module where it known as the "shared secrets > mechanism". Hi Alan, Can you provide an example of the "shared secrets mechanism"? You mentioned the java.base module but it's not clear where to look. It might also be easier if you reply at https://stackoverflow.com/q/46701545/14731 so others can see your answer. Thanks, Gili -- Sent from: http://jigsaw-dev.1059479.n5.nabble.com/ From mandy.chung at oracle.com Thu Oct 12 22:54:26 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 12 Oct 2017 15:54:26 -0700 Subject: 8186738: (sl) ServiceLoader::stream doesn't update cache In-Reply-To: <89c5feb1-7c74-9b0a-3e4a-5b17fee78649@oracle.com> References: <89c5feb1-7c74-9b0a-3e4a-5b17fee78649@oracle.com> Message-ID: On 10/12/17 2:11 PM, Alan Bateman wrote: > There are are two issues in ServiceLoader that we crept in with > re-write here in JDK 9. One is with the new stream method where the > Provider elements are specified to be cached but the implementation > dropped it in the final version. The second is specific to the > security manager scenario where? errors encountered loading? or > initializing providers (a static initializer throws an error for > example) aren't wrapped with the ServiceConfigurationError. > > The changes to address these issues are trivial and I'd like to get > them fixed in jdk10/master: > ?? http://cr.openjdk.java.net/~alanb/8186738/webrev/index.html > Looks good in general. test/jdk/java/util/ServiceLoader/security/test/p/Tests.java 184 assertTrue(e.getCause() instanceof Error); I think it's more precise to check e.getCause().getClass() == Error.class. Mandy From Alan.Bateman at oracle.com Fri Oct 13 13:51:02 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Oct 2017 14:51:02 +0100 Subject: 8186738: (sl) ServiceLoader::stream doesn't update cache In-Reply-To: References: <89c5feb1-7c74-9b0a-3e4a-5b17fee78649@oracle.com> Message-ID: <69ff48af-dffb-7ad5-8964-120aa53c2d3a@oracle.com> On 12/10/2017 23:54, mandy chung wrote: > : > > test/jdk/java/util/ServiceLoader/security/test/p/Tests.java > 184 assertTrue(e.getCause() instanceof Error); > I think it's more precise to check e.getCause().getClass() == Error.class. > You are right, that test should be improved, more so if each of cases throws a different error type. While testing this, I ran into an issue with the JRE and CLDR locale providers adpaters - they silently swallow exceptions and so were silently consuming security exceptions thrown by tests in in other areas (logging and resource bundle tests mostly). I've created JDK-8189272 to track this and in the mean-time, these two adpaters need to re-throw the SCE when it's not for a security exception. I've put the webrev with these changes here: ?? http://cr.openjdk.java.net/~alanb/8189264/webrev/index.html -Alan. From mandy.chung at oracle.com Fri Oct 13 17:36:14 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 13 Oct 2017 10:36:14 -0700 Subject: 8186738: (sl) ServiceLoader::stream doesn't update cache In-Reply-To: <69ff48af-dffb-7ad5-8964-120aa53c2d3a@oracle.com> References: <89c5feb1-7c74-9b0a-3e4a-5b17fee78649@oracle.com> <69ff48af-dffb-7ad5-8964-120aa53c2d3a@oracle.com> Message-ID: On 10/13/17 6:51 AM, Alan Bateman wrote: > On 12/10/2017 23:54, mandy chung wrote: >> : >> >> test/jdk/java/util/ServiceLoader/security/test/p/Tests.java >> 184 assertTrue(e.getCause() instanceof Error); >> I think it's more precise to check e.getCause().getClass() == >> Error.class. >> > You are right, that test should be improved, more so if each of cases > throws a different error type. > The test update looks good. > While testing this, I ran into an issue with the JRE and CLDR locale > providers adpaters - they silently swallow exceptions and so were > silently consuming security exceptions thrown by tests in in other > areas (logging and resource bundle tests mostly). I've created > JDK-8189272 to track this and in the mean-time, these two adpaters > need to re-throw the SCE when it's not for a security exception. > > I've put the webrev with these changes here: > http://cr.openjdk.java.net/~alanb/8189264/webrev/index.html +1 Throwing SCE if not caused for security is okay for this patch. ? I agree that if there is any problem loading these providers, it should be made fatal and JDK-8189272 should consider that. Mandy From cowwoc at bbs.darktech.org Sat Oct 14 02:13:31 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 13 Oct 2017 19:13:31 -0700 (MST) Subject: JDK-8189251 Message-ID: <1507947211920-0.post@n5.nabble.com> Hi, I'm trying to understand the reasoning behind https://bugs.openjdk.java.net/browse/JDK-8189251 being closed as Won't Fix. Can someone please clarify the downside of named automatic-modules vs normal modules? I assume that there is some sort of downside; otherwise, we wouldn't be warning about them. Thank you, Gili -- Sent from: http://jigsaw-dev.1059479.n5.nabble.com/ From forax at univ-mlv.fr Sat Oct 14 11:54:15 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 14 Oct 2017 13:54:15 +0200 (CEST) Subject: JDK-8189251 In-Reply-To: <1507947211920-0.post@n5.nabble.com> References: <1507947211920-0.post@n5.nabble.com> Message-ID: <785224142.6588222.1507982055605.JavaMail.zimbra@u-pem.fr> Hi Gili, the main issue is that an automatic module can see classes from the classpath, but it also exports all its package so there is no encapsulation, and once you require one automatic module all automatic modules from the module path are visible. So an automatic module is a great tool when you transitioned to the module world, but in fine, you do not want any automatic modules in you dependency graph. regards, R?mi ----- Mail original ----- > De: "cowwoc" > ?: "jigsaw-dev" > Envoy?: Samedi 14 Octobre 2017 04:13:31 > Objet: JDK-8189251 > Hi, > > I'm trying to understand the reasoning behind > https://bugs.openjdk.java.net/browse/JDK-8189251 being closed as Won't Fix. > > Can someone please clarify the downside of named automatic-modules vs normal > modules? I assume that there is some sort of downside; otherwise, we > wouldn't be warning about them. > > Thank you, > Gili > > > > -- > Sent from: http://jigsaw-dev.1059479.n5.nabble.com/ From sundararajan.athijegannathan at oracle.com Thu Oct 19 14:04:32 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 19 Oct 2017 19:34:32 +0530 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used as root Message-ID: <59E8B0F0.7010802@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ Thanks, -Sundar From Alan.Bateman at oracle.com Thu Oct 19 14:35:13 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Oct 2017 15:35:13 +0100 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used as root In-Reply-To: <59E8B0F0.7010802@oracle.com> References: <59E8B0F0.7010802@oracle.com> Message-ID: <570fc851-0140-2d93-b9a0-f9a8b175c70e@oracle.com> On 19/10/2017 15:04, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 > Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ Why do you want to treat the root modules differently?? Shouldn't it look at all modules in the configuration (cf, not config) and fail with a useful message if any of the modules are automatic modules? -Alan From sundararajan.athijegannathan at oracle.com Thu Oct 19 15:10:39 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 19 Oct 2017 20:40:39 +0530 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used In-Reply-To: <570fc851-0140-2d93-b9a0-f9a8b175c70e@oracle.com> References: <59E8B0F0.7010802@oracle.com> <570fc851-0140-2d93-b9a0-f9a8b175c70e@oracle.com> Message-ID: <59E8C06F.1010104@oracle.com> Right. Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.01/ Thanks, -Sundar On 19/10/17, 8:05 PM, Alan Bateman wrote: > On 19/10/2017 15:04, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 >> Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ > Why do you want to treat the root modules differently? Shouldn't it > look at all modules in the configuration (cf, not config) and fail > with a useful message if any of the modules are automatic modules? > > -Alan From mandy.chung at oracle.com Thu Oct 19 21:58:23 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 19 Oct 2017 14:58:23 -0700 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used as root In-Reply-To: <59E8B0F0.7010802@oracle.com> References: <59E8B0F0.7010802@oracle.com> Message-ID: <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> On 10/19/17 7:04 AM, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 > Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ > 441 ModuleFinder finder = config.finder(); 442 for (String root : config.getModules()) { This should check the resolved modules rather than just the root modules since a resolved module may be an automatic module but not a root. You may want to add such a test case too. (A side note: JlinkConfiguration::getModules perhaps should be renamed to `roots` since it returns the root modules specified in jlink --add-modules) 447 throw new IllegalArgumentException(taskHelper.getMessage("err.automatic.module.as.root", modDesc.name())); It may be useful to include the pathname to the exception message. Nit: long line and good to wrap it into multiple lines. Mandy From mandy.chung at oracle.com Thu Oct 19 22:07:42 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 19 Oct 2017 15:07:42 -0700 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used as root In-Reply-To: <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> References: <59E8B0F0.7010802@oracle.com> <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> Message-ID: <5a11c77c-f52c-07dd-fac3-5a6c808efe1e@oracle.com> Hi Sunder, > Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.01/ This version checks the resolved modules which is good.? One other comment: 444 throw new IllegalArgumentException(taskHelper.getMessage("err.automatic.module", modDesc.name()));It may be useful to include the pathname to the exception message. Nit: long line and good to wrap it into multiple lines. Mandy P.S.? My previous reply lost the formatting and I fixed the copy below (just as a record for easy viewing). On 10/19/17 2:58 PM, mandy chung wrote: > > On 10/19/17 7:04 AM, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 >> Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ >> > > 441 ModuleFinder finder = config.finder(); > 442 for (String root : config.getModules()) { > This should check the resolved modules rather than just the root > modules since a resolved module may be an automatic module but not > a root. You may want to add such a test case too. > > (A side note: JlinkConfiguration::getModules perhaps should be > renamed to `roots` since it returns the root modules specified > in jlink --add-modules) > > 447 throw new IllegalArgumentException(taskHelper.getMessage("err.automatic.module.as.root", modDesc.name())); > > It may be useful to include the pathname to the exception message. > Nit: long line and good to wrap it into multiple lines. > Mandy From sundararajan.athijegannathan at oracle.com Fri Oct 20 03:53:54 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 Oct 2017 09:23:54 +0530 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used In-Reply-To: <5a11c77c-f52c-07dd-fac3-5a6c808efe1e@oracle.com> References: <59E8B0F0.7010802@oracle.com> <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> <5a11c77c-f52c-07dd-fac3-5a6c808efe1e@oracle.com> Message-ID: <59E97352.8090208@oracle.com> Hi, Updated to include location (when available) and formatting: http://cr.openjdk.java.net/~sundar/8189671/webrev.02/ -Sundar On 20/10/17, 3:37 AM, mandy chung wrote: > Hi Sunder, > >> Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.01/ > > This version checks the resolved modules which is good. One other > comment: > > 444 throw new > IllegalArgumentException(taskHelper.getMessage("err.automatic.module", > modDesc.name()));It may be useful to include the pathname to the > exception message. Nit: long line and good to wrap it into multiple > lines. > > Mandy > P.S. My previous reply lost the formatting and I fixed the copy below > (just as a record for easy viewing). > > > > On 10/19/17 2:58 PM, mandy chung wrote: >> >> On 10/19/17 7:04 AM, Sundararajan Athijegannathan wrote: >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 >>> Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ >>> >> >> 441 ModuleFinder finder = config.finder(); >> 442 for (String root : config.getModules()) { >> This should check the resolved modules rather than just the root >> modules since a resolved module may be an automatic module but not >> a root. You may want to add such a test case too. >> >> (A side note: JlinkConfiguration::getModules perhaps should be >> renamed to `roots` since it returns the root modules specified >> in jlink --add-modules) >> >> 447 throw new >> IllegalArgumentException(taskHelper.getMessage("err.automatic.module.as.root", >> modDesc.name())); >> >> It may be useful to include the pathname to the exception message. >> Nit: long line and good to wrap it into multiple lines. >> Mandy > From Alan.Bateman at oracle.com Fri Oct 20 07:16:39 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Oct 2017 08:16:39 +0100 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used In-Reply-To: <59E97352.8090208@oracle.com> References: <59E8B0F0.7010802@oracle.com> <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> <5a11c77c-f52c-07dd-fac3-5a6c808efe1e@oracle.com> <59E97352.8090208@oracle.com> Message-ID: <749429c7-f1b1-4ba1-f156-7d261fdd9d9a@oracle.com> On 20/10/2017 04:53, Sundararajan Athijegannathan wrote: > Hi, > > Updated to include location (when available) and formatting: > http://cr.openjdk.java.net/~sundar/8189671/webrev.02/ This looks right now. As jlink only supports packaged modules on the file system then each module should have a location. Another way to handle this case is to map it to "unknown", this should do it: ??????? cf.modules().stream() ??????????????? .map(ResolvedModule::reference) ??????????????? .filter(mref -> mref.descriptor().isAutomatic()) ??????????????? .findAny() ??????????????? .ifPresent(mref -> { ??????????????????? String loc = mref.location().map(URI::toString).orElse(""); ??????????????????? .. ??????????????? }); -Alan From sundararajan.athijegannathan at oracle.com Fri Oct 20 08:03:17 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 Oct 2017 13:33:17 +0530 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used In-Reply-To: <749429c7-f1b1-4ba1-f156-7d261fdd9d9a@oracle.com> References: <59E8B0F0.7010802@oracle.com> <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> <5a11c77c-f52c-07dd-fac3-5a6c808efe1e@oracle.com> <59E97352.8090208@oracle.com> <749429c7-f1b1-4ba1-f156-7d261fdd9d9a@oracle.com> Message-ID: <59E9ADC5.2000804@oracle.com> Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.03/ -Sundar On 20/10/17, 12:46 PM, Alan Bateman wrote: > On 20/10/2017 04:53, Sundararajan Athijegannathan wrote: >> Hi, >> >> Updated to include location (when available) and formatting: >> http://cr.openjdk.java.net/~sundar/8189671/webrev.02/ > This looks right now. As jlink only supports packaged modules on the > file system then each module should have a location. Another way to > handle this case is to map it to "unknown", this should do it: > > cf.modules().stream() > .map(ResolvedModule::reference) > .filter(mref -> mref.descriptor().isAutomatic()) > .findAny() > .ifPresent(mref -> { > String loc = > mref.location().map(URI::toString).orElse(""); > .. > }); > > -Alan From Alan.Bateman at oracle.com Fri Oct 20 09:22:33 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Oct 2017 10:22:33 +0100 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used In-Reply-To: <59E9ADC5.2000804@oracle.com> References: <59E8B0F0.7010802@oracle.com> <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> <5a11c77c-f52c-07dd-fac3-5a6c808efe1e@oracle.com> <59E97352.8090208@oracle.com> <749429c7-f1b1-4ba1-f156-7d261fdd9d9a@oracle.com> <59E9ADC5.2000804@oracle.com> Message-ID: <0b006aa6-6cd0-f812-b16d-76154a180624@oracle.com> On 20/10/2017 09:03, Sundararajan Athijegannathan wrote: > Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.03/ Looks good. -Alan From mandy.chung at oracle.com Fri Oct 20 14:26:06 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 20 Oct 2017 07:26:06 -0700 Subject: RFR 8189671: jlink should clearly report error when an automatic module is used In-Reply-To: <59E9ADC5.2000804@oracle.com> References: <59E8B0F0.7010802@oracle.com> <84b61327-30e8-b7c4-f71c-483765ae7428@oracle.com> <5a11c77c-f52c-07dd-fac3-5a6c808efe1e@oracle.com> <59E97352.8090208@oracle.com> <749429c7-f1b1-4ba1-f156-7d261fdd9d9a@oracle.com> <59E9ADC5.2000804@oracle.com> Message-ID: On 10/20/17 1:03 AM, Sundararajan Athijegannathan wrote: > Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.03/ > Looks good. Mandy From tom.dewolf at aca-it.be Sun Oct 22 11:24:02 2017 From: tom.dewolf at aca-it.be (Tom De Wolf) Date: Sun, 22 Oct 2017 11:24:02 +0000 Subject: Planned Java Platform Modules Features? Message-ID: Hi I was wondering if there are any new features related to the java platform module system planned for the next jdk release? Maybe a more general question, which features to the java platform module system will get priority? semantic versioning to support compatibility checking within the module system? something else? Thanks for providing some insights in the future plans for the module system, Tom From sundararajan.athijegannathan at oracle.com Mon Oct 23 05:37:16 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Oct 2017 11:07:16 +0530 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing Message-ID: <59ED800C.9080406@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8189777 Webrev: http://cr.openjdk.java.net/~sundar/8189777/webrev.00/ Thanks, -Sundar From Alan.Bateman at oracle.com Mon Oct 23 07:41:40 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Oct 2017 08:41:40 +0100 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <59ED800C.9080406@oracle.com> References: <59ED800C.9080406@oracle.com> Message-ID: On 23/10/2017 06:37, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189777 > Webrev: http://cr.openjdk.java.net/~sundar/8189777/webrev.00/ This patch is very welcome as it makes jlink easier to use without any impact to the cross building case. Two small comments: - getStandardModulePath might be better renamed getDefaultModulePath as it isn't standard. - JlinkConfiguration calls moduleFinder() during construction. You can avoid this by adding a static ModuelFinder moduleFinder(List). -Alan From sundararajan.athijegannathan at oracle.com Mon Oct 23 10:37:21 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Oct 2017 16:07:21 +0530 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: References: <59ED800C.9080406@oracle.com> Message-ID: <59EDC661.2040601@oracle.com> Updated for getDefaultModulePath. moduleFinder uses three instance fields - modulepaths, limitmods and modules. We may have to pass all to the static method... http://cr.openjdk.java.net/~sundar/8189777/webrev.01 Thanks -Sundar On 23/10/17, 1:11 PM, Alan Bateman wrote: > On 23/10/2017 06:37, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189777 >> Webrev: http://cr.openjdk.java.net/~sundar/8189777/webrev.00/ > This patch is very welcome as it makes jlink easier to use without any > impact to the cross building case. > > Two small comments: > > - getStandardModulePath might be better renamed getDefaultModulePath > as it isn't standard. > > - JlinkConfiguration calls moduleFinder() during construction. You can > avoid this by adding a static ModuelFinder moduleFinder(List). > > -Alan From Alan.Bateman at oracle.com Mon Oct 23 14:33:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Oct 2017 15:33:06 +0100 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <59EDC661.2040601@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com> Message-ID: On 23/10/2017 11:37, Sundararajan Athijegannathan wrote: > Updated for getDefaultModulePath. moduleFinder uses three instance > fields - modulepaths, limitmods and modules. We may have to pass all > to the static method... Yes, if you want to avoid operating on a partly initialized JlinkConfiguration. The other alternative is to create the ModuleFinder before creating the JlinkConfiguration, that might be clearer overall. -Alan From org.openjdk at io7m.com Mon Oct 23 17:48:26 2017 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 23 Oct 2017 17:48:26 +0000 Subject: Retrieving the bytes of platform classes Message-ID: <20171023174826.31f4708e@copperhead.int.arc7.info> Hello. I'm writing a small tool to analyze the APIs of Java 9 modules. I'm analyzing the bytecode statically with ASM and have run into a slight problem: In order to properly analyze a class, I also need to analyze the superclasses and, in some cases, the superclasses can be platform classes. Given a platform class name such as "java/io/InputStream", is it possible to retrieve the raw bytes for the named class in a portable (read: non-platform-specific, non-JVM-specific) manner? In the olden days, we'd probably have gone rummaging in rt.jar, but that was obviously a hack and wasn't future-proof. My tool is only designed to work with JDK 9 and up. Note that I'm *not* asking to get from loaded Class instances to bytes: I'm analyzing classes statically and none of the analyzed classes will actually be loaded by any ClassLoader. -- Mark Raynsford | http://www.io7m.com From Alan.Bateman at oracle.com Mon Oct 23 17:55:15 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Oct 2017 18:55:15 +0100 Subject: Retrieving the bytes of platform classes In-Reply-To: <20171023174826.31f4708e@copperhead.int.arc7.info> References: <20171023174826.31f4708e@copperhead.int.arc7.info> Message-ID: <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> On 23/10/2017 18:48, Mark Raynsford wrote: > : > > In the olden days, we'd probably have gone rummaging in rt.jar, but > that was obviously a hack and wasn't future-proof. My tool is only > designed to work with JDK 9 and up. > > Note that I'm *not* asking to get from loaded Class instances to > bytes: I'm analyzing classes statically and none of the analyzed > classes will actually be loaded by any ClassLoader. > Have you looked at the jrt file system provider? Details in JEP 261 [1]. -Alan [1] http://openjdk.java.net/jeps/261 From Alan.Bateman at oracle.com Mon Oct 23 17:58:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Oct 2017 18:58:04 +0100 Subject: Retrieving the bytes of platform classes In-Reply-To: <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> References: <20171023174826.31f4708e@copperhead.int.arc7.info> <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> Message-ID: On 23/10/2017 18:55, Alan Bateman wrote: > Details in JEP 261 [1]. Sorry, I meant JEP 220 (http://openjdk.java.net/jeps/220). From mark.reinhold at oracle.com Mon Oct 23 18:00:22 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 23 Oct 2017 11:00:22 -0700 Subject: Retrieving the bytes of platform classes In-Reply-To: <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> References: <20171023174826.31f4708e@copperhead.int.arc7.info> <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> Message-ID: <20171023110022.963682505@eggemoggin.niobe.net> 2017/10/23 10:55:15 -0700, alan.bateman at oracle.com: > On 23/10/2017 18:48, Mark Raynsford wrote: >> : >> >> In the olden days, we'd probably have gone rummaging in rt.jar, but >> that was obviously a hack and wasn't future-proof. My tool is only >> designed to work with JDK 9 and up. >> >> Note that I'm *not* asking to get from loaded Class instances to >> bytes: I'm analyzing classes statically and none of the analyzed >> classes will actually be loaded by any ClassLoader. > > Have you looked at the jrt file system provider? Details in JEP 261 [1]. See also JEP 220: http://openjdk.java.net/jeps/220#New-URI-scheme-for-naming-stored-modules-classes-and-resources - Mark From org.openjdk at io7m.com Mon Oct 23 18:02:47 2017 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 23 Oct 2017 18:02:47 +0000 Subject: Retrieving the bytes of platform classes In-Reply-To: <20171023110022.963682505@eggemoggin.niobe.net> References: <20171023174826.31f4708e@copperhead.int.arc7.info> <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> <20171023110022.963682505@eggemoggin.niobe.net> Message-ID: <20171023180247.4f476489@copperhead.int.arc7.info> On 2017-10-23T11:00:22 -0700 mark.reinhold at oracle.com wrote: > 2017/10/23 10:55:15 -0700, alan.bateman at oracle.com: > > Have you looked at the jrt file system provider? Details in JEP 261 [1]. > > See also JEP 220: > > http://openjdk.java.net/jeps/220#New-URI-scheme-for-naming-stored-modules-classes-and-resources Ah, thanks! I hadn't seen this. Looks like exactly what I need. -- Mark Raynsford | http://www.io7m.com From mandy.chung at oracle.com Mon Oct 23 21:27:44 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 23 Oct 2017 14:27:44 -0700 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com> Message-ID: On 10/23/17 3:37 AM, Sundararajan Athijegannathan wrote: > Updated for getDefaultModulePath. moduleFinder uses three instance > fields - modulepaths, limitmods and modules. We may have to pass all > to the static method... > > http://cr.openjdk.java.net/~sundar/8189777/webrev.01 What happens to this command? ?? $ jlink --add-modules ALL-MODULE-PATH -output image It will use the default module path but there is no root module. On 10/23/17 7:33 AM, Alan Bateman wrote: > > The other alternative is to create the ModuleFinder before creating > the JlinkConfiguration, that might be clearer overall. I like the idea passing ModuleFinder to JlinkConfiguration constructor which is cleaner. Mandy From sundararajan.athijegannathan at oracle.com Tue Oct 24 01:47:46 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 24 Oct 2017 07:17:46 +0530 Subject: Retrieving the bytes of platform classes In-Reply-To: <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> References: <20171023174826.31f4708e@copperhead.int.arc7.info> <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> Message-ID: <59EE9BC2.6080004@oracle.com> A simple nashorn sample to extract single .class using jrt file system provider: https://blogs.oracle.com/sundararajan/extracting-a-single-class-file-from-java9-platform-jimage-modules-file -Sundar On 23/10/17, 11:25 PM, Alan Bateman wrote: > On 23/10/2017 18:48, Mark Raynsford wrote: >> : >> >> In the olden days, we'd probably have gone rummaging in rt.jar, but >> that was obviously a hack and wasn't future-proof. My tool is only >> designed to work with JDK 9 and up. >> >> Note that I'm *not* asking to get from loaded Class instances to >> bytes: I'm analyzing classes statically and none of the analyzed >> classes will actually be loaded by any ClassLoader. >> > Have you looked at the jrt file system provider? Details in JEP 261 [1]. > > -Alan > > [1] http://openjdk.java.net/jeps/261 From sundararajan.athijegannathan at oracle.com Tue Oct 24 04:05:05 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 24 Oct 2017 09:35:05 +0530 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

Message-ID: <59EEBBF1.9030200@oracle.com> Hi, * ALL-MODULE-PATH case seems to be handled fine (in private JlinkConfiguration initJlinkConfig() throws BadArgs { method). When no --module-path is specified, default module path is used and all default observable modules are added as root. I ran the command you mentioned and it worked fine. * refactored JlinkConfiguration.moduleFinder as a static method. Note that we've to create ModuleFinder inside JlinkContiguration because we may change modulepaths in constructor (if java.base module is not found) and so new ModuleFinder has to be created anyway. Updated webrev: http://cr.openjdk.java.net/~sundar/8189777/webrev.02/ Thanks, -Sundar On 24/10/17, 2:57 AM, mandy chung wrote: > On 10/23/17 3:37 AM, Sundararajan Athijegannathan wrote: >> Updated for getDefaultModulePath. moduleFinder uses three instance >> fields - modulepaths, limitmods and modules. We may have to pass all >> to the static method... >> >> http://cr.openjdk.java.net/~sundar/8189777/webrev.01 > > What happens to this command? > $ jlink --add-modules ALL-MODULE-PATH -output image > > It will use the default module path but there is no root module. > > On 10/23/17 7:33 AM, Alan Bateman wrote: >> >> The other alternative is to create the ModuleFinder before creating >> the JlinkConfiguration, that might be clearer overall. > > I like the idea passing ModuleFinder to JlinkConfiguration constructor > which is cleaner. > > Mandy From mandy.chung at oracle.com Tue Oct 24 17:10:45 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 24 Oct 2017 10:10:45 -0700 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <59EEBBF1.9030200@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

<59EEBBF1.9030200@oracle.com> Message-ID: <19fa0fca-4df8-28ee-4bd3-0bfa345786a8@oracle.com> On 10/23/17 9:05 PM, Sundararajan Athijegannathan wrote: > Hi, > > * ALL-MODULE-PATH case seems to be handled fine (in? private > JlinkConfiguration initJlinkConfig() throws BadArgs { method). When no > --module-path is specified, default module path is used and all > default observable modules are added as root. I ran the command you > mentioned and it worked fine. > That's right.? The default module path is added before initJlinkConfig is called.? Thanks for confirming that. > * refactored JlinkConfiguration.moduleFinder as a static method. Note > that we've to create ModuleFinder inside JlinkContiguration because we > may change modulepaths in constructor (if java.base module is not > found) and so new ModuleFinder has to be created anyway. > There are three places creating a ModuleFinder, JlinkConfiguration::moduleFinder, JlinkTask::initJlinkConfig, and JlinkTask::newModuleFinder.?? It'd be good to? refactor this e.g. all call the newModuleFinder method. Add a new JlinkConfiguration constructor takes a ModuleFinder and have the initJlinkConfig method to create a ModuleFinder with the default module path appended, if appropriate.? line 254-265 in JlinkTask - the check of an empty module path is not needed. Instead it can test if java.base is found from JlinkConfiguration::finder. Mandy From sundararajan.athijegannathan at oracle.com Wed Oct 25 10:23:08 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 Oct 2017 15:53:08 +0530 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <19fa0fca-4df8-28ee-4bd3-0bfa345786a8@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

<59EEBBF1.9030200@oracle.com> <19fa0fca-4df8-28ee-4bd3-0bfa345786a8@oracle.com> Message-ID: <59F0660C.7010600@oracle.com> Updated: http://cr.openjdk.java.net/~sundar/8189777/webrev.03/ Thanks -Sundar On 24/10/17, 10:40 PM, mandy chung wrote: > > > On 10/23/17 9:05 PM, Sundararajan Athijegannathan wrote: >> Hi, >> >> * ALL-MODULE-PATH case seems to be handled fine (in private >> JlinkConfiguration initJlinkConfig() throws BadArgs { method). When >> no --module-path is specified, default module path is used and all >> default observable modules are added as root. I ran the command you >> mentioned and it worked fine. >> > > That's right. The default module path is added before initJlinkConfig > is called. Thanks for confirming that. > >> * refactored JlinkConfiguration.moduleFinder as a static method. Note >> that we've to create ModuleFinder inside JlinkContiguration because >> we may change modulepaths in constructor (if java.base module is not >> found) and so new ModuleFinder has to be created anyway. >> > There are three places creating a ModuleFinder, > JlinkConfiguration::moduleFinder, JlinkTask::initJlinkConfig, and > JlinkTask::newModuleFinder. It'd be good to refactor this e.g. all > call the newModuleFinder method. > > Add a new JlinkConfiguration constructor takes a ModuleFinder and have > the initJlinkConfig method to create a ModuleFinder with the default > module path appended, if appropriate. line 254-265 in JlinkTask - the > check of an empty module path is not needed. Instead it can test if > java.base is found from JlinkConfiguration::finder. > > Mandy From Alan.Bateman at oracle.com Wed Oct 25 12:55:33 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Oct 2017 13:55:33 +0100 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <59F0660C.7010600@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

<59EEBBF1.9030200@oracle.com> <19fa0fca-4df8-28ee-4bd3-0bfa345786a8@oracle.com> <59F0660C.7010600@oracle.com> Message-ID: <92426d07-d750-285a-fcc7-5e842912c94e@oracle.com> On 25/10/2017 11:23, Sundararajan Athijegannathan wrote: > Updated: http://cr.openjdk.java.net/~sundar/8189777/webrev.03/ This looks better. A few comments/questions: Does the JlinkConfiguration constructor that takes the ModuleFinder still need the module path? I assume it shouldn't be needed now (getModulepaths() seems unused). Also is the second constructor needed? I ask because the second constructor as it callbacks back to JlinkTask which seems a bit odd. Is JlinkConfiguration the right place for getDefaultModulePath? It might be clearer to do that in JlinkTask. -Alan From sundararajan.athijegannathan at oracle.com Wed Oct 25 13:43:16 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 Oct 2017 19:13:16 +0530 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <92426d07-d750-285a-fcc7-5e842912c94e@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

<59EEBBF1.9030200@oracle.com> <19fa0fca-4df8-28ee-4bd3-0bfa345786a8@oracle.com> <59F0660C.7010600@oracle.com> <92426d07-d750-285a-fcc7-5e842912c94e@oracle.com> Message-ID: <59F094F4.7080408@oracle.com> Second constructor is used by packager (internal) api. I could move getDefaultModulePath to JlinkTask.. -Sundar On 25/10/17, 6:25 PM, Alan Bateman wrote: > On 25/10/2017 11:23, Sundararajan Athijegannathan wrote: >> Updated: http://cr.openjdk.java.net/~sundar/8189777/webrev.03/ > This looks better. A few comments/questions: > > Does the JlinkConfiguration constructor that takes the ModuleFinder > still need the module path? I assume it shouldn't be needed now > (getModulepaths() seems unused). Also is the second constructor > needed? I ask because the second constructor as it callbacks back to > JlinkTask which seems a bit odd. > > Is JlinkConfiguration the right place for getDefaultModulePath? It > might be clearer to do that in JlinkTask. > > -Alan From Alan.Bateman at oracle.com Wed Oct 25 14:20:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Oct 2017 15:20:19 +0100 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <59F094F4.7080408@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

<59EEBBF1.9030200@oracle.com> <19fa0fca-4df8-28ee-4bd3-0bfa345786a8@oracle.com> <59F0660C.7010600@oracle.com> <92426d07-d750-285a-fcc7-5e842912c94e@oracle.com> <59F094F4.7080408@oracle.com> Message-ID: On 25/10/2017 14:43, Sundararajan Athijegannathan wrote: > Second constructor is used by packager (internal) api. I could move > getDefaultModulePath to JlinkTask.. Ugh, we need to get packager moved away from using this. -Alan. From volker.simonis at gmail.com Thu Oct 26 16:37:50 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Oct 2017 18:37:50 +0200 Subject: Retrieving the bytes of platform classes In-Reply-To: <59EE9BC2.6080004@oracle.com> References: <20171023174826.31f4708e@copperhead.int.arc7.info> <516e2d2a-7405-91e2-fb63-9401aedf9936@oracle.com> <59EE9BC2.6080004@oracle.com> Message-ID: >From within Java (i.e. for the current VM) you could simply do: ClassLoader.getSystemResourceAsStream("java/io/InputStream.class") Regards, Volker On Tue, Oct 24, 2017 at 3:47 AM, Sundararajan Athijegannathan wrote: > A simple nashorn sample to extract single .class using jrt file system > provider: > > https://blogs.oracle.com/sundararajan/extracting-a-single-class-file-from-java9-platform-jimage-modules-file > > -Sundar > > > On 23/10/17, 11:25 PM, Alan Bateman wrote: >> >> On 23/10/2017 18:48, Mark Raynsford wrote: >>> >>> : >>> >>> In the olden days, we'd probably have gone rummaging in rt.jar, but >>> that was obviously a hack and wasn't future-proof. My tool is only >>> designed to work with JDK 9 and up. >>> >>> Note that I'm *not* asking to get from loaded Class instances to >>> bytes: I'm analyzing classes statically and none of the analyzed >>> classes will actually be loaded by any ClassLoader. >>> >> Have you looked at the jrt file system provider? Details in JEP 261 [1]. >> >> -Alan >> >> [1] http://openjdk.java.net/jeps/261 From mandy.chung at oracle.com Thu Oct 26 16:47:43 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 26 Oct 2017 09:47:43 -0700 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <59F094F4.7080408@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

Message-ID: <59F250DB.3090407@oracle.com> On 10/26/2017 1:03 PM, Stephen Colebourne wrote: > (previously posted on core-libs-dev, moved by request) (Thanks!) > Option 1: > All modules that implement a particular logging API must have the same > module name > eg. every module that implements "org.slf4j" (the API) must be named > "org.slf4j.impl" > > Option 2: > The module name of the implementation can be whatever name makes sense. > > > For most service providers, option 2 is obvious, however for logging > it is generally the case that only one implementation should be > present. If all the jar files that implement a specific logging API > had the same module name (option 1) then the module system could > ensure that only one was loaded. This is a particular concern as it is > not uncommon for a jar file in Maven Central to depend on a specific > implementation of logging when it should only be depending on the API. > > > I'm leaning towards option 2, as it is simpler and does not require > all implementations to have the same module name (which would be > difficult to require). Any other considerations I'm missing? Option 1 opens the door to multiple modules with the same name being placed in different directories of the modulepath. Not a good place to be, even if no-one is targeting them via 'requires'. (I think ServiceLoader does not care about duplicate module names when scanning modules on the modulepath, and will inspect their 'provides' directives regardless. However, I confess that I cannot figure out from the ServiceLoader spec which modules are observable during binding.) Stepping back, there are two big anti-patterns in the world of ServiceLoader. First, it is an anti-pattern for a provider module to 'exports' its provider implementation. Second, it is an anti-pattern for a consumer module to 'requires' a particular provider module. Option 2 fights the second anti-pattern by making provider modules not "stand out" more than other modules. This in turn fights the first anti-pattern, because a provider module that is not expecting to be mentioned in 'requires' will not hurry to 'exports' anything. (Yes, this is all a bit soft, but programming with services is primarily about mindset.) Alex From mandy.chung at oracle.com Thu Oct 26 21:31:52 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 26 Oct 2017 14:31:52 -0700 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: <59F215A4.9090604@oracle.com> References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

Message-ID: On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne wrote: > For most service providers, option 2 is obvious, however for logging > it is generally the case that only one implementation should be > present. If all the jar files that implement a specific logging API > had the same module name (option 1) then the module system could > ensure that only one was loaded. This is a particular concern as it is > not uncommon for a jar file in Maven Central to depend on a specific > implementation of logging when it should only be depending on the API. This is actually a general special case (if you follow my meaning): that of an API which uses services to locate an implementation, yet typically only one implementation should be existent and used. For example, I/O or other platform-dependent systems also spring to mind: they have a common API, but you generally only want one implementation (except maybe in some special cases - just like for logging). I think that in any case, be it a singleton-ish provider case like one of the above or a multiple-provider case, it is always appropriate to choose a unique module name for implementations. It's not appropriate for an API to prescribe an implementation module name. Perhaps we can enhance Jigsaw in the future with some kind of feature that enforces singleton implementations, if it becomes any sort of practical problem. -- - DML From greggwon at cox.net Thu Oct 26 22:14:35 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Thu, 26 Oct 2017 17:14:35 -0500 Subject: Module naming for logging implementations In-Reply-To: References:

Message-ID: <6269FD4D-B114-4F60-91F4-41260E99ECCD@cox.net> I?d like to reverse this dependency to be that in the end, I want every module in the app I construct to funnel through and use a single Logging implementation so that I can linearize the logging streams into a single stream of details that help me to understand the health and progress of my application. I want to make sure that I can provide this logging merge apparatus without having to jump through hoops. Yes, I need to have something that provides all APIs, but those all will be from a single module, not one module per API, because I don?t want to have to create such an layered web of modules. Removing the logging dependency resolution from module references to ServiceLayer resolution helps me to do this by deferring the task to runtime. I like that notion because it helps me be able to construct all the objects and implementation details, and then the logging users can find my merged logging implementation, instead of me having to reference the dependency graph and figure out how to make 5 modules accept dependency injections that allow me to make them work, when I may not know all of the details of their ?activation?. Gregg > On Oct 26, 2017, at 5:05 PM, David Lloyd wrote: > > On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne > wrote: >> For most service providers, option 2 is obvious, however for logging >> it is generally the case that only one implementation should be >> present. If all the jar files that implement a specific logging API >> had the same module name (option 1) then the module system could >> ensure that only one was loaded. This is a particular concern as it is >> not uncommon for a jar file in Maven Central to depend on a specific >> implementation of logging when it should only be depending on the API. > > This is actually a general special case (if you follow my meaning): > that of an API which uses services to locate an implementation, yet > typically only one implementation should be existent and used. For > example, I/O or other platform-dependent systems also spring to mind: > they have a common API, but you generally only want one implementation > (except maybe in some special cases - just like for logging). > > I think that in any case, be it a singleton-ish provider case like one > of the above or a multiple-provider case, it is always appropriate to > choose a unique module name for implementations. It's not appropriate > for an API to prescribe an implementation module name. > > Perhaps we can enhance Jigsaw in the future with some kind of feature > that enforces singleton implementations, if it becomes any sort of > practical problem. > > -- > - DML From scolebourne at joda.org Thu Oct 26 22:26:24 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 26 Oct 2017 23:26:24 +0100 Subject: Module naming for logging implementations In-Reply-To: References:

Message-ID: Thanks Alex and David, those are good arguments. So option 2 it is. Stephen On 26 October 2017 at 23:05, David Lloyd wrote: > On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne > wrote: >> For most service providers, option 2 is obvious, however for logging >> it is generally the case that only one implementation should be >> present. If all the jar files that implement a specific logging API >> had the same module name (option 1) then the module system could >> ensure that only one was loaded. This is a particular concern as it is >> not uncommon for a jar file in Maven Central to depend on a specific >> implementation of logging when it should only be depending on the API. > > This is actually a general special case (if you follow my meaning): > that of an API which uses services to locate an implementation, yet > typically only one implementation should be existent and used. For > example, I/O or other platform-dependent systems also spring to mind: > they have a common API, but you generally only want one implementation > (except maybe in some special cases - just like for logging). > > I think that in any case, be it a singleton-ish provider case like one > of the above or a multiple-provider case, it is always appropriate to > choose a unique module name for implementations. It's not appropriate > for an API to prescribe an implementation module name. > > Perhaps we can enhance Jigsaw in the future with some kind of feature > that enforces singleton implementations, if it becomes any sort of > practical problem. > > -- > - DML From cedric.champeau at gmail.com Thu Oct 26 22:35:43 2017 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Fri, 27 Oct 2017 00:35:43 +0200 Subject: Module naming for logging implementations In-Reply-To: References:

Message-ID: There's a good argument for 1, though. log4j typically doesn't separate api and implementation. So a module would "require 'log4j'". It means that if another module like slf4j doesn't "pretend to be" log4j, it's now going to fail. Said differently, Jigsaw kills module replacements and fatjars. 2017-10-27 0:26 GMT+02:00 Stephen Colebourne : > Thanks Alex and David, those are good arguments. So option 2 it is. > Stephen > > On 26 October 2017 at 23:05, David Lloyd wrote: > > On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne > > wrote: > >> For most service providers, option 2 is obvious, however for logging > >> it is generally the case that only one implementation should be > >> present. If all the jar files that implement a specific logging API > >> had the same module name (option 1) then the module system could > >> ensure that only one was loaded. This is a particular concern as it is > >> not uncommon for a jar file in Maven Central to depend on a specific > >> implementation of logging when it should only be depending on the API. > > > > This is actually a general special case (if you follow my meaning): > > that of an API which uses services to locate an implementation, yet > > typically only one implementation should be existent and used. For > > example, I/O or other platform-dependent systems also spring to mind: > > they have a common API, but you generally only want one implementation > > (except maybe in some special cases - just like for logging). > > > > I think that in any case, be it a singleton-ish provider case like one > > of the above or a multiple-provider case, it is always appropriate to > > choose a unique module name for implementations. It's not appropriate > > for an API to prescribe an implementation module name. > > > > Perhaps we can enhance Jigsaw in the future with some kind of feature > > that enforces singleton implementations, if it becomes any sort of > > practical problem. > > > > -- > > - DML > From scolebourne at joda.org Thu Oct 26 22:43:02 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 26 Oct 2017 23:43:02 +0100 Subject: Module naming for logging implementations In-Reply-To: References:

Message-ID: On 26 October 2017 at 23:35, C?dric Champeau wrote: > There's a good argument for 1, though. log4j typically doesn't separate api > and implementation. So a module would "require 'log4j'". It means that if > another module like slf4j doesn't "pretend to be" log4j, it's now going to > fail. Said differently, Jigsaw kills module replacements and fatjars. Module replacements like log4j v1 work exactly as today. There is one extra requirement that as well as having the same package name, the replacement must have the same module name. Fatjars are certainly of no use as a dependency with the current jigsaw design, but logging doesn't seem to use fatjars. Stephen From sundararajan.athijegannathan at oracle.com Fri Oct 27 02:51:45 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 27 Oct 2017 08:21:45 +0530 Subject: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing In-Reply-To: References: <59ED800C.9080406@oracle.com> <59EDC661.2040601@oracle.com>

<59EEBBF1.9030200@oracle.com> <19fa0fca-4df8-28ee-4bd3-0bfa345786a8@oracle.com> <59F0660C.7010600@oracle.com> <92426d07-d750-285a-fcc7-5e842912c94e@oracle.com> <59F094F4.7080408@oracle.com> <618a93dd-3c33-5b17-3fe4-53ee1561cdda@oracle.com> <59F215A4.9090604@oracle.com> Message-ID: <59F29F41.2010809@oracle.com> Thanks for your reviews! -Sundar On 27/10/17, 3:01 AM, mandy chung wrote: > > > On 10/26/17 10:04 AM, Sundararajan Athijegannathan wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~sundar/8189777/webrev.04/index.html >> > > Looks good. Thanks for incorporating the comments. > > Mandy > From mik3hall at gmail.com Sat Oct 28 14:12:19 2017 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 28 Oct 2017 09:12:19 -0500 Subject: OS X commandline tools Message-ID: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> I think I may of raised this as an issue sometime earlier. I filed a bug report through bug report.java We will review your report and have assigned it an internal review ID : 9051382 . But as I recall earlier it was indicated that this involved files owned by Apple. For one thing I think they seem to symbolic link files in an apple legacy java Framework. The solution as I remember it was for Mike Swingler to update the files. This doesn?t seem like something you would want him to continue doing on an ongoing basis. For now I looked at it again because there seems to be nothing at all pointing to the jlink command for me. echo `which jdeps` is here /usr/bin/jdeps is here echo `which jlink` is here is here Nothing ?is here? What didn?t seem appropriate to the bug report is /usr/libexec/java_home. This has been a useful platform specific command line tool for some time. Currently it is somewhat broken. This works? /usr/libexec/java_home /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home This didn?t seem to work but now does seem to but with a incorrect(?) error message. /usr/libexec/java_home -v 1.9 --exec java -version Unable to find any JVMs matching version "1.9". java version "9" Java(TM) SE Runtime Environment (build 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) Is this supported? Did Apple contribute this to the port? Would anyone be making changes to it or is it possible to get the source to change on your own? From javalists at cbfiddle.com Sat Oct 28 14:55:24 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Sat, 28 Oct 2017 07:55:24 -0700 Subject: OS X commandline tools In-Reply-To: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> References: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> Message-ID: Use ?9? instead of ?1.9? > On Oct 28, 2017, at 7:12 AM, Michael Hall wrote: > > I think I may of raised this as an issue sometime earlier. > > I filed a bug report through bug report.java > We will review your report and have assigned it an internal review ID : 9051382 . > > But as I recall earlier it was indicated that this involved files owned by Apple. For one thing I think they seem to symbolic link files in an apple legacy java Framework. > The solution as I remember it was for Mike Swingler to update the files. This doesn?t seem like something you would want him to continue doing on an ongoing basis. > > For now I looked at it again because there seems to be nothing at all pointing to the jlink command for me. > > echo `which jdeps` is here > /usr/bin/jdeps is here > > echo `which jlink` is here > is here > > Nothing ?is here? > > What didn?t seem appropriate to the bug report is /usr/libexec/java_home. > This has been a useful platform specific command line tool for some time. Currently it is somewhat broken. > This works? > /usr/libexec/java_home > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home > > This didn?t seem to work but now does seem to but with a incorrect(?) error message. > /usr/libexec/java_home -v 1.9 --exec java -version > Unable to find any JVMs matching version "1.9". > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > Is this supported? Did Apple contribute this to the port? Would anyone be making changes to it or is it possible to get the source to change on your own? > > From mik3hall at gmail.com Sat Oct 28 14:58:08 2017 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 28 Oct 2017 09:58:08 -0500 Subject: OS X commandline tools In-Reply-To: References: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> Message-ID: <625A5AB0-16BB-4520-AF4B-68FD78CE1F37@gmail.com> > >> >> What didn?t seem appropriate to the bug report is /usr/libexec/java_home. >> This has been a useful platform specific command line tool for some time. Currently it is somewhat broken. >> This works? >> /usr/libexec/java_home >> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home >> >> This didn?t seem to work but now does seem to but with a incorrect(?) error message. >> /usr/libexec/java_home -v 1.9 --exec java -version >> Unable to find any JVMs matching version "1.9". >> java version "9" >> Java(TM) SE Runtime Environment (build 9+181) >> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >> >> Is this supported? Did Apple contribute this to the port? Would anyone be making changes to it or is it possible to get the source to change on your own? >> >> > > On Oct 28, 2017, at 9:55 AM, Alan Snyder wrote: > > Use ?9? instead of ?1.9? Eliminates the error message. I should of looked at what version was actually giving me. Curious on the rest but this was the only real current issue. Thanks. From Alan.Bateman at oracle.com Sat Oct 28 18:59:26 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 28 Oct 2017 19:59:26 +0100 Subject: OS X commandline tools In-Reply-To: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> References: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> Message-ID: <702488e2-ebe1-084c-5c3f-ce9cf3184c7e@oracle.com> On 28/10/2017 15:12, Michael Hall wrote: > I think I may of raised this as an issue sometime earlier. > > I filed a bug report through bug report.java > We will review your report and have assigned it an internal review ID : 9051382 . > > But as I recall earlier it was indicated that this involved files owned by Apple. I think so, meaning it's the macOS installation and updates that add the sym links to /usr/bin. I don't think it's something that we can help with here, or even in OpenJDK. Once you set your PATH to the installation directory then you should be able to use jlink. -Alan From mik3hall at gmail.com Sat Oct 28 19:03:06 2017 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 28 Oct 2017 14:03:06 -0500 Subject: OS X commandline tools In-Reply-To: <702488e2-ebe1-084c-5c3f-ce9cf3184c7e@oracle.com> References: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> <702488e2-ebe1-084c-5c3f-ce9cf3184c7e@oracle.com> Message-ID: <5E2E5634-7BC5-4FF7-B508-81554706B2FE@gmail.com> > On Oct 28, 2017, at 1:59 PM, Alan Bateman wrote: > > On 28/10/2017 15:12, Michael Hall wrote: >> I think I may of raised this as an issue sometime earlier. >> >> I filed a bug report through bug report.java >> We will review your report and have assigned it an internal review ID : 9051382 . >> >> But as I recall earlier it was indicated that this involved files owned by Apple. > I think so, meaning it's the macOS installation and updates that add the sym links to /usr/bin. I don't think it's something that we can help with here, or even in OpenJDK. Once you set your PATH to the installation directory then you should be able to use jlink. > > -Alan So this means that without setting PATH the java command line tools are not available on OS X? Or just new ones? Is there potential conflict for existing commands pointed to out of /usr/bin? Or will that be assumed to work correctly as-is indefinitely? From mik3hall at gmail.com Sat Oct 28 19:12:15 2017 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 28 Oct 2017 14:12:15 -0500 Subject: OS X commandline tools In-Reply-To: <5E2E5634-7BC5-4FF7-B508-81554706B2FE@gmail.com> References: <78CE3142-7343-44D4-A028-776D8F2072A8@gmail.com> <702488e2-ebe1-084c-5c3f-ce9cf3184c7e@oracle.com> <5E2E5634-7BC5-4FF7-B508-81554706B2FE@gmail.com> Message-ID: > On Oct 28, 2017, at 2:03 PM, Michael Hall wrote: > >> On Oct 28, 2017, at 1:59 PM, Alan Bateman wrote: >> >> On 28/10/2017 15:12, Michael Hall wrote: >>> I think I may of raised this as an issue sometime earlier. >>> >>> I filed a bug report through bug report.java >>> We will review your report and have assigned it an internal review ID : 9051382 . >>> >>> But as I recall earlier it was indicated that this involved files owned by Apple. >> I think so, meaning it's the macOS installation and updates that add the sym links to /usr/bin. I don't think it's something that we can help with here, or even in OpenJDK. Once you set your PATH to the installation directory then you should be able to use jlink. >> >> -Alan > > So this means that without setting PATH the java command line tools are not available on OS X? Or just new ones? Is there potential conflict for existing commands pointed to out of /usr/bin? Or will that be assumed to work correctly as-is indefinitely? Not that I can?t set PATH. That works for me. I am just wondering about other Mac users who start running into this. I guess if they don?t have the legacy commands around nothing will be there and they will have to discover setting PATH?