From njbartlett at gmail.com Thu Sep 1 00:45:17 2016 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 1 Sep 2016 01:45:17 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, Actually I don?t think that statically linking will work. This would produce modules that have overlapping private (non-exported) packages, and such modules also cannot be used in Java 9 on the modulepath. I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two modules both containing a private package org.example.util. The following exception resulted: java.lang.reflect.LayerInstantiationException: Package org.example.util in both module a and module b. Again this could be ?solved? by using custom ClassLoaders or a ClassLoader-based module system like OSGi on Java 9. Neil > On 31 Aug 2016, at 20:28, Remi Forax wrote: > > The other solution is to statically link the right version of slf4j inside guava and jsoup. > A tool like jarjar can be updated to merge two modular jars (merge two module-info). > > cheers, > R?mi > > ----- Mail original ----- >> De: "Neil Bartlett" >> ?: cowwoc at bbs.darktech.org, "Alex Buckley" >> Cc: "ZML-OpenJDK-Jigsaw-Developers" >> Envoy?: Mercredi 31 Ao?t 2016 20:54:44 >> Objet: Re: Multiple versions of a non-exported dependency > >> Gili, >> >> As Alex points out: your use-case can be supported in Java 9 but only with the >> addition of custom ClassLoaders, or by using an existing ClassLoader-based >> module system such as OSGi. >> >> The same is also true of Java 8, and Java 7, etc. >> >> Regards, >> Neil >> >> >>> On 31 Aug 2016, at 19:29, Alex Buckley wrote: >>> >>> On 8/31/2016 10:56 AM, cowwoc wrote: >>>> I recently became aware of the fact that the Jigsaw specification declared >>>> "version-selection" as a non-goal. While I understand how we ended up here, >>>> I am hoping that you were able to support the following (very common) >>>> use-case: >>>> >>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>>> * Module "Guava" depends on module slf4j version 1 (requires but does not >>>> export it). >>>> * Module "JSoup" depends on module slf4j version 2 (requires but does not >>>> export it). >>>> * slf4j version 2 and is not backwards-compatible with version 1. >>>> >>>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party >>>> tools like Maven or OSGI) be smart enough to provide different versions of >>>> slf4j to "Guava" and "JSoup"? >>> >>> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it >>> a.k.a. 'requires public'.) >>> >>> This use case isn't possible on JDK 8 for JARs on the classpath, and it's not >>> supported on JDK 9 for modular JARs on the modulepath: >>> >>> - If you have two versions of a modular JAR slf4j.jar in different directories >>> on the modulepath, then the first one to be found will dominate, and that's >>> what will be resolved for both Guava and JSoup. >>> >>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the modulepath, >>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java >>> -m HelloWorld' will fail. The boot layer will refuse to map the "same" packages >>> from different slf4j_v* modules to the application class loader. >>> >>> The use case _is_ supported on JDK 9 for modular JARs loaded into custom loaders >>> of custom layers. That is, the Java Platform Module System is perfectly capable >>> of supporting the use case -- please see any of my "Jigsaw: Under The Hood" >>> presentations. The use case just isn't supported "out of the box" by the 'java' >>> launcher for JARs on the modulepath. >>> >>> Alex From njbartlett at gmail.com Thu Sep 1 07:28:48 2016 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 1 Sep 2016 08:28:48 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <7a721eb6-29a9-b1cc-28cc-cb5b1e65bc0f@bbs.darktech.org> Message-ID: Hi Paul, > On 31 Aug 2016, at 20:25, Paul Benedict wrote: > > Neil, but doesn't the prohibition of duplicate packages continue to rear > its head? I?m sorry I lost track of the context of this question! If you?re asking whether OSGi is prohibited from loading duplicate packages on Java 9, the answer is no. In OSGi on Java 9 (or any earlier Java version) we use ClassLoaders to achieve isolation between modules. Therefore we explicitly support overlapping private packages, and even multiple modules with overlapping exported packages (NB the latter feature does require OSGi Release 4 or above, which was released in 2004). In contrast, Jigsaw/JPMS implements isolation using access control rather than ClassLoader visibility. All modules on the modulepath are loaded into the same ClassLoader, and a single ClassLoader can have at most one definition of each class. The implication is that two modules can conflict purely based on their private internals. If any tool attempts to construct valid module sets for use with the modulepath, it will not be sufficient for that tool to examine only the declared module metadata in module-info.class. As Alex points out, you can work around this restriction by creating a Layer and mapping modules within that layer to separate ClassLoaders. If you do this then you will still need to manage the visibility of classes and delegation between ClassLoaders. In other words you will have started down the path of implementing your own ClassLoader-based module system comparable to where OSGi was in 1998. Regards, Neil > > Cheers, > Paul > > On Wed, Aug 31, 2016 at 2:21 PM, cowwoc wrote: > >> Well, this is unfortunate. As I stated earlier, I fail to see how >> depending on constant version numbers (not version ranges) fall under >> the scope of "version selection". Was this case considered/discussed in >> depth? >> >> Not everyone is sold on version ranges (e.g. the vast majority of Maven >> artifacts I've seen depend on constant versions) and I think this would >> go a long way towards solving the original "classpath hell" problem. >> >> Gili >> >> On 2016-08-31 2:55 PM, Neil Bartlett [via jigsaw-dev] wrote: >>> Gili, >>> >>> As Alex points out: your use-case can be supported in Java 9 but only >>> with the addition of custom ClassLoaders, or by using an existing >>> ClassLoader-based module system such as OSGi. >>> >>> The same is also true of Java 8, and Java 7, etc. >>> >>> Regards, >>> Neil >>> >>> >>>> On 31 Aug 2016, at 19:29, Alex Buckley <[hidden email] >>> > wrote: >>>> >>>> On 8/31/2016 10:56 AM, cowwoc wrote: >>>>> I recently became aware of the fact that the Jigsaw specification >>> declared >>>>> "version-selection" as a non-goal. While I understand how we ended >>> up here, >>>>> I am hoping that you were able to support the following (very common) >>>>> use-case: >>>>> >>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>>>> * Module "Guava" depends on module slf4j version 1 (requires but >>> does not >>>>> export it). >>>>> * Module "JSoup" depends on module slf4j version 2 (requires but >>> does not >>>>> export it). >>>>> * slf4j version 2 and is not backwards-compatible with version 1. >>>>> >>>>> What happens at runtime? Will Jigsaw (out of the box, without >>> 3rd-party >>>>> tools like Maven or OSGI) be smart enough to provide different >>> versions of >>>>> slf4j to "Guava" and "JSoup"? >>>> >>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not >>> "re-export" it a.k.a. 'requires public'.) >>>> >>>> This use case isn't possible on JDK 8 for JARs on the classpath, and >>> it's not supported on JDK 9 for modular JARs on the modulepath: >>>> >>>> - If you have two versions of a modular JAR slf4j.jar in different >>> directories on the modulepath, then the first one to be found will >>> dominate, and that's what will be resolved for both Guava and JSoup. >>>> >>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the >>> modulepath, and Guava requires slf4j_v1 and JSoup requires slf4j_v2, >>> then launching 'java -m HelloWorld' will fail. The boot layer will >>> refuse to map the "same" packages from different slf4j_v* modules to >>> the application class loader. >>>> >>>> The use case _is_ supported on JDK 9 for modular JARs loaded into >>> custom loaders of custom layers. That is, the Java Platform Module >>> System is perfectly capable of supporting the use case -- please see >>> any of my "Jigsaw: Under The Hood" presentations. The use case just >>> isn't supported "out of the box" by the 'java' launcher for JARs on >>> the modulepath. >>>> >>>> Alex >>> >>> >>> >>> ------------------------------------------------------------------------ >>> If you reply to this email, your message will be added to the >>> discussion below: >>> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions- >> of-a-non-exported-dependency-tp5713364p5713366.html >>> >>> To unsubscribe from Multiple versions of a non-exported dependency, >>> click here >>> > unsubscribe_by_code&node=5713364&code=Y293d29jQGJicy5kYXJrdGVjaC5vcm >> d8NTcxMzM2NHwxNTc0MzIxMjQ3>. >>> NAML >>> > NamlServlet.jtp?macro=macro_viewer&id=instant_html% >> 21nabble%3Aemail.naml&base=nabble.naml.namespaces. >> BasicNamespace-nabble.view.web.template.NabbleNamespace- >> nabble.naml.namespaces.BasicNamespace-nabble.view. >> web.template.NabbleNamespace-nabble.naml.namespaces. >> BasicNamespace-nabble.view.web.template.NabbleNamespace- >> nabble.naml.namespaces.BasicNamespace-nabble.view. >> web.template.NabbleNamespace-nabble.naml.namespaces. >> BasicNamespace-nabble.view.web.template.NabbleNamespace- >> nabble.naml.namespaces.BasicNamespace-nabble.view. >> web.template.NabbleNamespace-nabble.view.web.template. >> NodeNamespace&breadcrumbs=notify_subscribers%21nabble% >> 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_ >> instant_email%21nabble%3Aemail.naml> >>> >> >> >> >> >> >> >> -- >> View this message in context: http://jigsaw-dev.1059479.n5. >> nabble.com/Multiple-versions-of-a-non-exported-dependency- >> tp5713364p5713367.html >> Sent from the jigsaw-dev mailing list archive at Nabble.com. >> > > > > -- > Cheers, > Paul From Alan.Bateman at oracle.com Thu Sep 1 07:59:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Sep 2016 08:59:00 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <7a721eb6-29a9-b1cc-28cc-cb5b1e65bc0f@bbs.darktech.org> Message-ID: <670aaf29-9416-dca3-e938-090b5aab389f@oracle.com> On 01/09/2016 08:28, Neil Bartlett wrote: > : > In contrast, Jigsaw/JPMS implements isolation using access control rather than ClassLoader visibility. All modules on the modulepath are loaded into the same ClassLoader, and a single ClassLoader can have at most one definition of each class. The implication is that two modules can conflict purely based on their private internals. If any tool attempts to construct valid module sets for use with the modulepath, it will not be sufficient for that tool to examine only the declared module metadata in module-info.class. Tools or containers that are looking at module declarations will need to be concerned with the non-exported packages, even if each module is ultimately mapped to its own class loader (easy to do with Layer API, no need to get into creating custom class loaders). Specifically, it is an error if: "Two or more modules in the configuration export the same package to a module that reads both. This includes the case where a module M containing package p reads another module that exports p to M." Once you move beyond the command line and application module path then there is no issue if two modules have the same non-exported package. -Alan From david.lloyd at redhat.com Thu Sep 1 12:29:04 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 1 Sep 2016 07:29:04 -0500 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: It seems like there is no good reason why the application modules aren't loaded with classloader-per-module now. The platform stuff could all be in one, but the application stuff? Problems like this are going to come up a lot otherwise; let's consider making that change. On 08/31/2016 07:45 PM, Neil Bartlett wrote: > Remi, > > Actually I don?t think that statically linking will work. This would produce modules that have overlapping private (non-exported) packages, and such modules also cannot be used in Java 9 on the modulepath. > > I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two modules both containing a private package org.example.util. The following exception resulted: java.lang.reflect.LayerInstantiationException: Package org.example.util in both module a and module b. > > Again this could be ?solved? by using custom ClassLoaders or a ClassLoader-based module system like OSGi on Java 9. > > Neil > > > >> On 31 Aug 2016, at 20:28, Remi Forax wrote: >> >> The other solution is to statically link the right version of slf4j inside guava and jsoup. >> A tool like jarjar can be updated to merge two modular jars (merge two module-info). >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Neil Bartlett" >>> ?: cowwoc at bbs.darktech.org, "Alex Buckley" >>> Cc: "ZML-OpenJDK-Jigsaw-Developers" >>> Envoy?: Mercredi 31 Ao?t 2016 20:54:44 >>> Objet: Re: Multiple versions of a non-exported dependency >> >>> Gili, >>> >>> As Alex points out: your use-case can be supported in Java 9 but only with the >>> addition of custom ClassLoaders, or by using an existing ClassLoader-based >>> module system such as OSGi. >>> >>> The same is also true of Java 8, and Java 7, etc. >>> >>> Regards, >>> Neil >>> >>> >>>> On 31 Aug 2016, at 19:29, Alex Buckley wrote: >>>> >>>> On 8/31/2016 10:56 AM, cowwoc wrote: >>>>> I recently became aware of the fact that the Jigsaw specification declared >>>>> "version-selection" as a non-goal. While I understand how we ended up here, >>>>> I am hoping that you were able to support the following (very common) >>>>> use-case: >>>>> >>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>>>> * Module "Guava" depends on module slf4j version 1 (requires but does not >>>>> export it). >>>>> * Module "JSoup" depends on module slf4j version 2 (requires but does not >>>>> export it). >>>>> * slf4j version 2 and is not backwards-compatible with version 1. >>>>> >>>>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party >>>>> tools like Maven or OSGI) be smart enough to provide different versions of >>>>> slf4j to "Guava" and "JSoup"? >>>> >>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it >>>> a.k.a. 'requires public'.) >>>> >>>> This use case isn't possible on JDK 8 for JARs on the classpath, and it's not >>>> supported on JDK 9 for modular JARs on the modulepath: >>>> >>>> - If you have two versions of a modular JAR slf4j.jar in different directories >>>> on the modulepath, then the first one to be found will dominate, and that's >>>> what will be resolved for both Guava and JSoup. >>>> >>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the modulepath, >>>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java >>>> -m HelloWorld' will fail. The boot layer will refuse to map the "same" packages >>>> from different slf4j_v* modules to the application class loader. >>>> >>>> The use case _is_ supported on JDK 9 for modular JARs loaded into custom loaders >>>> of custom layers. That is, the Java Platform Module System is perfectly capable >>>> of supporting the use case -- please see any of my "Jigsaw: Under The Hood" >>>> presentations. The use case just isn't supported "out of the box" by the 'java' >>>> launcher for JARs on the modulepath. >>>> >>>> Alex > -- - DML From greggwon at cox.net Thu Sep 1 13:23:36 2016 From: greggwon at cox.net (Gregg Wonderly) Date: Thu, 1 Sep 2016 08:23:36 -0500 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: The important detail for me, is that ClassLoader per module, with the current Class resolution scheme (this ClassLoader and whatever I can find in the parent), provides a lot of issues. The ?custom ClassLoaders? or ?containers like OSGi? remarks point at the ?us and them? attitude that is pretty prevalent in this conversation. The majority of developers are looking for a module system that is not an ?us or them? proposition. These ?all or nothing? compromises are what create the ?hell? that dominates conversations here. What we all want to be able to do, is write software once, target it to ?THE Java platform?, and be done. What Sun and now Oracle are continuing to do, is create more stuff that is nothing like what everyone else is doing with modularity and instead create something that is orthogonal to most peoples problem spaces and in the end creates tremendously more ?work? for nothing more than compatibility with the new ?JVM? environment. The real goal here needs to be making all of the other module and container systems obsolete. Those systems should ?want? to provide support for the awesome, new module system that will make in unnecessary for them to roll their own details any longer. Yes, that is a long road and a tall measure for success. But frankly, even the lack of any visibility of the style of modules that Netbeans has used for decades makes it clear that this groups view at Oracle is extremely narrow and perhaps even more uninformed about what the community actually needs. Gregg > On Sep 1, 2016, at 7:29 AM, David M. Lloyd wrote: > > It seems like there is no good reason why the application modules aren't loaded with classloader-per-module now. The platform stuff could all be in one, but the application stuff? Problems like this are going to come up a lot otherwise; let's consider making that change. > > On 08/31/2016 07:45 PM, Neil Bartlett wrote: >> Remi, >> >> Actually I don?t think that statically linking will work. This would produce modules that have overlapping private (non-exported) packages, and such modules also cannot be used in Java 9 on the modulepath. >> >> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two modules both containing a private package org.example.util. The following exception resulted: java.lang.reflect.LayerInstantiationException: Package org.example.util in both module a and module b. >> >> Again this could be ?solved? by using custom ClassLoaders or a ClassLoader-based module system like OSGi on Java 9. >> >> Neil >> >> >> >>> On 31 Aug 2016, at 20:28, Remi Forax wrote: >>> >>> The other solution is to statically link the right version of slf4j inside guava and jsoup. >>> A tool like jarjar can be updated to merge two modular jars (merge two module-info). >>> >>> cheers, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Neil Bartlett" >>>> ?: cowwoc at bbs.darktech.org, "Alex Buckley" >>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" >>>> Envoy?: Mercredi 31 Ao?t 2016 20:54:44 >>>> Objet: Re: Multiple versions of a non-exported dependency >>> >>>> Gili, >>>> >>>> As Alex points out: your use-case can be supported in Java 9 but only with the >>>> addition of custom ClassLoaders, or by using an existing ClassLoader-based >>>> module system such as OSGi. >>>> >>>> The same is also true of Java 8, and Java 7, etc. >>>> >>>> Regards, >>>> Neil >>>> >>>> >>>>> On 31 Aug 2016, at 19:29, Alex Buckley wrote: >>>>> >>>>> On 8/31/2016 10:56 AM, cowwoc wrote: >>>>>> I recently became aware of the fact that the Jigsaw specification declared >>>>>> "version-selection" as a non-goal. While I understand how we ended up here, >>>>>> I am hoping that you were able to support the following (very common) >>>>>> use-case: >>>>>> >>>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>>>>> * Module "Guava" depends on module slf4j version 1 (requires but does not >>>>>> export it). >>>>>> * Module "JSoup" depends on module slf4j version 2 (requires but does not >>>>>> export it). >>>>>> * slf4j version 2 and is not backwards-compatible with version 1. >>>>>> >>>>>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party >>>>>> tools like Maven or OSGI) be smart enough to provide different versions of >>>>>> slf4j to "Guava" and "JSoup"? >>>>> >>>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it >>>>> a.k.a. 'requires public'.) >>>>> >>>>> This use case isn't possible on JDK 8 for JARs on the classpath, and it's not >>>>> supported on JDK 9 for modular JARs on the modulepath: >>>>> >>>>> - If you have two versions of a modular JAR slf4j.jar in different directories >>>>> on the modulepath, then the first one to be found will dominate, and that's >>>>> what will be resolved for both Guava and JSoup. >>>>> >>>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the modulepath, >>>>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java >>>>> -m HelloWorld' will fail. The boot layer will refuse to map the "same" packages >>>>> from different slf4j_v* modules to the application class loader. >>>>> >>>>> The use case _is_ supported on JDK 9 for modular JARs loaded into custom loaders >>>>> of custom layers. That is, the Java Platform Module System is perfectly capable >>>>> of supporting the use case -- please see any of my "Jigsaw: Under The Hood" >>>>> presentations. The use case just isn't supported "out of the box" by the 'java' >>>>> launcher for JARs on the modulepath. >>>>> >>>>> Alex >> > > -- > - DML From david.lloyd at redhat.com Thu Sep 1 13:37:07 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 1 Sep 2016 08:37:07 -0500 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: You've missed the point I'm afraid. I'm just talking about having the launcher use (the equivalent of) java.lang.reflect.Layer#defineModulesWithManyLoaders instead of (the equivalent of) java.lang.reflect.Layer#defineModulesWithOneLoader. (The launcher actually uses the slightly lower level defineModules() method I think, but really what I'm suggesting is to update the function to assign new class loaders for named modules instead of reusing the same one.) On 09/01/2016 08:23 AM, Gregg Wonderly wrote: > The important detail for me, is that ClassLoader per module, with the current Class resolution scheme (this ClassLoader and whatever I can find in the parent), provides a lot of issues. The ?custom ClassLoaders? or ?containers like OSGi? remarks point at the ?us and them? attitude that is pretty prevalent in this conversation. The majority of developers are looking for a module system that is not an ?us or them? proposition. These ?all or nothing? compromises are what create the ?hell? that dominates conversations here. What we all want to be able to do, is write software once, target it to ?THE Java platform?, and be done. > > What Sun and now Oracle are continuing to do, is create more stuff that is nothing like what everyone else is doing with modularity and instead create something that is orthogonal to most peoples problem spaces and in the end creates tremendously more ?work? for nothing more than compatibility with the new ?JVM? environment. > > The real goal here needs to be making all of the other module and container systems obsolete. Those systems should ?want? to provide support for the awesome, new module system that will make in unnecessary for them to roll their own details any longer. > > Yes, that is a long road and a tall measure for success. But frankly, even the lack of any visibility of the style of modules that Netbeans has used for decades makes it clear that this groups view at Oracle is extremely narrow and perhaps even more uninformed about what the community actually needs. > > Gregg > >> On Sep 1, 2016, at 7:29 AM, David M. Lloyd wrote: >> >> It seems like there is no good reason why the application modules aren't loaded with classloader-per-module now. The platform stuff could all be in one, but the application stuff? Problems like this are going to come up a lot otherwise; let's consider making that change. >> >> On 08/31/2016 07:45 PM, Neil Bartlett wrote: >>> Remi, >>> >>> Actually I don?t think that statically linking will work. This would produce modules that have overlapping private (non-exported) packages, and such modules also cannot be used in Java 9 on the modulepath. >>> >>> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two modules both containing a private package org.example.util. The following exception resulted: java.lang.reflect.LayerInstantiationException: Package org.example.util in both module a and module b. >>> >>> Again this could be ?solved? by using custom ClassLoaders or a ClassLoader-based module system like OSGi on Java 9. >>> >>> Neil >>> >>> >>> >>>> On 31 Aug 2016, at 20:28, Remi Forax wrote: >>>> >>>> The other solution is to statically link the right version of slf4j inside guava and jsoup. >>>> A tool like jarjar can be updated to merge two modular jars (merge two module-info). >>>> >>>> cheers, >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Neil Bartlett" >>>>> ?: cowwoc at bbs.darktech.org, "Alex Buckley" >>>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" >>>>> Envoy?: Mercredi 31 Ao?t 2016 20:54:44 >>>>> Objet: Re: Multiple versions of a non-exported dependency >>>> >>>>> Gili, >>>>> >>>>> As Alex points out: your use-case can be supported in Java 9 but only with the >>>>> addition of custom ClassLoaders, or by using an existing ClassLoader-based >>>>> module system such as OSGi. >>>>> >>>>> The same is also true of Java 8, and Java 7, etc. >>>>> >>>>> Regards, >>>>> Neil >>>>> >>>>> >>>>>> On 31 Aug 2016, at 19:29, Alex Buckley wrote: >>>>>> >>>>>> On 8/31/2016 10:56 AM, cowwoc wrote: >>>>>>> I recently became aware of the fact that the Jigsaw specification declared >>>>>>> "version-selection" as a non-goal. While I understand how we ended up here, >>>>>>> I am hoping that you were able to support the following (very common) >>>>>>> use-case: >>>>>>> >>>>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>>>>>> * Module "Guava" depends on module slf4j version 1 (requires but does not >>>>>>> export it). >>>>>>> * Module "JSoup" depends on module slf4j version 2 (requires but does not >>>>>>> export it). >>>>>>> * slf4j version 2 and is not backwards-compatible with version 1. >>>>>>> >>>>>>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party >>>>>>> tools like Maven or OSGI) be smart enough to provide different versions of >>>>>>> slf4j to "Guava" and "JSoup"? >>>>>> >>>>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it >>>>>> a.k.a. 'requires public'.) >>>>>> >>>>>> This use case isn't possible on JDK 8 for JARs on the classpath, and it's not >>>>>> supported on JDK 9 for modular JARs on the modulepath: >>>>>> >>>>>> - If you have two versions of a modular JAR slf4j.jar in different directories >>>>>> on the modulepath, then the first one to be found will dominate, and that's >>>>>> what will be resolved for both Guava and JSoup. >>>>>> >>>>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the modulepath, >>>>>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java >>>>>> -m HelloWorld' will fail. The boot layer will refuse to map the "same" packages >>>>>> from different slf4j_v* modules to the application class loader. >>>>>> >>>>>> The use case _is_ supported on JDK 9 for modular JARs loaded into custom loaders >>>>>> of custom layers. That is, the Java Platform Module System is perfectly capable >>>>>> of supporting the use case -- please see any of my "Jigsaw: Under The Hood" >>>>>> presentations. The use case just isn't supported "out of the box" by the 'java' >>>>>> launcher for JARs on the modulepath. >>>>>> >>>>>> Alex >>> >> >> -- >> - DML > -- - DML From Alan.Bateman at oracle.com Thu Sep 1 13:59:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Sep 2016 14:59:27 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> On 01/09/2016 13:29, David M. Lloyd wrote: > It seems like there is no good reason why the application modules > aren't loaded with classloader-per-module now. The platform stuff > could all be in one, but the application stuff? Problems like this > are going to come up a lot otherwise; let's consider making that change. If we were just dealing with a graph of explicit modules they it may be an option, assuming you get over all the issues that arise when arranging visibility this way. You might remember "module mode" in the original exploratory phase of Project Jigsaw for example. The issue is of course that there is lot more in picture, esp. when you have the unnamed module (= class path) reading all modules, also automatic modules that bridge to the class path (and so read the unnamed module). Then add upgradable modules into the picture, ... and you will quickly start to see there is a lot more to this, not to mind the risk of circular delegation. So I think what we have ended up with sane and not difficult to explain. It favors migration and good interop over green field. Sure, there will be periodic complaints when people try to deploy modules with overlapping packages on the application module path. Anyone using Maven Shade Plugin and the like can continue to do this. Finally, it's not hard to create your own "launcher" that instantiates the configuration with Layer.defineModulesWithManyLoaders if you really want. -Alan From cowwoc at bbs.darktech.org Thu Sep 1 14:28:56 2016 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 1 Sep 2016 07:28:56 -0700 (MST) Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: <27313e73-2023-4906-e361-743e1182b28c@bbs.darktech.org> > What Sun and now Oracle are continuing to do, is create more stuff > that is nothing like what everyone else is doing with modularity and > instead create something that is orthogonal to most peoples problem > spaces and in the end creates tremendously more ?work? for nothing > more than compatibility with the new ?JVM? environment. A big +1. The cost/benefit of Jigsaw without version-awareness is very poor for end-users. Our long-term goal should be to "import" the best ideas from existing module systems in the Java platform over time. No one is expecting you to do this from day one, but the fact that "requires" does not take a constant version number from day one prevents this kind of evolution from ever taking place. On 2016-09-01 10:00 AM, Alan Bateman [via jigsaw-dev] wrote: > So I think what we have ended up with sane and not difficult to explain. > It favors migration and good interop over green field. Sure, there will > be periodic complaints when people try to deploy modules with > overlapping packages on the application module path. Anyone using Maven > Shade Plugin and the like can continue to do this. Finally, it's not > hard to create your own "launcher" that instantiates the configuration > with Layer.defineModulesWithManyLoaders if you really want. It would help if you could publish a sample "launcher" to show people how easy it really is. This won't resolve my outstanding problem with the specification (lack of a version number in "requires") but at least then we can move the discussion to whether a (simple) concrete implementation is able to do what we want. Gili On 2016-09-01 9:24 AM, Gregg Wonderly [via jigsaw-dev] wrote: > The important detail for me, is that ClassLoader per module, with the > current Class resolution scheme (this ClassLoader and whatever I can > find in the parent), provides a lot of issues. The ?custom > ClassLoaders? or ?containers like OSGi? remarks point at the ?us and > them? attitude that is pretty prevalent in this conversation. The > majority of developers are looking for a module system that is not an > ?us or them? proposition. These ?all or nothing? compromises are > what create the ?hell? that dominates conversations here. What we all > want to be able to do, is write software once, target it to ?THE Java > platform?, and be done. > > What Sun and now Oracle are continuing to do, is create more stuff > that is nothing like what everyone else is doing with modularity and > instead create something that is orthogonal to most peoples problem > spaces and in the end creates tremendously more ?work? for nothing > more than compatibility with the new ?JVM? environment. > > The real goal here needs to be making all of the other module and > container systems obsolete. Those systems should ?want? to provide > support for the awesome, new module system that will make in > unnecessary for them to roll their own details any longer. > > Yes, that is a long road and a tall measure for success. But frankly, > even the lack of any visibility of the style of modules that Netbeans > has used for decades makes it clear that this groups view at Oracle is > extremely narrow and perhaps even more uninformed about what the > community actually needs. > > Gregg > > > On Sep 1, 2016, at 7:29 AM, David M. Lloyd <[hidden email] > > wrote: > > > > It seems like there is no good reason why the application modules > aren't loaded with classloader-per-module now. The platform stuff > could all be in one, but the application stuff? Problems like this > are going to come up a lot otherwise; let's consider making that change. > > > > On 08/31/2016 07:45 PM, Neil Bartlett wrote: > >> Remi, > >> > >> Actually I don?t think that statically linking will work. This > would produce modules that have overlapping private (non-exported) > packages, and such modules also cannot be used in Java 9 on the > modulepath. > >> > >> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by > creating two modules both containing a private package > org.example.util. The following exception resulted: > java.lang.reflect.LayerInstantiationException: Package > org.example.util in both module a and module b. > >> > >> Again this could be ?solved? by using custom ClassLoaders or a > ClassLoader-based module system like OSGi on Java 9. > >> > >> Neil > >> > >> > >> > >>> On 31 Aug 2016, at 20:28, Remi Forax <[hidden email] > > wrote: > >>> > >>> The other solution is to statically link the right version of > slf4j inside guava and jsoup. > >>> A tool like jarjar can be updated to merge two modular jars (merge > two module-info). > >>> > >>> cheers, > >>> R?mi > >>> > >>> ----- Mail original ----- > >>>> De: "Neil Bartlett" <[hidden email] > > > >>>> ?: [hidden email] > , "Alex Buckley" > <[hidden email] > > >>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email] > > > >>>> Envoy?: Mercredi 31 Ao?t 2016 20:54:44 > >>>> Objet: Re: Multiple versions of a non-exported dependency > >>> > >>>> Gili, > >>>> > >>>> As Alex points out: your use-case can be supported in Java 9 but > only with the > >>>> addition of custom ClassLoaders, or by using an existing > ClassLoader-based > >>>> module system such as OSGi. > >>>> > >>>> The same is also true of Java 8, and Java 7, etc. > >>>> > >>>> Regards, > >>>> Neil > >>>> > >>>> > >>>>> On 31 Aug 2016, at 19:29, Alex Buckley <[hidden email] > > wrote: > >>>>> > >>>>> On 8/31/2016 10:56 AM, cowwoc wrote: > >>>>>> I recently became aware of the fact that the Jigsaw > specification declared > >>>>>> "version-selection" as a non-goal. While I understand how we > ended up here, > >>>>>> I am hoping that you were able to support the following (very > common) > >>>>>> use-case: > >>>>>> > >>>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". > >>>>>> * Module "Guava" depends on module slf4j version 1 (requires > but does not > >>>>>> export it). > >>>>>> * Module "JSoup" depends on module slf4j version 2 (requires > but does not > >>>>>> export it). > >>>>>> * slf4j version 2 and is not backwards-compatible with version 1. > >>>>>> > >>>>>> What happens at runtime? Will Jigsaw (out of the box, without > 3rd-party > >>>>>> tools like Maven or OSGI) be smart enough to provide different > versions of > >>>>>> slf4j to "Guava" and "JSoup"? > >>>>> > >>>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not > "re-export" it > >>>>> a.k.a. 'requires public'.) > >>>>> > >>>>> This use case isn't possible on JDK 8 for JARs on the classpath, > and it's not > >>>>> supported on JDK 9 for modular JARs on the modulepath: > >>>>> > >>>>> - If you have two versions of a modular JAR slf4j.jar in > different directories > >>>>> on the modulepath, then the first one to be found will dominate, > and that's > >>>>> what will be resolved for both Guava and JSoup. > >>>>> > >>>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on > the modulepath, > >>>>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then > launching 'java > >>>>> -m HelloWorld' will fail. The boot layer will refuse to map the > "same" packages > >>>>> from different slf4j_v* modules to the application class loader. > >>>>> > >>>>> The use case _is_ supported on JDK 9 for modular JARs loaded > into custom loaders > >>>>> of custom layers. That is, the Java Platform Module System is > perfectly capable > >>>>> of supporting the use case -- please see any of my "Jigsaw: > Under The Hood" > >>>>> presentations. The use case just isn't supported "out of the > box" by the 'java' > >>>>> launcher for JARs on the modulepath. > >>>>> > >>>>> Alex > >> > > > > -- > > - DML > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713387.html > > To unsubscribe from Multiple versions of a non-exported dependency, > click here > . > NAML > > -- View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713390.html Sent from the jigsaw-dev mailing list archive at Nabble.com. From david.lloyd at redhat.com Thu Sep 1 14:35:01 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 1 Sep 2016 09:35:01 -0500 Subject: Multiple versions of a non-exported dependency In-Reply-To: <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> Message-ID: <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> On 09/01/2016 08:59 AM, Alan Bateman wrote: > On 01/09/2016 13:29, David M. Lloyd wrote: > >> It seems like there is no good reason why the application modules >> aren't loaded with classloader-per-module now. The platform stuff >> could all be in one, but the application stuff? Problems like this >> are going to come up a lot otherwise; let's consider making that change. > If we were just dealing with a graph of explicit modules they it may be > an option, assuming you get over all the issues that arise when > arranging visibility this way. You might remember "module mode" in the > original exploratory phase of Project Jigsaw for example. > > The issue is of course that there is lot more in picture, esp. when you > have the unnamed module (= class path) reading all modules, also > automatic modules that bridge to the class path (and so read the unnamed > module). Then add upgradable modules into the picture, ... and you will > quickly start to see there is a lot more to this, not to mind the risk > of circular delegation. Risk? If the modules don't have circular delegation then the class loaders won't; but anyway I don't understand *at all* why circular delegation in class loaders is a problem (we do this today and it has worked great since Java 7, and there's no particular magic necessary to do so). And in any event circular delegation in modules *should* be allowed, full stop; there's no good reason not to allow it (especially given the very-super-eager-loading behavior of module layers). Again we do this today and it's fine. > So I think what we have ended up with sane and not difficult to explain. > It favors migration and good interop over green field. Yeah having the class path remain on the legacy application class loader is demonstrably better for interop. But new modules? Does that make sense? > Sure, there will > be periodic complaints when people try to deploy modules with > overlapping packages on the application module path. Anyone using Maven > Shade Plugin and the like can continue to do this. Finally, it's not > hard to create your own "launcher" that instantiates the configuration > with Layer.defineModulesWithManyLoaders if you really want. I think many people will do this. The benefits of modules are diminishing if you don't actually get this level of isolation by default. And I think that it's much harder to imagine a real interop problem that could arise from it than it is to imagine a real problem that will occur from not doing it. Anyway using interoperability as an argument is very weak as long as "export dynamic *" or any variation thereof is considered to be an acceptable solution to #ReflectiveAccessToNonExportedTypes. In order to have proper interoperability for any reflection-using or reflected module, you have to do this, which defeats the primary security measure of modules. Isn't this a much more likely interop problem than putting modules (something that never existed before) into their own class loaders? -- - DML From greggwon at cox.net Thu Sep 1 15:12:08 2016 From: greggwon at cox.net (Gregg Wonderly) Date: Thu, 1 Sep 2016 10:12:08 -0500 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: Why I was referring to is how will modules find classes from other modules? How will the different version of the same package namespace that Gili was talking about be hidden? In other words, you can only make them all visible by using a single class loader, unless there is a DAG of dependencies that naturally falls out, because all we have is ClassLoaders parent as the pointer to other interesting detail. How will definedModulesWithManyLoaders make it possible for all of the correct details to be visible? Some explicit example detail: module A uses l4j logging in module B module C uses l4j logging in module D module E is a standalone module A and C exchange data objects defined in E +? B ? A | + E | +? D ? C This graph you can draw today with ClassLoader parent references. But, there are more complicated graphs that fall out from less simple needs. It?s this specific issue of still not trying to provide support for versions and for arranging the module dependencies more explicitly through the use of version as part of the package name namespace which Gili is trying to speak to I feel. Since B and D are the same package name, you have to hide them from each other in separate class loaders, obviously. But the Graph from C to E and A to E is not always direct and can in some cases not be possible with a single instance of the jar. That breaks static class data designs if you create two copies in separate loaders. Gregg > On Sep 1, 2016, at 8:37 AM, David M. Lloyd wrote: > > You've missed the point I'm afraid. I'm just talking about having the launcher use (the equivalent of) java.lang.reflect.Layer#defineModulesWithManyLoaders instead of (the equivalent of) java.lang.reflect.Layer#defineModulesWithOneLoader. (The launcher actually uses the slightly lower level defineModules() method I think, but really what I'm suggesting is to update the function to assign new class loaders for named modules instead of reusing the same one.) > > On 09/01/2016 08:23 AM, Gregg Wonderly wrote: >> The important detail for me, is that ClassLoader per module, with the current Class resolution scheme (this ClassLoader and whatever I can find in the parent), provides a lot of issues. The ?custom ClassLoaders? or ?containers like OSGi? remarks point at the ?us and them? attitude that is pretty prevalent in this conversation. The majority of developers are looking for a module system that is not an ?us or them? proposition. These ?all or nothing? compromises are what create the ?hell? that dominates conversations here. What we all want to be able to do, is write software once, target it to ?THE Java platform?, and be done. >> >> What Sun and now Oracle are continuing to do, is create more stuff that is nothing like what everyone else is doing with modularity and instead create something that is orthogonal to most peoples problem spaces and in the end creates tremendously more ?work? for nothing more than compatibility with the new ?JVM? environment. >> >> The real goal here needs to be making all of the other module and container systems obsolete. Those systems should ?want? to provide support for the awesome, new module system that will make in unnecessary for them to roll their own details any longer. >> >> Yes, that is a long road and a tall measure for success. But frankly, even the lack of any visibility of the style of modules that Netbeans has used for decades makes it clear that this groups view at Oracle is extremely narrow and perhaps even more uninformed about what the community actually needs. >> >> Gregg >> >>> On Sep 1, 2016, at 7:29 AM, David M. Lloyd wrote: >>> >>> It seems like there is no good reason why the application modules aren't loaded with classloader-per-module now. The platform stuff could all be in one, but the application stuff? Problems like this are going to come up a lot otherwise; let's consider making that change. >>> >>> On 08/31/2016 07:45 PM, Neil Bartlett wrote: >>>> Remi, >>>> >>>> Actually I don?t think that statically linking will work. This would produce modules that have overlapping private (non-exported) packages, and such modules also cannot be used in Java 9 on the modulepath. >>>> >>>> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two modules both containing a private package org.example.util. The following exception resulted: java.lang.reflect.LayerInstantiationException: Package org.example.util in both module a and module b. >>>> >>>> Again this could be ?solved? by using custom ClassLoaders or a ClassLoader-based module system like OSGi on Java 9. >>>> >>>> Neil >>>> >>>> >>>> >>>>> On 31 Aug 2016, at 20:28, Remi Forax wrote: >>>>> >>>>> The other solution is to statically link the right version of slf4j inside guava and jsoup. >>>>> A tool like jarjar can be updated to merge two modular jars (merge two module-info). >>>>> >>>>> cheers, >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Neil Bartlett" >>>>>> ?: cowwoc at bbs.darktech.org, "Alex Buckley" >>>>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" >>>>>> Envoy?: Mercredi 31 Ao?t 2016 20:54:44 >>>>>> Objet: Re: Multiple versions of a non-exported dependency >>>>> >>>>>> Gili, >>>>>> >>>>>> As Alex points out: your use-case can be supported in Java 9 but only with the >>>>>> addition of custom ClassLoaders, or by using an existing ClassLoader-based >>>>>> module system such as OSGi. >>>>>> >>>>>> The same is also true of Java 8, and Java 7, etc. >>>>>> >>>>>> Regards, >>>>>> Neil >>>>>> >>>>>> >>>>>>> On 31 Aug 2016, at 19:29, Alex Buckley wrote: >>>>>>> >>>>>>> On 8/31/2016 10:56 AM, cowwoc wrote: >>>>>>>> I recently became aware of the fact that the Jigsaw specification declared >>>>>>>> "version-selection" as a non-goal. While I understand how we ended up here, >>>>>>>> I am hoping that you were able to support the following (very common) >>>>>>>> use-case: >>>>>>>> >>>>>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>>>>>>> * Module "Guava" depends on module slf4j version 1 (requires but does not >>>>>>>> export it). >>>>>>>> * Module "JSoup" depends on module slf4j version 2 (requires but does not >>>>>>>> export it). >>>>>>>> * slf4j version 2 and is not backwards-compatible with version 1. >>>>>>>> >>>>>>>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party >>>>>>>> tools like Maven or OSGI) be smart enough to provide different versions of >>>>>>>> slf4j to "Guava" and "JSoup"? >>>>>>> >>>>>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it >>>>>>> a.k.a. 'requires public'.) >>>>>>> >>>>>>> This use case isn't possible on JDK 8 for JARs on the classpath, and it's not >>>>>>> supported on JDK 9 for modular JARs on the modulepath: >>>>>>> >>>>>>> - If you have two versions of a modular JAR slf4j.jar in different directories >>>>>>> on the modulepath, then the first one to be found will dominate, and that's >>>>>>> what will be resolved for both Guava and JSoup. >>>>>>> >>>>>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the modulepath, >>>>>>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java >>>>>>> -m HelloWorld' will fail. The boot layer will refuse to map the "same" packages >>>>>>> from different slf4j_v* modules to the application class loader. >>>>>>> >>>>>>> The use case _is_ supported on JDK 9 for modular JARs loaded into custom loaders >>>>>>> of custom layers. That is, the Java Platform Module System is perfectly capable >>>>>>> of supporting the use case -- please see any of my "Jigsaw: Under The Hood" >>>>>>> presentations. The use case just isn't supported "out of the box" by the 'java' >>>>>>> launcher for JARs on the modulepath. >>>>>>> >>>>>>> Alex >>>> >>> >>> -- >>> - DML >> > > -- > - DML From greggwon at cox.net Thu Sep 1 15:34:04 2016 From: greggwon at cox.net (Gregg Wonderly) Date: Thu, 1 Sep 2016 10:34:04 -0500 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> Message-ID: <160158D2-4E53-4F5F-9D6E-40CD42BA8A8F@cox.net> Trying not to distract this conversation away from the details? In the end, the concept of ?micro services? and things like ?Jini? discovery can allow smaller distribution of systems in single class loaders without conflicts. But still, there is the static data design issue. I have a Jini discovery based desktop application that I?ve used for more than a decade to ?find? services on my network, download their proxy and associated UI, and use them. Those applications are all separate class loaders and do not interact inside of my desktop application. If they need to interact, they do so via their services which interact with other services through discovery of that service, download of the proxy and calls out through the jointly know interface/class name which was used in the lookup criteria. All of this has explicit version management because the Jar file names are well known and include version numbers in them. In Jini, there is a lot of class loading happening with downloaded code, but it is a well formed tree structure inside of my desktop application because each application is using a specific version of jars in its setting of the exported class details. Jigsaw is orthogonal to what I am doing with Jini because Jigsaw is about starting the application, not extending the application as the Jini discovery and downloads do. However, I am trying to point out how the direct references to version details in the design and operation of the system allow for multiple versions to coexist trivially and be managed explicitly to help the system continue to function correctly. If I have an application deployed twice, with two different sets of jars because of version changes, and my desktop application picks one of them at random to use, it won?t matter if I in fact try to open both instances by explicitly knowing how to do that because the class loader design keeps them separated and the exported class loader detail identifies the specifics need to make each function as a separate application within my desktop container. I don?t know what base of users and what paradigms of deployments the Jigsaw team considered. It?s clear that they focused first on modularity of the JVM. It?s not obvious that how other module systems unrelated to pluggable functionality that the JVM is trying to separate were considered. The separation of detail that is not referenced is a simple modularization detail. The isolation of detail that should not be referenced is a different modularization detail which just doesn?t seem to be completely considered for any detail other than ?exposure? as opposed to ?compatibility? which is what ?Version? points to. Gregg > On Sep 1, 2016, at 10:12 AM, Gregg Wonderly wrote: > > Why I was referring to is how will modules find classes from other modules? How will the different version of the same package namespace that Gili was talking about be hidden? In other words, you can only make them all visible by using a single class loader, unless there is a DAG of dependencies that naturally falls out, because all we have is ClassLoaders parent as the pointer to other interesting detail. > > How will definedModulesWithManyLoaders make it possible for all of the correct details to be visible? > > Some explicit example detail: > > module A uses l4j logging in module B > > module C uses l4j logging in module D > > module E is a standalone module > > A and C exchange data objects defined in E > > +? B ? A > | > + E > | > +? D ? C > > This graph you can draw today with ClassLoader parent references. But, there are more complicated graphs that fall out from less simple needs. It?s this specific issue of still not trying to provide support for versions and for arranging the module dependencies more explicitly through the use of version as part of the package name namespace which Gili is trying to speak to I feel. > > Since B and D are the same package name, you have to hide them from each other in separate class loaders, obviously. But the Graph from C to E and A to E is not always direct and can in some cases not be possible with a single instance of the jar. That breaks static class data designs if you create two copies in separate loaders. > > Gregg > >> On Sep 1, 2016, at 8:37 AM, David M. Lloyd wrote: >> >> You've missed the point I'm afraid. I'm just talking about having the launcher use (the equivalent of) java.lang.reflect.Layer#defineModulesWithManyLoaders instead of (the equivalent of) java.lang.reflect.Layer#defineModulesWithOneLoader. (The launcher actually uses the slightly lower level defineModules() method I think, but really what I'm suggesting is to update the function to assign new class loaders for named modules instead of reusing the same one.) >> >> On 09/01/2016 08:23 AM, Gregg Wonderly wrote: >>> The important detail for me, is that ClassLoader per module, with the current Class resolution scheme (this ClassLoader and whatever I can find in the parent), provides a lot of issues. The ?custom ClassLoaders? or ?containers like OSGi? remarks point at the ?us and them? attitude that is pretty prevalent in this conversation. The majority of developers are looking for a module system that is not an ?us or them? proposition. These ?all or nothing? compromises are what create the ?hell? that dominates conversations here. What we all want to be able to do, is write software once, target it to ?THE Java platform?, and be done. >>> >>> What Sun and now Oracle are continuing to do, is create more stuff that is nothing like what everyone else is doing with modularity and instead create something that is orthogonal to most peoples problem spaces and in the end creates tremendously more ?work? for nothing more than compatibility with the new ?JVM? environment. >>> >>> The real goal here needs to be making all of the other module and container systems obsolete. Those systems should ?want? to provide support for the awesome, new module system that will make in unnecessary for them to roll their own details any longer. >>> >>> Yes, that is a long road and a tall measure for success. But frankly, even the lack of any visibility of the style of modules that Netbeans has used for decades makes it clear that this groups view at Oracle is extremely narrow and perhaps even more uninformed about what the community actually needs. >>> >>> Gregg >>> >>>> On Sep 1, 2016, at 7:29 AM, David M. Lloyd wrote: >>>> >>>> It seems like there is no good reason why the application modules aren't loaded with classloader-per-module now. The platform stuff could all be in one, but the application stuff? Problems like this are going to come up a lot otherwise; let's consider making that change. >>>> >>>> On 08/31/2016 07:45 PM, Neil Bartlett wrote: >>>>> Remi, >>>>> >>>>> Actually I don?t think that statically linking will work. This would produce modules that have overlapping private (non-exported) packages, and such modules also cannot be used in Java 9 on the modulepath. >>>>> >>>>> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two modules both containing a private package org.example.util. The following exception resulted: java.lang.reflect.LayerInstantiationException: Package org.example.util in both module a and module b. >>>>> >>>>> Again this could be ?solved? by using custom ClassLoaders or a ClassLoader-based module system like OSGi on Java 9. >>>>> >>>>> Neil >>>>> >>>>> >>>>> >>>>>> On 31 Aug 2016, at 20:28, Remi Forax wrote: >>>>>> >>>>>> The other solution is to statically link the right version of slf4j inside guava and jsoup. >>>>>> A tool like jarjar can be updated to merge two modular jars (merge two module-info). >>>>>> >>>>>> cheers, >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Neil Bartlett" >>>>>>> ?: cowwoc at bbs.darktech.org, "Alex Buckley" >>>>>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" >>>>>>> Envoy?: Mercredi 31 Ao?t 2016 20:54:44 >>>>>>> Objet: Re: Multiple versions of a non-exported dependency >>>>>> >>>>>>> Gili, >>>>>>> >>>>>>> As Alex points out: your use-case can be supported in Java 9 but only with the >>>>>>> addition of custom ClassLoaders, or by using an existing ClassLoader-based >>>>>>> module system such as OSGi. >>>>>>> >>>>>>> The same is also true of Java 8, and Java 7, etc. >>>>>>> >>>>>>> Regards, >>>>>>> Neil >>>>>>> >>>>>>> >>>>>>>> On 31 Aug 2016, at 19:29, Alex Buckley wrote: >>>>>>>> >>>>>>>> On 8/31/2016 10:56 AM, cowwoc wrote: >>>>>>>>> I recently became aware of the fact that the Jigsaw specification declared >>>>>>>>> "version-selection" as a non-goal. While I understand how we ended up here, >>>>>>>>> I am hoping that you were able to support the following (very common) >>>>>>>>> use-case: >>>>>>>>> >>>>>>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>>>>>>>> * Module "Guava" depends on module slf4j version 1 (requires but does not >>>>>>>>> export it). >>>>>>>>> * Module "JSoup" depends on module slf4j version 2 (requires but does not >>>>>>>>> export it). >>>>>>>>> * slf4j version 2 and is not backwards-compatible with version 1. >>>>>>>>> >>>>>>>>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party >>>>>>>>> tools like Maven or OSGI) be smart enough to provide different versions of >>>>>>>>> slf4j to "Guava" and "JSoup"? >>>>>>>> >>>>>>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it >>>>>>>> a.k.a. 'requires public'.) >>>>>>>> >>>>>>>> This use case isn't possible on JDK 8 for JARs on the classpath, and it's not >>>>>>>> supported on JDK 9 for modular JARs on the modulepath: >>>>>>>> >>>>>>>> - If you have two versions of a modular JAR slf4j.jar in different directories >>>>>>>> on the modulepath, then the first one to be found will dominate, and that's >>>>>>>> what will be resolved for both Guava and JSoup. >>>>>>>> >>>>>>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the modulepath, >>>>>>>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java >>>>>>>> -m HelloWorld' will fail. The boot layer will refuse to map the "same" packages >>>>>>>> from different slf4j_v* modules to the application class loader. >>>>>>>> >>>>>>>> The use case _is_ supported on JDK 9 for modular JARs loaded into custom loaders >>>>>>>> of custom layers. That is, the Java Platform Module System is perfectly capable >>>>>>>> of supporting the use case -- please see any of my "Jigsaw: Under The Hood" >>>>>>>> presentations. The use case just isn't supported "out of the box" by the 'java' >>>>>>>> launcher for JARs on the modulepath. >>>>>>>> >>>>>>>> Alex >>>>> >>>> >>>> -- >>>> - DML >>> >> >> -- >> - DML > From ropalka at redhat.com Thu Sep 1 16:34:45 2016 From: ropalka at redhat.com (Richard Opalka) Date: Thu, 1 Sep 2016 18:34:45 +0200 Subject: Multiple versions of a non-exported dependency In-Reply-To: <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> Message-ID: On 09/01/2016 03:59 PM, Alan Bateman wrote: > The issue is of course that there is lot more in picture, esp. when > you have the unnamed module (= class path) reading all modules, also > automatic modules that bridge to the class path (and so read the > unnamed module). Then add upgradable modules into the picture, ... and > you will quickly start to see there is a lot more to this, not to mind > the risk of circular delegation. Trying not to hijack this thread (and yes I am aware it is maybe too late for Jigsaw project to change it) but I'd like to share one idea. What if Jigsaw would work like this? - [A] Non-platform explicit modules (specified on --module-path) would support versions with loaders-per-module - [B] Version should be optional literal in module-info.java when declaring module dependencies for such modules - [C] UNNAMED classpath module shouldn't see non-platform explicit modules by default (users might use -XaddExports to export them explicitly with risk for split-package issue and other issues) Further I can't see the real benefit of automatic modules (they read UNNAMED module(s) and all other explicit modules). I am aware of two real world usecases it might solve: 1) to workaround licensing issues of dead java projects (where consumers are disallowed to change them in any way) 2) automatic module placed on --upgrade-module-path (to allow smooth migration for EE APIs without need to define module-info.class for them) Considering 1) (i.e. dead wrong licensed projects should die) and 2) here's final proposal point: - [D] automatic modules would be supported only in --upgrade-module-path universe without possibility to read UNNAMED modules. Since upgradeable modules replace platform modules UNNAMED classpath module would have to read/see them. Richard From Alan.Bateman at oracle.com Thu Sep 1 16:58:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Sep 2016 17:58:32 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> Message-ID: <4a02179c-9f4e-8492-f3ce-a6d8b4608905@oracle.com> On 01/09/2016 17:34, Richard Opalka wrote: > > - [C] UNNAMED classpath module shouldn't see non-platform explicit > modules by default > (users might use -XaddExports to export them explicitly with risk > for split-package issue and other issues) That is how it works, except you use --add-modules to ensure that any needed modules on the module path are resolved. > > Further I can't see the real benefit of automatic modules (they read > UNNAMED module(s) and all other explicit modules). > I am aware of two real world usecases it might solve: > 1) to workaround licensing issues of dead java projects (where > consumers are disallowed to change them in any way) > 2) automatic module placed on --upgrade-module-path (to allow smooth > migration for EE APIs without need to define module-info.class for them) Automatic modules facilitate top-level migration, you can migrate to modules without waiting for everything that you transitively depend to migrate. They also allow bridging to the class path - say where you move just your direct dependences while leaving the rest on the class path. The topic is covered in the STOMS [1] and also in the Advanced Modularity talks at JavaOne and Devoxx last year [2]. -Alan [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/ [1] http://openjdk.java.net/projects/jigsaw/talks/ From Alan.Bateman at oracle.com Thu Sep 1 17:11:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Sep 2016 18:11:16 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> Message-ID: On 01/09/2016 15:35, David M. Lloyd wrote: > > Yeah having the class path remain on the legacy application class > loader is demonstrably better for interop. But new modules? Does > that make sense? Yes, specifically automatic modules where a JAR file is moved from the class path to module path without any changes. Also any library that is migrated to an explicit module. If the library is used to being on the class path today, and it's not in a world of hurt that is split packages or cycles, then the effort to make it an explicit module might be minimal. > : > > Anyway using interoperability as an argument is very weak as long as > "export dynamic *" or any variation thereof is considered to be an > acceptable solution to #ReflectiveAccessToNonExportedTypes. In order > to have proper interoperability for any reflection-using or reflected > module, you have to do this, which defeats the primary security > measure of modules. Isn't this a much more likely interop problem > than putting modules (something that never existed before) into their > own class loaders? Modules might be new but a lot existing code that will be migrated. I don't wish to engage on the #ReflectiveAccessToNonExportedTypes topic in this thread, mostly because that topic is still open on the JSR list and there are several overlapping threads already. -Alan From ropalka at redhat.com Thu Sep 1 19:33:45 2016 From: ropalka at redhat.com (Richard Opalka) Date: Thu, 1 Sep 2016 21:33:45 +0200 Subject: Multiple versions of a non-exported dependency In-Reply-To: <4a02179c-9f4e-8492-f3ce-a6d8b4608905@oracle.com> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <4a02179c-9f4e-8492-f3ce-a6d8b4608905@oracle.com> Message-ID: <66c66a61-7241-0980-1c77-1a9cd70678df@redhat.com> On 09/01/2016 06:58 PM, Alan Bateman wrote: > On 01/09/2016 17:34, Richard Opalka wrote: > Further I can't see the real benefit of automatic modules (they read > UNNAMED module(s) and all other explicit modules). >> I am aware of two real world usecases it might solve: >> 1) to workaround licensing issues of dead java projects (where >> consumers are disallowed to change them in any way) >> 2) automatic module placed on --upgrade-module-path (to allow smooth >> migration for EE APIs without need to define module-info.class for them) > Automatic modules facilitate top-level migration, you can migrate to > modules without waiting for everything that you transitively depend to > migrate. They also allow bridging to the class path - say where you > move just your direct dependences while leaving the rest on the class > path. The topic is covered in the STOMS [1] and also in the Advanced > Modularity talks at JavaOne and Devoxx last year [2]. > > -Alan > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/ > [1] http://openjdk.java.net/projects/jigsaw/talks/ Yes, I'm familiar and aware of these. What I meant is: Is the benefit of incremental migration (automatic modules provide) that valuable? What's bad with "modularize all or nothing" kind of migration? There would be no need for bridges to the classpath if automatic modules would disappear. Richard From cowwoc at bbs.darktech.org Thu Sep 1 20:04:13 2016 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 1 Sep 2016 13:04:13 -0700 (MST) Subject: Multiple versions of a non-exported dependency In-Reply-To: <66c66a61-7241-0980-1c77-1a9cd70678df@redhat.com> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <4a02179c-9f4e-8492-f3ce-a6d8b4608905@oracle.com> <66c66a61-7241-0980-1c77-1a9cd70678df@redhat.com> Message-ID: <30f6934f-82d2-e197-e6e1-7611330bd8a1@bbs.darktech.org> Another possibility (not saying it's better, just putting it out there) is to do the following: 1. Provide a tool like "javah" that would generate module-info.java for non-modularized JAR files. 2. Provide a mechanism to "glue" the generated module-info files to the original non-modularized JAR files without modification (as if the files were inside the JAR file, but they aren't). 3. Developers could use the generated templates as-is or customize them further after generation. This way everything would be a real module and you'd get extra customization that is currently not available with automatic modules. This process moves the "glue" from runtime to package-time. Gili On 2016-09-01 3:34 PM, Richard Opalka [via jigsaw-dev] wrote: > On 09/01/2016 06:58 PM, Alan Bateman wrote: > > > On 01/09/2016 17:34, Richard Opalka wrote: > > Further I can't see the real benefit of automatic modules (they read > > UNNAMED module(s) and all other explicit modules). > >> I am aware of two real world usecases it might solve: > >> 1) to workaround licensing issues of dead java projects (where > >> consumers are disallowed to change them in any way) > >> 2) automatic module placed on --upgrade-module-path (to allow smooth > >> migration for EE APIs without need to define module-info.class for > them) > > Automatic modules facilitate top-level migration, you can migrate to > > modules without waiting for everything that you transitively depend to > > migrate. They also allow bridging to the class path - say where you > > move just your direct dependences while leaving the rest on the class > > path. The topic is covered in the STOMS [1] and also in the Advanced > > Modularity talks at JavaOne and Devoxx last year [2]. > > > > -Alan > > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/ > > [1] http://openjdk.java.net/projects/jigsaw/talks/ > Yes, I'm familiar and aware of these. What I meant is: > > Is the benefit of incremental migration (automatic modules provide) that > valuable? > What's bad with "modularize all or nothing" kind of migration? > There would be no need for bridges to the classpath if automatic modules > would disappear. > > Richard > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713397.html > > To unsubscribe from Multiple versions of a non-exported dependency, > click here > . > NAML > > -- View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713398.html Sent from the jigsaw-dev mailing list archive at Nabble.com. From patrick at reini.net Thu Sep 1 20:06:41 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 1 Sep 2016 22:06:41 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream Message-ID: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Hi Alan, Hi Paul, Here is the first revision of the implementation based on our earlier conversation. http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 - Patrick From ropalka at redhat.com Thu Sep 1 21:02:04 2016 From: ropalka at redhat.com (Richard Opalka) Date: Thu, 1 Sep 2016 23:02:04 +0200 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> Message-ID: <94efbab4-997c-ce2a-8ad5-0689843d7cf7@redhat.com> Reformulating the idea to make it more clear: On 09/01/2016 06:34 PM, Richard Opalka wrote: > On 09/01/2016 03:59 PM, Alan Bateman wrote: >> The issue is of course that there is lot more in picture, esp. when >> you have the unnamed module (= class path) reading all modules, also >> automatic modules that bridge to the class path (and so read the >> unnamed module). Then add upgradable modules into the picture, ... >> and you will quickly start to see there is a lot more to this, not to >> mind the risk of circular delegation. > Trying not to hijack this thread (and yes I am aware it is maybe too > late for Jigsaw project to change it) but I'd like to share one idea. > > What if Jigsaw would work like this? > - [A] Non-platform explicit modules (specified on --module-path) > would support versions with loaders-per-module > - [B] Version should be optional literal in module-info.java when > declaring module dependencies for such modules > - [C] UNNAMED classpath module shouldn't see non-platform explicit > modules by default > (users might use -XaddExports to export them explicitly with risk > for split-package issue and other issues) > > Further I can't see the real benefit of automatic modules (they read > UNNAMED module(s) and all other explicit modules). > I am aware of two real world usecases it might solve: > 1) to workaround licensing issues of dead java projects (where > consumers are disallowed to change them in any way) > 2) automatic module placed on --upgrade-module-path (to allow smooth > migration for EE APIs without need to define module-info.class for them) > > Considering 1) (i.e. dead wrong licensed projects should die) and 2) > here's final proposal point: > - [D] automatic modules would be supported only in > --upgrade-module-path universe without possibility to read UNNAMED > modules. > Since upgradeable modules replace platform modules UNNAMED > classpath module would have to read/see them. > > Richard In order for Jigsaw to support multiple module versions (not saying it should do so, just reasoning about it) the following steps would be necessary: * Disconnect Modularized world from Classpath world (eliminate automatic modules) * All platform provided modules would be "unversioned" and unique (they'd have implicit platform version, e.g. 9-ea) * Separate graphs of "user provided explicit modules universe" (provided via --module-path option) from "platform modules universe" (provided in JDK image) * User provided explicit modules would support multiple versions via loader-per-module (including explicit module version string in module-info.java) * Update module-info.java format to allow both to specify explicit module version and to allow dependencies on explicit module versions (e.g. "requires module.foo 1.0) * "requires public" would be disallowed for explicitly versioned modules * Update module graph mapping to the VM to take module version string into account Richard From mandy.chung at oracle.com Fri Sep 2 04:39:33 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:39:33 +0000 Subject: hg: jigsaw/jake: 2 new changesets Message-ID: <201609020439.u824dXEY002584@aojmv0008.oracle.com> Changeset: 7ef51cfe867e Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7ef51cfe867e Added tag jdk-9+134 for changeset 065724348690 ! .hgtags Changeset: 8fa615724c4f Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8fa615724c4f Merge ! common/autoconf/generated-configure.sh From mandy.chung at oracle.com Fri Sep 2 04:39:41 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:39:41 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201609020439.u824df3B002694@aojmv0008.oracle.com> Changeset: 094d0db606db Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/094d0db606db Added tag jdk-9+134 for changeset 1a497f5ca0cf ! .hgtags Changeset: 11ceba666902 Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/11ceba666902 Merge From mandy.chung at oracle.com Fri Sep 2 04:39:49 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:39:49 +0000 Subject: hg: jigsaw/jake/hotspot: 4 new changesets Message-ID: <201609020439.u824dnvr002832@aojmv0008.oracle.com> Changeset: 091445016861 Author: jwilhelm Date: 2016-08-19 17:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/091445016861 8164124: [BACKOUT] G1 does not implement millis_since_last_gc which is needed by RMI GC Reviewed-by: jprovino ! src/share/vm/gc/g1/g1Analytics.cpp ! src/share/vm/gc/g1/g1Analytics.hpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1DefaultPolicy.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp Changeset: b8b694c6b4d2 Author: lana Date: 2016-08-25 22:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b8b694c6b4d2 Merge Changeset: d785dfdb7bcc Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d785dfdb7bcc Added tag jdk-9+134 for changeset b8b694c6b4d2 ! .hgtags Changeset: 25cc45ea8cdb Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/25cc45ea8cdb Merge ! .hgtags From mandy.chung at oracle.com Fri Sep 2 04:40:01 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:40:01 +0000 Subject: hg: jigsaw/jake/jaxp: 5 new changesets Message-ID: <201609020440.u824e15c002972@aojmv0008.oracle.com> Changeset: 4414c22d531e Author: joehw Date: 2016-08-23 13:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4414c22d531e 8157797: SAX Parser throws incorrect error on invalid xml Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java + test/javax/xml/jaxp/unittest/parsers/HandleError.java Changeset: 6e7c24624fc9 Author: lana Date: 2016-08-25 22:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6e7c24624fc9 Merge Changeset: 1c6c21d87aa4 Author: joehw Date: 2016-08-26 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1c6c21d87aa4 8163232: Catalog API: Consolidating CatalogResolver to support all XML Resolvers Reviewed-by: dfuchs, lancea ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EntityResolverWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/StaxEntityResolverWrapper.java ! src/java.xml/share/classes/javax/xml/catalog/Catalog.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java - src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolver.java - src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolverImpl.java ! src/java.xml/share/classes/javax/xml/catalog/Util.java ! test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java ! test/javax/xml/jaxp/functional/catalog/DefaultFeaturesTest.java ! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java ! test/javax/xml/jaxp/functional/catalog/DelegatePublicTest.java ! test/javax/xml/jaxp/functional/catalog/DelegateSystemTest.java ! test/javax/xml/jaxp/functional/catalog/DelegateUriTest.java ! test/javax/xml/jaxp/functional/catalog/GroupTest.java ! test/javax/xml/jaxp/functional/catalog/LoadCatalogTest.java ! test/javax/xml/jaxp/functional/catalog/NextCatalogTest.java ! test/javax/xml/jaxp/functional/catalog/NormalizationTest.java ! test/javax/xml/jaxp/functional/catalog/PreferFeatureTest.java ! test/javax/xml/jaxp/functional/catalog/PreferTest.java ! test/javax/xml/jaxp/functional/catalog/PublicFamilyTest.java ! test/javax/xml/jaxp/functional/catalog/PublicTest.java ! test/javax/xml/jaxp/functional/catalog/ResolveFeatureTest.java ! test/javax/xml/jaxp/functional/catalog/RewriteSystemTest.java ! test/javax/xml/jaxp/functional/catalog/RewriteUriTest.java ! test/javax/xml/jaxp/functional/catalog/SpecifyCatalogTest.java ! test/javax/xml/jaxp/functional/catalog/SystemFamilyTest.java ! test/javax/xml/jaxp/functional/catalog/SystemSuffixTest.java ! test/javax/xml/jaxp/functional/catalog/SystemTest.java ! test/javax/xml/jaxp/functional/catalog/UriFamilyTest.java ! test/javax/xml/jaxp/functional/catalog/UriSuffixTest.java ! test/javax/xml/jaxp/functional/catalog/UriTest.java ! test/javax/xml/jaxp/functional/catalog/UrnUnwrappingTest.java ! test/javax/xml/jaxp/functional/catalog/ValidateCatalogTest.java ! test/javax/xml/jaxp/functional/catalog/catalogFiles/deferFeature.xml ! test/javax/xml/jaxp/functional/catalog/catalogFiles/uri.xml ! test/javax/xml/jaxp/functional/catalog/catalogFiles/uriFamily.xml ! test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.java ! test/javax/xml/jaxp/libs/catalog/CatalogTestUtils.java ! test/javax/xml/jaxp/libs/catalog/ResolutionChecker.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport.xml ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport1.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport2.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport3.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport4.java + test/javax/xml/jaxp/unittest/catalog/CatalogSupport5.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java + test/javax/xml/jaxp/unittest/catalog/CatalogSupport_uri.xml ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java ! test/javax/xml/jaxp/unittest/catalog/catalog.xml + test/javax/xml/jaxp/unittest/catalog/catalog_uri.xml + test/javax/xml/jaxp/unittest/catalog/delegateuri.xml ! test/javax/xml/jaxp/unittest/catalog/files/delegatecatalog.xml + test/javax/xml/jaxp/unittest/catalog/files/delegatecatalog_uri.xml + test/javax/xml/jaxp/unittest/catalog/files/delegateuri.dtd ! test/javax/xml/jaxp/unittest/catalog/system.xml Changeset: 92e63ecec33e Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/92e63ecec33e Added tag jdk-9+134 for changeset 1c6c21d87aa4 ! .hgtags Changeset: 9978b642096b Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/9978b642096b Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java From mandy.chung at oracle.com Fri Sep 2 04:40:04 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:40:04 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201609020440.u824e4J8003019@aojmv0008.oracle.com> Changeset: 22631824f551 Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/22631824f551 Added tag jdk-9+134 for changeset ab1d78d395d4 ! .hgtags Changeset: 64b7e64f3dbe Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/64b7e64f3dbe Merge From mandy.chung at oracle.com Fri Sep 2 04:40:17 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:40:17 +0000 Subject: hg: jigsaw/jake/jdk: 46 new changesets Message-ID: <201609020440.u824eJBU003106@aojmv0008.oracle.com> Changeset: 8e5362b5a18d Author: igerasim Date: 2016-08-22 22:16 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e5362b5a18d 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input Reviewed-by: scolebourne, ntv, coffeys ! src/java.base/share/classes/java/time/ZoneOffset.java ! test/java/time/tck/java/time/TCKZoneOffset.java Changeset: 1a18cda712f8 Author: sdrach Date: 2016-08-18 17:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a18cda712f8 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file Reviewed-by: psandoz Contributed-by: steve.drach at oracle.com ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java + test/jdk/nio/zipfs/jarfs/JFSTester.java + test/jdk/nio/zipfs/jarfs/root/dir1/leaf1.txt + test/jdk/nio/zipfs/jarfs/root/dir1/leaf2.txt + test/jdk/nio/zipfs/jarfs/root/dir2/leaf3.txt + test/jdk/nio/zipfs/jarfs/root/dir2/leaf4.txt + test/jdk/nio/zipfs/jarfs/v9/root/dir1/leaf1.txt + test/jdk/nio/zipfs/jarfs/v9/root/dir1/leaf2.txt + test/jdk/nio/zipfs/jarfs/v9/root/dir2/leaf3.txt + test/jdk/nio/zipfs/jarfs/v9/root/dir2/leaf4.txt Changeset: 7925851df5ff Author: amurillo Date: 2016-08-22 15:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7925851df5ff 8164589: Remove sun/rmi/runtime/Log/6409194/NoConsoleOutput.java from ProblemList Reviewed-by: jwilhelm ! test/ProblemList.txt Changeset: 0cd4b4def24f Author: darcy Date: 2016-08-22 17:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0cd4b4def24f 8164524: Correct inconsistencies in floating-point abs spec Reviewed-by: martin, bpb ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: eeef9a64af04 Author: shurailine Date: 2016-08-22 18:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eeef9a64af04 8163126: Fix @modules in some of jdk/* tests Reviewed-by: weijun, alanb, mchung ! test/jdk/lambda/TEST.properties ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/scenarios/container/ContainerTest.java ! test/jdk/nio/zipfs/MultiReleaseJarTest.java ! test/jdk/security/jarsigner/Spec.java Changeset: b548b8217d8c Author: rfield Date: 2016-08-22 19:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b548b8217d8c 8164596: jshell tool: jdk repo module pages to allow double-dash fix to access Jopt-simple Reviewed-by: jlahoda ! src/jdk.internal.opt/share/classes/module-info.java Changeset: 6fe57070fd27 Author: lancea Date: 2016-08-23 10:30 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6fe57070fd27 8164061: Fix @since for javax.sql.rowset.BaseRowSet and javax.sql.CommonDataSource Reviewed-by: darcy ! src/java.sql.rowset/share/classes/javax/sql/rowset/BaseRowSet.java ! src/java.sql/share/classes/javax/sql/CommonDataSource.java ! src/java.sql/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/java.sql/share/classes/javax/sql/DataSource.java ! src/java.sql/share/classes/javax/sql/XADataSource.java Changeset: e160c542959b Author: asmotrak Date: 2016-08-23 10:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e160c542959b 8164592: java/net/MulticastSocket/NoLoopbackPackets.java tests may leave a daemon thread Reviewed-by: clanger, chegar ! test/java/net/MulticastSocket/NoLoopbackPackets.java Changeset: 822cc9eacd37 Author: asmotrak Date: 2016-08-23 10:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/822cc9eacd37 8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads Reviewed-by: alanb ! test/java/nio/file/WatchService/UpdateInterference.java Changeset: 64a55ea8c804 Author: bchristi Date: 2016-08-23 10:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64a55ea8c804 7180225: SecurityExceptions not defined in some class loader methods Reviewed-by: mchung, mullan ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Thread.java Changeset: 5612c35465f3 Author: bpb Date: 2016-08-23 10:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5612c35465f3 8164556: Drop AAC and FLAC from content type check in java/nio/file/Files/probeContentType/Basic.java Summary: Remove file extensions of AAC and FLAC audio encodings from the list of extensions verified. Reviewed-by: alanb ! test/java/nio/file/Files/probeContentType/Basic.java Changeset: 48a8aec77491 Author: psandoz Date: 2016-08-23 15:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/48a8aec77491 8160971: Re-enable VarHandle tests quarantined by JDK-8160690 Reviewed-by: vlivanov ! test/ProblemList.txt Changeset: 104fda852047 Author: sdrach Date: 2016-08-23 11:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/104fda852047 8164585: JarFile::isMultiRelease does not return true in all cases where it should return true Reviewed-by: alanb, psandoz Contributed-by: steve.drach at oracle.com ! src/java.base/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java Changeset: 7a1d9d0e918f Author: weijun Date: 2016-08-24 13:32 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7a1d9d0e918f 8164656: krb5 does not retry if TCP connection timeouts Reviewed-by: xuelei ! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java + test/sun/security/krb5/auto/KdcPolicy.java Changeset: 1f2506b9aadb Author: redestad Date: 2016-08-24 13:54 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1f2506b9aadb 8164669: Lazier initialization of java.time Reviewed-by: scolebourne, chegar, alanb ! src/java.base/share/classes/java/time/Duration.java ! src/java.base/share/classes/sun/util/calendar/ZoneInfo.java Changeset: 6415dc933783 Author: redestad Date: 2016-08-24 16:09 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6415dc933783 8164483: Generate field lambda forms at link time Reviewed-by: vlivanov ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java Changeset: e57d5e251041 Author: redestad Date: 2016-08-24 16:11 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e57d5e251041 8164569: Generate non-customized invoker forms at link time Reviewed-by: vlivanov ! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangInvokeAccess.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! test/java/lang/StackWalker/VerifyStackTrace.java Changeset: 5c5973952fc0 Author: coffeys Date: 2016-08-24 17:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c5973952fc0 8150530: Improve javax.crypto.BadPaddingException messages Reviewed-by: xuelei ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java ! src/java.base/share/classes/sun/security/rsa/RSAPadding.java ! src/java.base/share/classes/sun/security/ssl/CipherBox.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java Changeset: 59162b94ab98 Author: asmotrak Date: 2016-08-24 10:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/59162b94ab98 8164166: Make sure java/nio/channels tests shutdown asynchronous channel groups Reviewed-by: alanb ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java Changeset: 248159c6e61a Author: bpb Date: 2016-08-24 11:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/248159c6e61a 8163136: Add print statements to java/nio/file/WatchService/LotsOfCancels.java Summary: Add some print statements. Reviewed-by: alanb ! test/java/nio/file/WatchService/LotsOfCancels.java Changeset: 7c285662ed53 Author: dl Date: 2016-08-24 12:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7c285662ed53 8163353: NPE in ConcurrentHashMap.removeAll() Reviewed-by: martin, psandoz, redestad, alanb ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java ! test/java/util/concurrent/tck/ConcurrentHashMapTest.java Changeset: 614a48afcff8 Author: sundar Date: 2016-08-25 09:43 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/614a48afcff8 8163793: jlink has typo in copy-files plugin help text example Reviewed-by: sundar, redestad Contributed-by: srinivas.dama at oracle.com ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties Changeset: 53fab310d21d Author: alanb Date: 2016-08-25 10:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/53fab310d21d 8066943: (fs) Path.relativize() gives incorrect result for ".." Reviewed-by: prappo, bpb ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! src/java.base/windows/classes/sun/nio/fs/WindowsPath.java ! test/java/nio/file/Path/PathOps.java Changeset: 30494c2e0f4c Author: redestad Date: 2016-08-25 13:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30494c2e0f4c 8164739: Remove computation of predefined interpreter forms Reviewed-by: vlivanov ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java Changeset: 9c7eb3e1799f Author: mullan Date: 2016-08-25 15:06 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c7eb3e1799f 8151893: Add security property to configure XML Signature secure validation mode Reviewed-by: jnimeh, xuelei ! src/java.base/share/conf/security/java.security ! src/java.base/share/lib/security/default.policy ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java + src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Policy.java + test/javax/xml/crypto/dsig/SecureValidationPolicy.java Changeset: 662fc05c56c8 Author: mullan Date: 2016-08-25 17:08 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/662fc05c56c8 8150158: Update bugs.sun.com references to bugs.java.com Reviewed-by: ascarpino ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java Changeset: fe3b82c04826 Author: lana Date: 2016-08-25 22:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fe3b82c04826 Merge Changeset: 7e21149a616e Author: smarks Date: 2016-08-25 17:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e21149a616e 8164698: modify jdk makefiles to build jdeprscan Reviewed-by: psandoz ! make/launcher/Launcher-jdk.jdeps.gmk Changeset: 2ecab45c0d88 Author: smarks Date: 2016-08-25 21:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2ecab45c0d88 8164834: remove jdeprscan from tools/launcher/VersionCheck.java Reviewed-by: sundar, darcy ! test/tools/launcher/VersionCheck.java Changeset: 267a2788026b Author: sundar Date: 2016-08-26 11:50 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/267a2788026b 8147491: module graph consistency checks after jlink plugins operate on module pool Reviewed-by: jlaskey, mchung, psandoz ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! test/tools/jlink/CustomPluginTest.java ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/customplugin/module-info.java + test/tools/jlink/customplugin/plugin/RogueAdderPlugin.java + test/tools/jlink/customplugin/plugin/RogueFilterPlugin.java Changeset: 8c0d4a9bfea1 Author: ssahoo Date: 2016-08-26 01:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c0d4a9bfea1 8006690: sun/security/krb5/auto/BadKdc* tests fails intermittently Summary: Some of test for bad KDC failed intermittently Reviewed-by: weijun ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc4.java Changeset: a8028ad28ece Author: mullan Date: 2016-08-26 08:16 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a8028ad28ece 8024714: In java.security file, ocsp.responderCertSubjectName should not contain quotes Reviewed-by: vinnie ! src/java.base/share/conf/security/java.security Changeset: a3ba85993930 Author: redestad Date: 2016-08-26 16:16 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3ba85993930 8163371: Enable tracing which JLI classes can be pre-generated Reviewed-by: vlivanov ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties Changeset: 48dffef3ede0 Author: xiaofeya Date: 2016-08-26 08:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/48dffef3ede0 8163561: Add a test for Proxy Authentication in HTTP/2 Client API Reviewed-by: chegar Contributed-by: Felix Yang + test/java/net/httpclient/ProxyAuthTest.java Changeset: d478931e18c7 Author: sundar Date: 2016-08-26 21:31 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d478931e18c7 8164800: Cross targeting Windows Reviewed-by: jlaskey, alanb, mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java Changeset: f65a2005b5d7 Author: redestad Date: 2016-08-26 18:10 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f65a2005b5d7 8164866: tools/jlink/plugins/GenerateJLIClassesPluginTest.java can't compile after JDK-8163371 Reviewed-by: sundar, vlivanov ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! test/tools/jlink/plugins/GenerateJLIClassesPluginTest.java Changeset: 489654d17d7a Author: ascarpino Date: 2016-08-26 09:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/489654d17d7a 8074838: Resolve disabled warnings for libj2pkcs11 Reviewed-by: wetmore, erikj ! make/lib/Lib-jdk.crypto.pkcs11.gmk ! src/jdk.crypto.pkcs11/share/native/libj2pkcs11/p11_util.c ! src/jdk.crypto.pkcs11/unix/native/libj2pkcs11/j2secmod_md.c ! src/jdk.crypto.pkcs11/windows/native/libj2pkcs11/j2secmod_md.c Changeset: 1adaba365592 Author: snikandrova Date: 2016-08-25 20:53 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1adaba365592 8005068: HttpCookie does not correctly handle negative maxAge values Reviewed-by: chegar ! src/java.base/share/classes/java/net/HttpCookie.java + test/java/net/HttpCookie/CookieNegativeMaxAge.java Changeset: 259d5781a907 Author: wetmore Date: 2016-08-26 13:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/259d5781a907 8061842: Package jurisdiction policy files as something other than JAR Reviewed-by: xuelei, weijun, mullan - make/data/cryptopolicy/limited/default_local.policy - make/data/cryptopolicy/limited/exempt_local.policy - make/data/cryptopolicy/unlimited/default_US_export.policy - make/data/cryptopolicy/unlimited/default_local.policy ! make/gendata/Gendata-java.base.gmk + make/gendata/GendataCryptoPolicy.gmk - make/gendata/GendataPolicyJars.gmk ! make/src/classes/build/tools/makejavasecurity/MakeJavaSecurity.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java ! src/java.base/share/conf/security/java.security + src/java.base/share/conf/security/policy/README.txt + src/java.base/share/conf/security/policy/limited/default_US_export.policy + src/java.base/share/conf/security/policy/limited/default_local.policy + src/java.base/share/conf/security/policy/limited/exempt_local.policy + src/java.base/share/conf/security/policy/unlimited/default_US_export.policy + src/java.base/share/conf/security/policy/unlimited/default_local.policy + test/javax/crypto/CryptoPermissions/TestUnlimited.java ! test/jdk/security/JavaDotSecurity/final_java_security ! test/jdk/security/JavaDotSecurity/ifdefs.sh ! test/jdk/security/JavaDotSecurity/raw_java_security Changeset: 2c68a91dcecf Author: clanger Date: 2016-08-29 11:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2c68a91dcecf 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java Reviewed-by: alanb ! test/java/nio/channels/FileChannel/Lock.java Changeset: 01807f630529 Author: jlaskey Date: 2016-08-29 09:10 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01807f630529 8161000: GPL header incorrect - classfile/classpath Reviewed-by: sundar ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PathResourcePoolEntry.java Changeset: 237840d68fa8 Author: sundar Date: 2016-08-29 21:09 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/237840d68fa8 8159004: jlink attempts to create launcher scripts when root/bin dir does not exist Reviewed-by: jlaskey, alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java Changeset: c5a832e62e0f Author: snikandrova Date: 2016-08-29 20:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c5a832e62e0f 8164533: sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error while cleaning up threads after test" Reviewed-by: xuelei ! test/sun/security/ssl/SSLSocketImpl/CloseSocket.java Changeset: 803adcd526d7 Author: sherman Date: 2016-08-29 11:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/803adcd526d7 8066577: Cleanup and make better use of the stream API in the jrtfs code Reviewed-by: alanb, psandoz, redestad ! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java Changeset: ffd7ba8f2bf8 Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ffd7ba8f2bf8 Added tag jdk-9+134 for changeset 803adcd526d7 ! .hgtags Changeset: 2e46f14e2012 Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2e46f14e2012 Merge ! .hgtags ! make/gendata/Gendata-java.base.gmk ! make/gendata/GendataCryptoPolicy.gmk ! make/launcher/Launcher-jdk.jdeps.gmk ! make/lib/Lib-jdk.crypto.pkcs11.gmk ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/conf/security/java.security ! src/jdk.internal.opt/share/classes/module-info.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/ProblemList.txt ! test/java/lang/StackWalker/VerifyStackTrace.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/scenarios/container/ContainerTest.java ! test/tools/jlink/CustomPluginTest.java ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/customplugin/module-info.java ! test/tools/launcher/VersionCheck.java From mandy.chung at oracle.com Fri Sep 2 04:40:33 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:40:33 +0000 Subject: hg: jigsaw/jake/langtools: 22 new changesets Message-ID: <201609020440.u824eXXi003193@aojmv0008.oracle.com> Changeset: 4b17f176d19c Author: jjg Date: 2016-08-22 16:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4b17f176d19c 8164130: Simplify doclet IOException handling Reviewed-by: bpatel, ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/DocType.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/FixedStringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocument.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/StringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstantsSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Content.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/DocletException.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PackageSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/SerializedFormWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/LayoutParser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PackageSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFileFactory.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFileIOException.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocletAbortException.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/InternalException.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PackageListWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ResourceIOException.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SimpleDocletException.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/jdk/javadoc/doclet/testIOException/TestIOException.java Changeset: bfc6d670ec1f Author: rfield Date: 2016-08-22 19:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bfc6d670ec1f 8160089: jshell tool: use new double-dash long-form command-line options Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/module-info.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/EditorTestBase.java ! test/jdk/jshell/ExternalEditorTest.java ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/ToolBasicTest.java ! test/jdk/jshell/ToolCommandOptionTest.java ! test/jdk/jshell/ToolLocaleMessageTest.java ! test/jdk/jshell/ToolReloadTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: aa225bdbcc52 Author: darcy Date: 2016-08-22 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/aa225bdbcc52 8164598: Problem list TestIOException.java Reviewed-by: jjg ! test/ProblemList.txt Changeset: 7e0e176a6297 Author: anazarov Date: 2016-08-23 10:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7e0e176a6297 8163991: Fix license and copyright headers under test/jdk/javadoc/ and test/tools/javac/ Reviewed-by: anazarov, iris, jjg, shurailine Contributed-by: Sandeep Konchady ! test/jdk/javadoc/doclet/testTypeAnnotations/typeannos/RepeatedAnnotations.java ! test/tools/javac/InnerClassesAttribute/Test.java ! test/tools/javac/modules/SingleModuleModeTest.java ! test/tools/javac/redefineObject/Object1-test.java ! test/tools/javac/redefineObject/Object2-test.java Changeset: c10b810f0685 Author: vromero Date: 2016-08-24 12:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c10b810f0685 8047338: javac is not correctly filtering non-members methods to obtain the function descriptor Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/T8047338/FilterNonMembersToObtainFunctionDescriptorTest.java Changeset: f83c37d8c02c Author: jjg Date: 2016-08-24 15:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f83c37d8c02c 8164747: allclasses-frame broken after JDK-8162353 Reviewed-by: bpatel ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java ! test/jdk/javadoc/doclet/testFramesNoFrames/TestFramesNoFrames.java Changeset: e666d0f958f6 Author: vromero Date: 2016-08-24 17:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e666d0f958f6 8161501: JSR269 jigsaw update: javax.lang.model.element.ModuleElement.getEnclosedElements() on unnamed module with unnamed package Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java + test/tools/javac/modules/T8161501/EmptyClass.java + test/tools/javac/modules/T8161501/UnnamedModuleUnnamedPackageTest.java Changeset: 34dea0a7b9ab Author: mcimadamore Date: 2016-08-25 11:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/34dea0a7b9ab 8164399: inference of thrown variable does not work correctly Summary: Logic for inferring thrown variables should exclude non proper bounds as per JLS 18.1 Reviewed-by: vromero, dlsmith ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8164399/T8164399.java + test/tools/javac/generics/inference/8164399/T8164399b.java + test/tools/javac/generics/inference/8164399/T8164399b.out Changeset: e20e3cb61cf8 Author: lana Date: 2016-08-25 22:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e20e3cb61cf8 Merge - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocletAbortException.java Changeset: 871b60b0c091 Author: smarks Date: 2016-08-25 17:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/871b60b0c091 8145464: implement deprecation static analysis tool Reviewed-by: psandoz, darcy ! make/CompileInterim.gmk + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/CSV.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/CSVParseException.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/DeprDB.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/DeprData.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/LoadProc.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Messages.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Pretty.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/internals.md + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/scan/CPEntries.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/scan/CPSelector.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/scan/ClassFinder.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/scan/MethodSig.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/scan/Scan.java + test/tools/jdeprscan/cases/jdk/deprcases/members/ExampleAnnotation.java + test/tools/jdeprscan/cases/jdk/deprcases/members/ExampleClass.java + test/tools/jdeprscan/cases/jdk/deprcases/members/ExampleElements.java + test/tools/jdeprscan/cases/jdk/deprcases/members/ExampleEnum.java + test/tools/jdeprscan/cases/jdk/deprcases/members/ExampleInterface.java + test/tools/jdeprscan/cases/jdk/deprcases/members/ExampleSubclass.java + test/tools/jdeprscan/cases/jdk/deprcases/types/DeprecatedAnnotation.java + test/tools/jdeprscan/cases/jdk/deprcases/types/DeprecatedClass.java + test/tools/jdeprscan/cases/jdk/deprcases/types/DeprecatedEnum.java + test/tools/jdeprscan/cases/jdk/deprcases/types/DeprecatedException.java + test/tools/jdeprscan/cases/jdk/deprcases/types/DeprecatedInterface.java + test/tools/jdeprscan/tests/jdk/jdeprscan/TestCSV.java + test/tools/jdeprscan/tests/jdk/jdeprscan/TestLoad.java + test/tools/jdeprscan/tests/jdk/jdeprscan/TestLoadExpected.csv + test/tools/jdeprscan/tests/jdk/jdeprscan/TestMethodSig.java + test/tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java + test/tools/jdeprscan/tests/jdk/jdeprscan/TestScanExpected.txt + test/tools/jdeprscan/usage/jdk/deprusage/UseAnnotation.java + test/tools/jdeprscan/usage/jdk/deprusage/UseClass.java + test/tools/jdeprscan/usage/jdk/deprusage/UseEnum.java + test/tools/jdeprscan/usage/jdk/deprusage/UseEnumMembers.java + test/tools/jdeprscan/usage/jdk/deprusage/UseException.java + test/tools/jdeprscan/usage/jdk/deprusage/UseField.java + test/tools/jdeprscan/usage/jdk/deprusage/UseInterface.java + test/tools/jdeprscan/usage/jdk/deprusage/UseMethod.java Changeset: 3aacdb2da217 Author: smarks Date: 2016-08-25 21:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3aacdb2da217 8164835: add a few tools tests to the problem list Reviewed-by: darcy ! test/ProblemList.txt Changeset: 7576f5b45480 Author: rfield Date: 2016-08-26 11:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7576f5b45480 8158738: jshell tool: Save does not affect jshell if started from another editor Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/ToolCommandOptionTest.java Changeset: 64182008b2d0 Author: jjg Date: 2016-08-26 15:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/64182008b2d0 8164887: update tests to remove use of old-style options Reviewed-by: mchung ! make/build.xml ! make/diags-examples.xml ! make/gendata/Gendata-jdk.compiler.gmk ! make/intellij/runConfigurations/javah.xml ! make/intellij/runConfigurations/javap.xml ! make/intellij/runConfigurations/jshell.xml ! make/intellij/runConfigurations/sjavac.xml ! make/netbeans/langtools/build.xml ! test/jdk/javadoc/doclet/testFramesNoFrames/TestFramesNoFrames.java ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/jdk/javadoc/tool/modules/FilterOptions.java ! test/jdk/javadoc/tool/modules/Modules.java ! test/jdk/javadoc/tool/modules/PackageOptions.java ! test/tools/javac/VersionOpt.java ! test/tools/javac/diags/examples/DirPathElementNotDirectory/modulesourcepath ! test/tools/javac/diags/examples/ModuleNotFoundInModuleSourcePath/ModuleNotFoundInModuleSourcePath.java ! test/tools/javac/diags/examples/XModuleWithModulePath/XModuleWithModulePath.java ! test/tools/javac/file/LimitedImage.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/javac/modules/NPEEmptyFileTest.java ! test/tools/jdeps/jdkinternals/RemovedJDKInternals.java ! test/tools/jdeps/lib/CompilerUtils.java Changeset: 669b6e24db11 Author: ntv Date: 2016-08-29 09:58 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/669b6e24db11 8156984: JShell tool: for (FormatCase e : EnumSet.allOf(FormatCase.class)) Summary: Replacde EnumSet.allOf(FormatCase.class) with FormatCase.all Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java Changeset: 1b85b34c5451 Author: ntv Date: 2016-08-29 11:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1b85b34c5451 8153897: jshell tool: "not active" must be pulled from resource file Summary: Not active error msg pulled from resource file Reviewed-by: rfield ! test/jdk/jshell/ToolSimpleTest.java Changeset: 00ed01cc934d Author: jlahoda Date: 2016-08-29 15:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/00ed01cc934d 8164745: javac -Xmodule compiles the module in a way that reads the unnamed module Summary: Ensuring proper separation between named modules the unnamed module when using -Xmodule Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/tools/javac/modules/XModuleTest.java Changeset: 8df4d9a3f0f5 Author: rfield Date: 2016-08-29 08:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8df4d9a3f0f5 8158507: JShell: new jdk.jshell.MemoryFileManager(StandardJavaFileManager, JShell) creates a jdk.jshell.MemoryFileManager$REPLClassLoader classloader, which should be performed within a doPrivileged block Summary: Remove the ClassLoader and other unused code in support of in-process execution. This is now supported through the SPI. Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java Changeset: 8817d125028c Author: jlahoda Date: 2016-08-29 18:14 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8817d125028c 8164951: Build broken after JDK-8164745 Summary: Reverting the fix for JDK-8164745 to investigate a build failure. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/tools/javac/modules/XModuleTest.java Changeset: 1c94cec888d8 Author: ksrini Date: 2016-08-29 07:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1c94cec888d8 8157349: Missing doc-files in javadoc documentation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/jdk/javadoc/doclet/testCopyFiles/TestCopyFiles.java + test/jdk/javadoc/doclet/testCopyFiles/modules/acme.mdle/module-info.java + test/jdk/javadoc/doclet/testCopyFiles/modules/acme.mdle/p/Foo.java + test/jdk/javadoc/doclet/testCopyFiles/modules/acme.mdle/p/doc-files/inpackage.html + test/jdk/javadoc/doclet/testCopyFiles/packages/p1/Foo.java + test/jdk/javadoc/doclet/testCopyFiles/packages/p1/doc-files/inpackage.html + test/jdk/javadoc/doclet/testCopyFiles/unnamed/Foo.java + test/jdk/javadoc/doclet/testCopyFiles/unnamed/doc-files/inpackage.html Changeset: f08683786207 Author: jlahoda Date: 2016-08-29 20:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f08683786207 8164836: TEST_BUG: adjust scope of the DefinedByAnalyzer in tools/all/RunCodingRules.java Summary: Only enabling the DefinedByAnalyzer on java.compiler and jdk.compiler; removing the @DefinedBy annotations from other modules Reviewed-by: jjg, ksrini ! make/tools/crules/DefinedByAnalyzer.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTaskImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/OverviewElement.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ClassUseMapper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDependencyScanner.java ! test/ProblemList.txt Changeset: c24aba041be9 Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c24aba041be9 Added tag jdk-9+134 for changeset f08683786207 ! .hgtags Changeset: dccf3761c661 Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dccf3761c661 Merge ! .hgtags ! make/CompileInterim.gmk ! make/build.xml ! make/gendata/Gendata-jdk.compiler.gmk ! make/netbeans/langtools/build.xml ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/ProblemList.txt ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/jdk/javadoc/tool/modules/FilterOptions.java ! test/jdk/javadoc/tool/modules/Modules.java ! test/jdk/javadoc/tool/modules/PackageOptions.java ! test/jdk/jshell/CommandCompletionTest.java ! test/tools/javac/VersionOpt.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/javac/modules/NPEEmptyFileTest.java ! test/tools/javac/modules/SingleModuleModeTest.java ! test/tools/javac/modules/XModuleTest.java ! test/tools/javac/redefineObject/Object1-test.java ! test/tools/javac/redefineObject/Object2-test.java ! test/tools/jdeps/lib/CompilerUtils.java From mandy.chung at oracle.com Fri Sep 2 04:40:37 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 02 Sep 2016 04:40:37 +0000 Subject: hg: jigsaw/jake/nashorn: 5 new changesets Message-ID: <201609020440.u824eb1V003241@aojmv0008.oracle.com> Changeset: 5fb49fa09808 Author: sundar Date: 2016-08-24 14:02 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5fb49fa09808 8164618: add documentation for NativeNumber and NativeBoolean Reviewed-by: sundar Contributed-by: srinivas.dama at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Functions.properties Changeset: fe2dcb396ff4 Author: sundar Date: 2016-08-25 22:23 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fe2dcb396ff4 8164748: Edit pad crashes when calling function Reviewed-by: jlaskey ! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Main.java Changeset: e05400ba9357 Author: lana Date: 2016-08-25 22:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e05400ba9357 Merge Changeset: cb00d5ef023a Author: lana Date: 2016-09-01 23:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cb00d5ef023a Added tag jdk-9+134 for changeset e05400ba9357 ! .hgtags Changeset: 03176c9f7a69 Author: mchung Date: 2016-09-01 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/03176c9f7a69 Merge ! .hgtags From sundararajan.athijegannathan at oracle.com Fri Sep 2 06:07:01 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 02 Sep 2016 11:37:01 +0530 Subject: RFR 8157992: Improve jlink help message on optimization-related options Message-ID: <57C91705.1050302@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8157992 Thanks -Sundar From andrej.golovnin at gmail.com Fri Sep 2 06:09:14 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 2 Sep 2016 08:09:14 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: Hi Patrick, src/java.base/share/classes/java/lang/ClassLoader.java The constant RESOURCE_CHARACTERISTICS in the line 215 should be defined near the #streamOf()-method. The distance between the line 1412 where the #streamOf()-method is defined and the line 215 is just too huge. Your patch seems to modify the JavaDocs of the methods #getParent(), #getPlatformClassLoader(), #getSystemClassLoader(). But I don see how it is related to the issue you try to solve. test/java/lang/ClassLoader/resources/ResourcesFailureCase.java test/java/lang/ClassLoader/resources/ResourcesSuccessCase.java The indentation is broken. You use tabs. But in JDK you must use spaces, see http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation Best regards, Andrej Golovnin On Thu, Sep 1, 2016 at 10:06 PM, Patrick Reinhart wrote: > Hi Alan, > Hi Paul, > > Here is the first revision of the implementation based on our earlier conversation. > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 > > - Patrick From patrick at reini.net Fri Sep 2 07:41:31 2016 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 02 Sep 2016 09:41:31 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: On 2016-09-02 08:09, Andrej Golovnin wrote: > src/java.base/share/classes/java/lang/ClassLoader.java > > The constant RESOURCE_CHARACTERISTICS in the line 215 should be > defined near the #streamOf()-method. The distance between the line > 1412 where the #streamOf()-method is defined and the line 215 is just > too huge. No problem, moved to the method itself > Your patch seems to modify the JavaDocs of the methods #getParent(), > #getPlatformClassLoader(), #getSystemClassLoader(). But I don see how > it is related to the issue you try to solve.> Was a merge issue, removed those > test/java/lang/ClassLoader/resources/ResourcesFailureCase.java > test/java/lang/ClassLoader/resources/ResourcesSuccessCase.java > The indentation is broken. You use tabs. But in JDK you must use > spaces, see > http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation Fixed those also. See updated webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 - Patrick From Alan.Bateman at oracle.com Fri Sep 2 08:12:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Sep 2016 09:12:01 +0100 Subject: RFR 8157992: Improve jlink help message on optimization-related options In-Reply-To: <57C91705.1050302@oracle.com> References: <57C91705.1050302@oracle.com> Message-ID: On 02/09/2016 07:07, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8157992 > "details" should have one "d" :-) Looks fine otherwise. From Alan.Bateman at oracle.com Fri Sep 2 08:27:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Sep 2016 09:27:26 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: <30f6934f-82d2-e197-e6e1-7611330bd8a1@bbs.darktech.org> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <4a02179c-9f4e-8492-f3ce-a6d8b4608905@oracle.com> <66c66a61-7241-0980-1c77-1a9cd70678df@redhat.com> <30f6934f-82d2-e197-e6e1-7611330bd8a1@bbs.darktech.org> Message-ID: <2d046427-4724-61a6-2a37-13efd315a3ac@oracle.com> On 01/09/2016 21:04, cowwoc wrote: > Another possibility (not saying it's better, just putting it out there) > is to do the following: > > 1. Provide a tool like "javah" that would generate module-info.java for > non-modularized JAR files. > > Look at `jdeps --gen-module-info ..`. It's a starting point to create a source file that is easy to edit (see the slide decks). It's not difficult to write your own ModuleFinder that reads the module declaration from elsewhere if you really want. If you are willing to write a module declaration for each of the 100 JAR files on your class path then more power to you. To be honest, the feedback over the years has almost always been that developers don't want to take responsibility for libraries maintained by others. This usually means they won't want to write/maintain the module declaration for libraries that they won't own, or they don't know enough about the code in these components to be confident that the module declaration is correct. -Alan From sundararajan.athijegannathan at oracle.com Fri Sep 2 09:10:52 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 2 Sep 2016 14:40:52 +0530 Subject: RFR 8157992: Improve jlink help message on optimization-related options In-Reply-To: References: <57C91705.1050302@oracle.com> Message-ID: Cleas, Alan: Thanks for the reviews. Uploaded updated webrev for the record: http://cr.openjdk.java.net/~sundar/8157992/webrev.02/ And going ahead with push.. Thanks. -Sundar On 9/2/2016 1:42 PM, Alan Bateman wrote: > On 02/09/2016 07:07, Sundararajan Athijegannathan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ >> for https://bugs.openjdk.java.net/browse/JDK-8157992 >> > "details" should have one "d" :-) Looks fine otherwise. From ropalka at redhat.com Fri Sep 2 09:35:15 2016 From: ropalka at redhat.com (Richard Opalka) Date: Fri, 2 Sep 2016 11:35:15 +0200 Subject: Multiple versions of a non-exported dependency In-Reply-To: <2d046427-4724-61a6-2a37-13efd315a3ac@oracle.com> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <4a02179c-9f4e-8492-f3ce-a6d8b4608905@oracle.com> <66c66a61-7241-0980-1c77-1a9cd70678df@redhat.com> <30f6934f-82d2-e197-e6e1-7611330bd8a1@bbs.darktech.org> <2d046427-4724-61a6-2a37-13efd315a3ac@oracle.com> Message-ID: On 09/02/2016 10:27 AM, Alan Bateman wrote: > On 01/09/2016 21:04, cowwoc wrote: > >> Another possibility (not saying it's better, just putting it out there) >> is to do the following: >> >> 1. Provide a tool like "javah" that would generate module-info.java >> for >> non-modularized JAR files. >> >> > Look at `jdeps --gen-module-info ..`. It's a starting point to create > a source file that is easy to edit (see the slide decks). > > It's not difficult to write your own ModuleFinder that reads the > module declaration from elsewhere if you really want. If you are > willing to write a module declaration for each of the 100 JAR files on > your class path then more power to you. To be honest, the feedback > over the years has almost always been that developers don't want to > take responsibility for libraries maintained by others. This usually > means they won't want to write/maintain the module declaration for > libraries that they won't own, or they don't know enough about the > code in these components to be confident that the module declaration > is correct. > > -Alan Seems the main reason why automatic modules need to see the classpath UNNAMED module is there might be conflicting packages on that classpath which modularization would be non trivial (would require custom ModuleFinders, Layers and ClassLoader factories). Yes, automatic modules help in such scenarios. Will Java support classpath forever or there are plans to remove it? Asking because if classpath would be removed some time in the future such compromise (automatic modules) is just short term win affecting many key design decisions. Richard From Alan.Bateman at oracle.com Fri Sep 2 09:54:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Sep 2016 10:54:11 +0100 Subject: Multiple versions of a non-exported dependency In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <4a02179c-9f4e-8492-f3ce-a6d8b4608905@oracle.com> <66c66a61-7241-0980-1c77-1a9cd70678df@redhat.com> <30f6934f-82d2-e197-e6e1-7611330bd8a1@bbs.darktech.org> <2d046427-4724-61a6-2a37-13efd315a3ac@oracle.com> Message-ID: <1fece3d0-b7cb-688b-6437-53d99610802b@oracle.com> On 02/09/2016 10:35, Richard Opalka wrote: > : > > Will Java support classpath forever or there are plans to remove it? > Asking because if classpath would be removed some time in the future > such compromise (automatic modules) is just short term win affecting > many key design decisions. I'm not aware of any proposal to drop the class path, it's just too entrenched. Remember that we are retrofitting modules to a mature platform and so migration, compatibility, and interoperability have to be at the fore. -Alan. From james.laskey at oracle.com Fri Sep 2 11:49:58 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 2 Sep 2016 08:49:58 -0300 Subject: RFR 8157992: Improve jlink help message on optimization-related options In-Reply-To: References: <57C91705.1050302@oracle.com> Message-ID: +1 > On Sep 2, 2016, at 6:10 AM, Sundararajan Athijegannathan wrote: > > Cleas, Alan: > > Thanks for the reviews. Uploaded updated webrev for the record: > http://cr.openjdk.java.net/~sundar/8157992/webrev.02/ > > And going ahead with push.. > > Thanks. > > -Sundar > > > On 9/2/2016 1:42 PM, Alan Bateman wrote: >> On 02/09/2016 07:07, Sundararajan Athijegannathan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ >>> for https://bugs.openjdk.java.net/browse/JDK-8157992 >>> >> "details" should have one "d" :-) Looks fine otherwise. > From blackdrag at gmx.org Sun Sep 4 13:35:35 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sun, 4 Sep 2016 15:35:35 +0200 Subject: problem with Class#getResource Message-ID: <57CC2327.6020604@gmx.org> Hi all, I am using build 9-ea+132 I have a test, that does in the setup this.class.getResource("/jars"), to get a URL to the jars directory. The parent directory is on the classpath, but the call returns null... This code is not run in a named module. Can anyone tell me why that returns null with jigsaw? bye Jochen From uschindler at apache.org Sun Sep 4 15:32:08 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 4 Sep 2016 17:32:08 +0200 Subject: problem with Class#getResource In-Reply-To: <57CC2327.6020604@gmx.org> References: <57CC2327.6020604@gmx.org> Message-ID: <031b01d206c1$81f38280$85da8780$@apache.org> Hi, I think this is related to multi-release JAR files because directories are no longer "unique" for the same resource. I am not 100% sure, but according to specs, Resources are only files, never directories, so I'd always say the above code is wrong and it is just caused by an implementation detail that it works at all. :-) Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > Sent: Sunday, September 4, 2016 3:36 PM > To: jigsaw-dev at openjdk.java.net > Subject: problem with Class#getResource > > Hi all, > > > I am using build 9-ea+132 > > I have a test, that does in the setup this.class.getResource("/jars"), > to get a URL to the jars directory. The parent directory is on the > classpath, but the call returns null... This code is not run in a named > module. > > Can anyone tell me why that returns null with jigsaw? > > bye Jochen From rfscholte at apache.org Sun Sep 4 17:01:41 2016 From: rfscholte at apache.org (Robert Scholte) Date: Sun, 04 Sep 2016 19:01:41 +0200 Subject: [MRJAR] Entry order matters? Message-ID: Hi, we have this demo application[1] to show how you can generate a multirelease JAR right now with Maven. However, in my case the result for Java9 is very unstable. Most of the time I get something like 9-ea+133-jigsaw-nightly-h5435-20160828 BASE but I would expect 9-ea+133-jigsaw-nightly-h5435-20160828 FROM BASE -> NINE Once I had both a successful and a failing jar, I compared the content: success: META-INF/MANIFEST.MF META-INF/ base/ mr/ META-INF/maven/ META-INF/maven/multirelease/ META-INF/maven/multirelease/multirelease-base/ META-INF/versions/ META-INF/versions/8/ META-INF/versions/8/mr/ META-INF/versions/9/ META-INF/versions/9/mr/ base/Base.class META-INF/maven/multirelease/multirelease-base/pom.properties META-INF/maven/multirelease/multirelease-base/pom.xml META-INF/versions/8/mr/A.class mr/A.class META-INF/versions/9/mr/A.class failure: META-INF/MANIFEST.MF META-INF/ base/ mr/ META-INF/versions/ META-INF/versions/8/ META-INF/versions/8/mr/ META-INF/versions/9/ META-INF/versions/9/mr/ base/Base.class META-INF/maven/multirelease/ META-INF/maven/multirelease/multirelease-base/pom.properties META-INF/versions/9/mr/A.class META-INF/versions/8/mr/A.class META-INF/maven/multirelease/multirelease-base/pom.xml mr/A.class META-INF/maven/multirelease/multirelease-base/ META-INF/maven/ AFAIK the JEP238 doesn't mention something about order. This is an issue on both Windows and Mac. Anyone who has an explanation? regards, Robert Scholte [1] https://github.com/hboutemy/maven-jep238 [2] http://openjdk.java.net/jeps/238 From dawid.weiss at gmail.com Sun Sep 4 19:30:44 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Sun, 4 Sep 2016 21:30:44 +0200 Subject: problem with Class#getResource In-Reply-To: <031b01d206c1$81f38280$85da8780$@apache.org> References: <57CC2327.6020604@gmx.org> <031b01d206c1$81f38280$85da8780$@apache.org> Message-ID: This kind of "package-list" by getResources seems to be used quite frequently in the wild... Check out this issue I filed for Log4j2. https://issues.apache.org/jira/browse/LOG4J2-1484 I agree it's a side-effect that isn't defined in the spec (and shouldn't be working). Dawid On Sun, Sep 4, 2016 at 5:32 PM, Uwe Schindler wrote: > Hi, > > I think this is related to multi-release JAR files because directories are no longer "unique" for the same resource. I am not 100% sure, but according to specs, Resources are only files, never directories, so I'd always say the above code is wrong and it is just caused by an implementation detail that it works at all. :-) > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ >> Sent: Sunday, September 4, 2016 3:36 PM >> To: jigsaw-dev at openjdk.java.net >> Subject: problem with Class#getResource >> >> Hi all, >> >> >> I am using build 9-ea+132 >> >> I have a test, that does in the setup this.class.getResource("/jars"), >> to get a URL to the jars directory. The parent directory is on the >> classpath, but the call returns null... This code is not run in a named >> module. >> >> Can anyone tell me why that returns null with jigsaw? >> >> bye Jochen > From Alan.Bateman at oracle.com Sun Sep 4 20:05:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Sep 2016 21:05:13 +0100 Subject: problem with Class#getResource In-Reply-To: <57CC2327.6020604@gmx.org> References: <57CC2327.6020604@gmx.org> Message-ID: <2cedbfcf-28f1-fb9f-d6f4-ddf178ee0628@oracle.com> On 04/09/2016 14:35, Jochen Theodorou wrote: > Hi all, > > > I am using build 9-ea+132 > > I have a test, that does in the setup this.class.getResource("/jars"), > to get a URL to the jars directory. The parent directory is on the > classpath, but the call returns null... This code is not run in a > named module. > > Can anyone tell me why that returns null with jigsaw? Can you say what "this.class" is in the example? Also do you see any difference in behavior between the regular JDK 9 downloads and the Jigsaw EA downloads? -Alan From Alan.Bateman at oracle.com Sun Sep 4 20:50:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Sep 2016 21:50:00 +0100 Subject: [MRJAR] Entry order matters? In-Reply-To: References: Message-ID: <223e2860-386f-fa40-7621-a01352130a68@oracle.com> On 04/09/2016 18:01, Robert Scholte wrote: > Hi, > > we have this demo application[1] to show how you can generate a > multirelease JAR right now with Maven. > However, in my case the result for Java9 is very unstable. Most of the > time I get something like > 9-ea+133-jigsaw-nightly-h5435-20160828 > BASE > > but I would expect > 9-ea+133-jigsaw-nightly-h5435-20160828 > FROM BASE -> NINE > > Once I had both a successful and a failing jar, I compared the content: Just to double check. For the failure case then are you sure that that "Multi-Release: true" is in the main manifest. Also if you "unzip -d " then does everything look okay? -Alan From rfscholte at apache.org Sun Sep 4 20:56:57 2016 From: rfscholte at apache.org (Robert Scholte) Date: Sun, 04 Sep 2016 22:56:57 +0200 Subject: [MRJAR] Entry order matters? In-Reply-To: <223e2860-386f-fa40-7621-a01352130a68@oracle.com> References: <223e2860-386f-fa40-7621-a01352130a68@oracle.com> Message-ID: On Sun, 04 Sep 2016 22:50:00 +0200, Alan Bateman wrote: > On 04/09/2016 18:01, Robert Scholte wrote: > >> Hi, >> >> we have this demo application[1] to show how you can generate a >> multirelease JAR right now with Maven. >> However, in my case the result for Java9 is very unstable. Most of the >> time I get something like >> 9-ea+133-jigsaw-nightly-h5435-20160828 >> BASE >> >> but I would expect >> 9-ea+133-jigsaw-nightly-h5435-20160828 >> FROM BASE -> NINE >> >> Once I had both a successful and a failing jar, I compared the content: > Just to double check. For the failure case then are you sure that that > "Multi-Release: true" is in the main manifest. Yes > Also if you "unzip -d " then does everything look okay? > hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_failure.jar | grep class hboutemy testing: base/Base.class OK hboutemy testing: META-INF/versions/9/mr/A.class OK hboutemy testing: META-INF/versions/8/mr/A.class OK hboutemy testing: mr/A.class OK hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_success.jar | grep class hboutemy testing: base/Base.class OK hboutemy testing: META-INF/versions/8/mr/A.class OK hboutemy testing: mr/A.class OK hboutemy testing: META-INF/versions/9/mr/A.class OK Looks good to me. Robert > -Alan From blackdrag at gmx.org Sun Sep 4 21:33:11 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sun, 4 Sep 2016 23:33:11 +0200 Subject: problem with Class#getResource In-Reply-To: <031b01d206c1$81f38280$85da8780$@apache.org> References: <57CC2327.6020604@gmx.org> <031b01d206c1$81f38280$85da8780$@apache.org> Message-ID: <57CC9317.4040505@gmx.org> hmmm... makes a sad sense to me. Though.... it seems to extend to ClassLoader#getResources(). That can?t be because of multi-release JAR files, can it? bye Jochen On 04.09.2016 17:32, Uwe Schindler wrote: > Hi, > > I think this is related to multi-release JAR files because directories are no longer "unique" for the same resource. I am not 100% sure, but according to specs, Resources are only files, never directories, so I'd always say the above code is wrong and it is just caused by an implementation detail that it works at all. :-) > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ >> Sent: Sunday, September 4, 2016 3:36 PM >> To: jigsaw-dev at openjdk.java.net >> Subject: problem with Class#getResource >> >> Hi all, >> >> >> I am using build 9-ea+132 >> >> I have a test, that does in the setup this.class.getResource("/jars"), >> to get a URL to the jars directory. The parent directory is on the >> classpath, but the call returns null... This code is not run in a named >> module. >> >> Can anyone tell me why that returns null with jigsaw? >> >> bye Jochen > From Alan.Bateman at oracle.com Mon Sep 5 07:10:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Sep 2016 08:10:56 +0100 Subject: [MRJAR] Entry order matters? In-Reply-To: References: <223e2860-386f-fa40-7621-a01352130a68@oracle.com> Message-ID: <823816d2-3b34-5a2a-76d8-84f6123d276c@oracle.com> On 04/09/2016 21:56, Robert Scholte wrote: > : > >> Also if you "unzip -d " then does everything look okay? >> > > hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_failure.jar | grep class > hboutemy testing: base/Base.class OK > hboutemy testing: META-INF/versions/9/mr/A.class OK > hboutemy testing: META-INF/versions/8/mr/A.class OK > hboutemy testing: mr/A.class OK > hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_success.jar | grep class > hboutemy testing: base/Base.class OK > hboutemy testing: META-INF/versions/8/mr/A.class OK > hboutemy testing: mr/A.class OK > hboutemy testing: META-INF/versions/9/mr/A.class OK > > Looks good to me. I think I need to see multirelease-0.8-SNAPSHOT_failure.jar to understand this as I suspect there is more going on that is obvious here. I'll see if I can duplicate it. -Alan From Alan.Bateman at oracle.com Mon Sep 5 07:28:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Sep 2016 08:28:58 +0100 Subject: problem with Class#getResource In-Reply-To: <57CC9317.4040505@gmx.org> References: <57CC2327.6020604@gmx.org> <031b01d206c1$81f38280$85da8780$@apache.org> <57CC9317.4040505@gmx.org> Message-ID: <073509f2-5f13-6209-d4dd-fa5ab8aef211@oracle.com> On 04/09/2016 22:33, Jochen Theodorou wrote: > hmmm... makes a sad sense to me. Though.... it seems to extend to > ClassLoader#getResources(). That can?t be because of multi-release JAR > files, can it? I can't think how the MR JARs could be an issue here. Do you think you could distill this down to a small test case so that it's a bit clearer on what the issue is. -Alan From blackdrag at gmx.org Mon Sep 5 13:15:03 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 5 Sep 2016 15:15:03 +0200 Subject: problem with Class#getResource In-Reply-To: <2cedbfcf-28f1-fb9f-d6f4-ddf178ee0628@oracle.com> References: <57CC2327.6020604@gmx.org> <2cedbfcf-28f1-fb9f-d6f4-ddf178ee0628@oracle.com> Message-ID: <57CD6FD7.60100@gmx.org> On 04.09.2016 22:05, Alan Bateman wrote: > On 04/09/2016 14:35, Jochen Theodorou wrote: > >> Hi all, >> >> >> I am using build 9-ea+132 >> >> I have a test, that does in the setup this.class.getResource("/jars"), >> to get a URL to the jars directory. The parent directory is on the >> classpath, but the call returns null... This code is not run in a >> named module. >> >> Can anyone tell me why that returns null with jigsaw? > Can you say what "this.class" is in the example? Also do you see any > difference in behavior between the regular JDK 9 downloads and the > Jigsaw EA downloads? this.class is the same as this.getClass(). Anyway... turns out this is working if I make a standalone example. Which means the test setup part must do something wrong when forking a new JVM. bye Jochen From blackdrag at gmx.org Mon Sep 5 14:50:42 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 5 Sep 2016 16:50:42 +0200 Subject: problem with Class#getResource In-Reply-To: <57CD6FD7.60100@gmx.org> References: <57CC2327.6020604@gmx.org> <2cedbfcf-28f1-fb9f-d6f4-ddf178ee0628@oracle.com> <57CD6FD7.60100@gmx.org> Message-ID: <57CD8642.7030500@gmx.org> On 05.09.2016 15:15, Jochen Theodorou wrote: > > On 04.09.2016 22:05, Alan Bateman wrote: >> On 04/09/2016 14:35, Jochen Theodorou wrote: >> >>> Hi all, >>> >>> >>> I am using build 9-ea+132 >>> >>> I have a test, that does in the setup this.class.getResource("/jars"), >>> to get a URL to the jars directory. The parent directory is on the >>> classpath, but the call returns null... This code is not run in a >>> named module. >>> >>> Can anyone tell me why that returns null with jigsaw? >> Can you say what "this.class" is in the example? Also do you see any >> difference in behavior between the regular JDK 9 downloads and the >> Jigsaw EA downloads? > > this.class is the same as this.getClass(). > > Anyway... turns out this is working if I make a standalone example. > Which means the test setup part must do something wrong when forking a > new JVM. getResource did not get caller sensitive, right? bye Jochen From Alan.Bateman at oracle.com Mon Sep 5 15:00:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Sep 2016 16:00:20 +0100 Subject: problem with Class#getResource In-Reply-To: <57CD8642.7030500@gmx.org> References: <57CC2327.6020604@gmx.org> <2cedbfcf-28f1-fb9f-d6f4-ddf178ee0628@oracle.com> <57CD6FD7.60100@gmx.org> <57CD8642.7030500@gmx.org> Message-ID: <1c2e02e7-6b1a-acf7-15b0-e7b4ead4b412@oracle.com> On 05/09/2016 15:50, Jochen Theodorou wrote: > > getResource did not get caller sensitive, right? The Class getResource/getResourceAsStream methods are but this is only relevant if you are invoke them on classes in named modules. This is why I was asking what "this.class" was in the previous mail. -Alan From martin.lehmann at gmx.de Mon Sep 5 17:26:53 2016 From: martin.lehmann at gmx.de (Martin Lehmann) Date: Mon, 5 Sep 2016 19:26:53 +0200 Subject: A few questions on layers ... and a compile problem with split-package caused by automatic module Message-ID: <000a01d2079a$b24a0880$16de1980$@gmx.de> Hi all, I have a few questions regarding layers, especially to "split package compile problem caused by automatic module". I tried out my examples with build b132. Any help is much appreciated! Thanks in advance, Martin! In some examples, I am creating a hierarchy of layers as follows: boot (with 1 module mod.main) --isparentof -- "top" layer (with 1 module mod.x_top) --isparentof -- "middle" layer (with 1 module mod.x_middle) --isparentof -- "bottom" layer (with 1 module mod.x_bottom) Question 1) Is there any way to give a layer a name or an ID? My current workaround is to put my layers to a map which do the name <-> layer-instance mapping which is not nice. Please consider to allow layer names, thanks. Question 2) The creation of the layer in my code looks more or less as follows. A starter class in module mod.main (in the boot layer) creates all the other layers. Via naming convention of module names (suffix of module must match the layer name), all relevant modules are found (from a single module path) and added/resolved with Configuration.resolveRequires() void createJigsawLayersAndAddModules() { Layer parentLayer = Layer.boot(); Path modPath = Paths.get("./mlib").toAbsolutePath().normalize(); ModuleFinder finder = ModuleFinder.of(modPath); Set allModules = finder.findAll(); for (String layerName: new String[] {"top", "middle", "bottom"}) { Set allFilteredModuleNames = new HashSet<>(); allModules.stream() .map(modRef -> modRef.descriptor().name()) .filter(modName -> modName.contains("_"+layerName)) // naming convention .forEach(modName -> allFilteredModuleNames.add(modName)); // *** Configuration cf = parentLayer.configuration() .resolveRequires(ModuleFinder.of(), finder, allFilteredModuleNames); Layer layer = parentLayer .defineModulesWithOneLoader(cf, ClassLoader.getSystemClassLoader()); parentLayer = layer; } } What's the visibility of modules (i.e. their classes) along the layer hierarchy / relationships? I had expected that a module (i.e. its classes) can only see modules (i.e. classes) in the same layer or in its parent or in any of its parent layers. I have tried this with a class hierarchy where a class in "bottom" is derived from a super class in "middle" which is again derived from a super class in "top". For that readability is needed from bottom -> middle -> top. Works as expected. On the other hand, my starter module mod.main is in the topmost boot layer. Via reflection, it can see and call anything from there in any module (i.e. also classes in "lower layers", i.e. in top, middle and bottom). If readability and accessibility are given either statically in module-infos or dynamically at runtime, then are there any constraints of what can be seen / called? Question 3) Is there any way to add / delete modules from a given configuration? For now I used the 2 code lines above (***) to use the parent layer's configuration when creating a new configuration for a new layer. I have not found any API to add / delete modules "on the fly". Did I miss something? Question 4) With using (***) I cannot "instantiate" a module twice along the layer hierarchy (which makes sense). So a module in a parent layer is already resolved and not added to the new layer again. Correct? Would it be possible to add the same module to two sibling layers (i.e. the children of the same parent layer)? Or to cousins or ... ;-) Is it needed to use the parentLayer's configuration? Or is there any way to create new configuration just for the new layer without "looking up the chain"? Question 5) I tried out if the split package problem does not occur, when the mod.x* modules have/export the same package, but are put to different layers. Works fine indeed, no split package problem occurs. Also, from my mod.main module, I can call all of them via reflection. Normally I am compiling mod.main, mod.x_top, mod.x_middle, mod.x_bottom at the same time with this bash script one-liner: $JAVA_HOME/bin/javac -d mods --module-path mlib -modulesourcepath src $(find src -name "*.java") The split package problem in mod.x* does not cause compile problems, because no other module has a read relationship to them at compile time. Instead, the mod.x* modules with the split package problem are only read/required and called via reflection from mod.main. So far so good. Now I wanted to extend my mod.main module to parse a layer "topology" from a JSON file instead of hard-coding the top/middle/bottom hierarchy. I hence added javax.json-1.0.4.jar to amlib, added "requires javax.json;" to mod.main's module-info. Only by doing that I am running into these unexpected compile errors (checked with b127 and b132): error: module reads package pkgx from both mod.x_top and mod.x_middle error: module reads package pkgx from both mod.x_top and mod.x_bottom error: module javax.json reads package pkgx from both mod.x_top and mod.x_middle error: module javax.json reads package pkgx from both mod.x_top and mod.x_bottom 4 errors I assume that having added the automatic module javax.json , I now implicitely added a read-relationship to *all* other modules at compile time, i.e. also to mod.x* modules. With that, the split package problem now prevents compile success. Let me emphasize that I have no reads static relationship to the mod.x* modules *anywhere* (not in code, not via compiler command-line options). It seems pretty (too?) restrictive to me, that simply adding a third-part lib (i.e. an already compiled automatic module) now prevents the compilation of (totally unrelated) code. Is that a known and wanted behaviour? Even then you should consider of correcting the compiler error messages: The first two of them do not include the cause's module name. For whatever reason only the latter two do show the correct problem cause "module javax.json". And yes, by compiling the mod.x* modules separately from the rest, I can get around the compile problem. Still, this looks bit awkward to me... From Alan.Bateman at oracle.com Mon Sep 5 20:35:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Sep 2016 21:35:22 +0100 Subject: A few questions on layers ... and a compile problem with split-package caused by automatic module In-Reply-To: <000a01d2079a$b24a0880$16de1980$@gmx.de> References: <000a01d2079a$b24a0880$16de1980$@gmx.de> Message-ID: On 05/09/2016 18:26, Martin Lehmann wrote: > : > > > Question 1) Is there any way to give a layer a name or an ID? My current > workaround is to put my layers to a map which do the name <-> layer-instance > mapping which is not nice. Please consider to allow layer names, thanks. Layers don't have names. It's come up once or twice in the context of diagnosability as it's potentially useful to have in stack traces. I think TBD as to whether to do this or not, esp. given the number of fields that are now going into the stack trace element. > : > > What's the visibility of modules (i.e. their classes) along the layer > hierarchy / relationships? I had expected that a module (i.e. its classes) > can only see modules (i.e. classes) in the same layer or in its parent or in > any of its parent layers. > I have tried this with a class hierarchy where a class in "bottom" is > derived from a super class in "middle" which is again derived from a super > class in "top". For that readability is needed from bottom -> middle -> top. > Works as expected. When using the Layer defineModulesWithXXX methods then the class loader delegation supports the readability graph. So from a module then you will be able to "see" any of the types in the packages exported by the modules that is reads. In addition, I note in your example that you've specified the system class loader as the parent class loader. This means that you can "see" types that are visible via the system class loader too (assuming no overlapping packages in the graph of modules). > On the other hand, my starter module mod.main is in the topmost boot layer. > Via reflection, it can see and call anything from there in any module (i.e. > also classes in "lower layers", i.e. in top, middle and bottom). Are you using Class.forName and specifying the class loader for top, middle or bottom? Alternatively maybe one of the types in modules defined to these layers is leaking back to code in mod.main. > > If readability and accessibility are given either statically in module-infos > or dynamically at runtime, then are there any constraints of what can be > seen / called? If you are using the 3-arg Class.forName then this allows you to get a reference to any type in any module. > : > > > Question 3) > Is there any way to add / delete modules from a given configuration? For > now I used the 2 code lines above (***) to use the parent layer's > configuration when creating a new configuration for a new layer. > I have not found any API to add / delete modules "on the fly". Did I miss > something? No, that is different design. > > > Question 4) > With using (***) I cannot "instantiate" a module twice along the layer > hierarchy (which makes sense). So a module in a parent layer is already > resolved and not added to the new layer again. Correct? > Would it be possible to add the same module to two sibling layers (i.e. the > children of the same parent layer)? Or to cousins or ... ;-) > Is it needed to use the parentLayer's configuration? Or is there any way to > create new configuration just for the new layer without "looking up the > chain"? No issue with overriding a module in a child layer or having two sibling layers with the same module. I note that in your code fragment that you specify "finder" as the second parameter to resolveRequires - this is the "after" ModuleFinder that is used when the module cannot be found by the "before" ModuleFinder and cannot be found in the parent layer. > : > > > Now I wanted to extend my mod.main module to parse a layer "topology" from a > JSON file instead of hard-coding the top/middle/bottom hierarchy. I hence > added javax.json-1.0.4.jar to amlib, added "requires javax.json;" to > mod.main's module-info. Only by doing that I am running into these > unexpected compile errors (checked with b127 and b132): > error: module reads package pkgx from both mod.x_top and mod.x_middle > error: module reads package pkgx from both mod.x_top and mod.x_bottom > error: module javax.json reads package pkgx from both mod.x_top and > mod.x_middle > error: module javax.json reads package pkgx from both mod.x_top and > mod.x_bottom > 4 errors > > I assume that having added the automatic module javax.json , I now > implicitely added a read-relationship to *all* other modules at compile > time, i.e. also to mod.x* modules. With that, the split package problem now > prevents compile success. Let me emphasize that I have no reads static > relationship to the mod.x* modules *anywhere* (not in code, not via compiler > command-line options). Automatic modules read all other modules. I need to double check your observations because there was an issue with javac where it granted implied readability to all explicit modules when it should have only done so for automatic modules. I thought it had been fixed so needs to be checked. -Alan From sundararajan.athijegannathan at oracle.com Tue Sep 6 10:12:39 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 6 Sep 2016 15:42:39 +0530 Subject: RFR 8163952: jlink exclude VM plugin does not support static libraries Message-ID: <8cad3759-ed22-c8d3-cecc-d38a7b7183c2@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8163952 Thanks, -Sundar From james.laskey at oracle.com Tue Sep 6 12:07:50 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 6 Sep 2016 09:07:50 -0300 Subject: RFR 8163952: jlink exclude VM plugin does not support static libraries In-Reply-To: <8cad3759-ed22-c8d3-cecc-d38a7b7183c2@oracle.com> References: <8cad3759-ed22-c8d3-cecc-d38a7b7183c2@oracle.com> Message-ID: <7080D009-4022-4930-A99F-0ABD1620241B@oracle.com> +1 > On Sep 6, 2016, at 7:12 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8163952 > > Thanks, > > -Sundar > From anthony.vanelverdinghe at gmail.com Tue Sep 6 14:50:41 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Tue, 6 Sep 2016 16:50:41 +0200 Subject: RFR 8163952: jlink exclude VM plugin does not support static libraries In-Reply-To: <8cad3759-ed22-c8d3-cecc-d38a7b7183c2@oracle.com> References: <8cad3759-ed22-c8d3-cecc-d38a7b7183c2@oracle.com> Message-ID: Hi Sundar I'm not familiar with the code, but the for-loop at lines 105-107 looks like a bug, since only the first element is considered: 105 for (String jvmlib : jvmlibs) { 106 return t.path().endsWith("/" + jvmlib); 107 } Kind regards, Anthony On 6/09/2016 12:12, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8163952 > > Thanks, > > -Sundar > From james.laskey at oracle.com Tue Sep 6 14:55:32 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 6 Sep 2016 11:55:32 -0300 Subject: RFR 8163952: jlink exclude VM plugin does not support static libraries In-Reply-To: References: <8cad3759-ed22-c8d3-cecc-d38a7b7183c2@oracle.com> Message-ID: I missed that as well. Good catch. > On Sep 6, 2016, at 11:50 AM, Anthony Vanelverdinghe wrote: > > Hi Sundar > > I'm not familiar with the code, but the for-loop at lines 105-107 looks like a bug, since only the first element is considered: > > 105 for (String jvmlib : jvmlibs) { > 106 return t.path().endsWith("/" + jvmlib); > 107 } > > Kind regards, > Anthony > > > On 6/09/2016 12:12, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for >> https://bugs.openjdk.java.net/browse/JDK-8163952 >> >> Thanks, >> >> -Sundar >> > From sundararajan.athijegannathan at oracle.com Tue Sep 6 15:08:24 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 6 Sep 2016 20:38:24 +0530 Subject: RFR 8163952: jlink exclude VM plugin does not support static libraries In-Reply-To: References: <8cad3759-ed22-c8d3-cecc-d38a7b7183c2@oracle.com> Message-ID: <1dc6cde6-3dad-c68c-e0f0-05f2897fdbdc@oracle.com> Yep, my mistake - Sorry! Thanks for the catch. Will file a bug. PS. I suspect test ran -- but jlink missed removing those .a static libraries! Thanks -Sundar On 9/6/2016 8:25 PM, Jim Laskey (Oracle) wrote: > I missed that as well. Good catch. > > >> On Sep 6, 2016, at 11:50 AM, Anthony Vanelverdinghe wrote: >> >> Hi Sundar >> >> I'm not familiar with the code, but the for-loop at lines 105-107 looks like a bug, since only the first element is considered: >> >> 105 for (String jvmlib : jvmlibs) { >> 106 return t.path().endsWith("/" + jvmlib); >> 107 } >> >> Kind regards, >> Anthony >> >> >> On 6/09/2016 12:12, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for >>> https://bugs.openjdk.java.net/browse/JDK-8163952 >>> >>> Thanks, >>> >>> -Sundar >>> From mark.reinhold at oracle.com Tue Sep 6 15:50:12 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 06 Sep 2016 08:50:12 -0700 Subject: Feedback on proposal for #ReflectiveAccessToNonExportedTypes In-Reply-To: <84093C81-ED37-4747-9E46-917561CA8BA6@redhat.com> References: <577ED372.6010806@oracle.com> <1C679BF6-5B89-468D-BC67-43C3615D75BC@redhat.com> <20160713214737.35BAFB79B7@eggemoggin.niobe.net> <20160718213004.21AD4B9282@eggemoggin.niobe.net> <84093C81-ED37-4747-9E46-917561CA8BA6@redhat.com> Message-ID: <20160906085012.812938063eggemoggin.niobe.net> (Finally getting back to this thread, now that vacation season is over.) 2016/7/21 10:01:11 -0700, jason.greene at redhat.com: > On Jul 18, 2016, at 4:30 PM, mark.reinhold at oracle.com wrote: >> 2016/7/13 20:27:45 -0700, jason.greene at redhat.com: >>> ... >>> >>> Sorry for the confusion, what I was trying to say on this point was a bit >>> different. What I was trying to say was: >>> >>> (2') It weakens encapsulation by forcing the introduction of exports >>> introducing potential conflicts that break applications. >>> >>> As an example, assume I have three modules with classloader-per-module >>> isolation (A, B, and Victim) >>> >>> - A exports foo, and has a non-exported package ?bar" >>> >>> - B exports bar >>> >>> - Victim has a module-info with requires A; requires B >>> >>> Now A decides to use IoC on some of its classes in bar, so it?s >>> definition is changed to: >>> >>> { exports foo; exports dynamic bar; } >>> >>> Since exports dynamic is internally a normal export at runtime, module >>> resolution fails when loading Victim, because its now including a >>> duplicate package, even though A had no intention of publishing its >>> internal bar package for linkage. >> >> Got it. Thanks for clarifying this -- I agree that it's a problem. >> >> Fortunately I think we can address it simply by revising the semantics of >> `exports dynamic p` to omit the package-conflict constraint. This would >> allow split packages to occur more readily at run time, though still >> really only in fairly obscure situations involving poorly-written class >> loaders. > > That would help, but there is also class visibility issues that would > need to be addressed as well. > > Example 1 (Ambiguous class names): > > Both A and B export ?bar?, and both define ?bar.MyClass? which have > differing definitions. Victim could load the supposed to be hidden A?s > MyClass instead of the intended B?s MyClass. > > There is also a variant of this where the conflict is between Victim > and A if A also exports another hidden package that is present in > Victim itself. Alan addressed this in a nearby message. A high-level point worth emphasizing here is that visibility issues are class-loader issues, and Jigsaw (for the most part) does not dictate how custom class loaders should work. It's a good idea for class loaders to respect the readability relationships set up by the module system, but if they don't then there's nothing that the module system can really do about it. > Example 2 (Unintentional discovery): > > Victim uses ClassLoader.getResources (plural), looking for a standard > configuration file or class name, and receives entries for both A and > B. A?s was not intended to be discovered by victim, and leads to a > failure state. As an example perhaps the configuration file in B > specifies a class name in B?s dependency, which is not visible to > Victim. Or, perhaps A?s config leads to duplicate runtime actions being > configured (since the file was really only indented for A, which also > processes it) ... which you later amended: > Sorry for the confusion, this should read: > > " As an example perhaps the configuration file in [A] specifies a class > name in [A]?s dependency, which is not visible to Victim. Or, perhaps A?s > config leads to duplicate runtime actions being configured (since the > file was really only indented for A, which also processes it)" Alan also addressed this, in a couple of different nearby messages. Again, what the class loaders do in this example is not really up to the module system. This example can, however, be seen as an argument in favor of #ResourceEncapsulation, as Alan noted. If module A contains a resource that's strictly internal to A, and if the module system gives the author of A a way to encapsulate such resources, then the module system could help out in this case by refusing to locate that resource. (Resource location is one way in which Jigsaw may well change how all class loaders work.) > You can potentially address 1 with precedence, but not 2. > > I think you would need to say that export dynamic is only utilizable > for reflection permissions and has no other similarity with ?export? > (although perhaps that?s what you meant?) No, that's not what I meant. `exports dynamic` allows static (i.e., bytecode) references too; it just doesn't allow compile-time access. Anyway, this isn't an accessibility issue, as noted. > If you combine that approach with a wildcard capability like you > mentioned earlier then I?ll admit its very hard for me to quibble over > a one line additional requirement in module-info.java. Glad to hear it. > Although, for completeness, let me (re?)introduce one other > consideration that was briefly mentioned (although with sparing > details) earlier in the thread > > If you have a custom serialization framework that is supposed to be > identical to Java serialization in contract, then it becomes impossible > to mirror using the only available standard means (core reflection), > since that mechanism disallows non-exported packages. Currently a > custom serialization framework only needs to handle one non-standard > case (missing no-arg constructor). Going forward it would need to use > Unsafe for everything. If all the classes of all the objects to be serialized by such a framework are on the class path, or in automatic modules, or in exported or dynamically-exported packages of explicit modules, then it will just work. If any of the classes are strongly encapsulated in explicit modules, by the choice of the module's author -- as will be the case for most if not all JDK modules -- then the framework will indeed need to use Unsafe to serialize those classes. Most of the external serialization frameworks that we've seen already use Unsafe to achieve good performance, and Unsafe isn't going away in JDK 9, so in the near to medium term I don't see this as a problem. They might have to make a few adjustments to work properly on 9, but given that they're hacking into the internals of the system that shouldn't really surprise anyone. In the longer term we really need a better story for serialization so that external serializers can serialize instances of JDK classes without relying upon JDK internals. We have some ideas about how to do that, but they're completely out of scope for this release. > ... >>>> >>>> These observations lead to your suggestion to allow declarative module >>>> boundaries to be overridden by "trusted" framework code. It's far from >>>> clear how to define such a facility in a way that would still allow us to >>>> achieve one of our primary goals, namely strong encapsulation, i.e., the >>>> ability of the author of a module to declare which types are accessible >>>> by other components, and which are not. >>> >>> My understanding was the underlying driver was a security concern (that?s >>> were I was going with that suggestion). Is that accurate? >> >> It's a question of both security (i.e., preventing vulnerabilities) and >> integrity (i.e., respecting the intent of a module's author). >> >> For security, the problem with introducing an explicit notion of trust >> into any system, or in this case an additional explicit notion of trust, >> is that you then have to figure out how to prevent it from being used as >> an attack vector. >> >> Yes, we could define a notion of "trusted" modules whose code can reflect >> arbitrarily. Even if we implement and use it completely correctly in the >> JDK, however, there would be an API for it, and that API would be used by >> external library and application code, and eventually somebody, somewhere, >> would make a mistake that leads to a CVSS 10 in some production code. > > I think it could be done in a fairly clean manner. For example, you > could utilize something like JCE providers, and code which needs to > obtain this trust has to be signed by a framework provider with a > certificate that?s either been signed by a central JDK CA, or has been > explicitly deployed as a trust within the JVM. There would be a burden > for framework developers, but I assume they would prefer this over a > limited model. Anything having to do with PKI would be, I suspect, a rather extreme burden for framework developers. An approach that requires an end user somehow to install a framework module into a JVM so that it's trusted will have many of the same downsides that you point out below for command-line options. > You could also reuse the security manager infrastructure, and just add > a new permission. That would mean giving up on protection even without > a security manager, but if the user isn?t using a security manager then > that implies they are on a platform will all trusted code. One of the central goals of this entire project is to improve the integrity of the platform so that it's less costly to maintain and -- more importantly -- easier to evolve for the future. Enforcing module boundaries even when a security manager is not present, and providing only limited ways to override those boundaries, is critical to achieving that goal. >> In the Jigsaw design so far, therefore, we've tried instead to leverage >> existing implicit notions of trust wherever possible. >> >> We already trust whoever has control over the invocation of the Java >> run-time environment. If you can edit the `java` command line, or its >> equivalent, then you can already do pretty much anything you want, so >> there's little additional risk in providing command line options (as >> we do [1]) to break module-encapsulation boundaries. >> >> We also already trust whoever writes systems that explicitly load >> classes, i.e., container developers. If you can modify bytecodes on >> their way into the JVM then you already have significant power, so >> there's little additional risk in giving you the ability to control how >> modules are defined and related in the class loaders that you create. >> (In fact you already have this ability, since you can rewrite module >> descriptors prior to the configuration of a layer, so there's no need >> to create a special API for it.) > > So the main issue with these solutions is really the problems we list > above. > > The command line approach has issues with compatibility with all of the > various launch mechanism. For example you can?t just bundle a script > for the user, because IDEs launch the VM too, and ensuring those are > all in sync is brittle. The command line is also too early in the boot > process (unless its just export everything in all modules). > > The class loading approach also has the problem of requiring a > particular launch mechanism; you can?t, for example, support a standard > SE launch unless you require a particular agent on the command line. Yes, I agree that these approaches are limited but that is, as noted, by design. It will be simpler for everyone if we can devise a system that does not require placing trust in a framework, or using command-line flags, or using custom launchers, or whatever, except in extenuating circumstances or in the case of containers, which are expected to do such things and already have the power to do so. >> A natural consequence of this approach is that we need not place total >> trust in a framework in order to use it. A container can arrange for a >> framework to have reflective access to just the packages of just the >> modules that the framework is going to support, by adding qualified >> dynamic exports as needed, rather than grant it full reflective access >> to all code in the system. >> >> This approach does mean that container developers have a bit more work >> to do, but that seems a reasonable tradeoff if in return we're able to >> keep the platform simpler, and thus both easier to understand and easier >> to secure. > > I think its fair to require a few more steps of additional burden to an > advanced capability used by a framework developer, my concern is really > more in when it spills over into the end user. I share your concern. In the near term, end users will be impacted when they try to run existing code that reaches into JDK internals. There's no way to avoid that if we're going to improve the integrity of the platform for the long haul, which is why we've been warning people about it for years and providing a tool (jdeps) to aid in the transition. This isn't just an issue for the JDK, of course -- giving all module authors the ability to strongly encapsulate internals in ways that are difficult to break will be of benefit to everyone in the long run. >> As to integrity, if the author of a module decides not to export a >> specific package then they should be able to expect that decision to be >> respected, and not overridden lightly by any random code in the system >> that uses reflection. Whoever controls the `java` command line or sets >> up the container in which the module ultimately runs can override that >> encapsulation decision, and they may have very good and legitimate >> reasons to do so. At that point, however, they take on the burden of >> bearing the consequences of any violation of the module author's intent. >> If a future version of the module, e.g., removes an encapsulated package >> in a way that causes reflective code to fail then that is not the fault >> of the module author but, rather, of whoever decided to break into the >> package. > > Wouldn?t you agree though that we already have this balance today? You > have to use setAccessible and a security permission to override the > accessibility contract expressed by the developer. No, I don't think we do have that balance today. History shows that `setAccessible` and a security permission are woefully ineffective barriers. For twenty years we've been extremely conservative about changing the internals of the JDK, since we have no idea what random but customer-critical code out there might be using reflection to dig into it. Every release is a gamble in which we have to be prepared for last-minute P1 bug reports of major applications failing to run because they use some long-unmaintained library that relies upon JDK internals. It's time for this to stop, and for us all to move on. (Sorry for the rant. Horror stories available on demand, over beer.) > ... > >>> >>> Perhaps this problem could be addressed by addressed by an indirection >>> that represents a role or an actor (e.g. something like "export dynamic * >>> to role runtime?). I haven?t thought that through though. >> >> Happily, I don't think we need to go that far. > > I agree that modifying exports dynamic to avoid side effects is a > superior solution to the indirection idea. Good. >> A container is in complete control of the class loaders that it creates, >> so it already has the power to load arbitrary classes into arbitrary >> modules. If a container needs to add a dynamic export at run time then >> it can synthesize a tiny class whose static initializer invokes the >> java.lang.Module::addExports method as needed, and then define that class >> in the target module. >> >> We already use this technique in the JDK's Nashorn JavaScript engine, >> which loads script classes into modules that are defined completely at >> run time. (As Alex mentioned, there will be a talk on this at the >> upcoming JVM Language Summit, and the video will be available shortly >> thereafter. We'll post a link here when it's available.) > > Thanks that would be useful to read. Here's a link to the video: https://www.youtube.com/watch?v=Zk6a6jNZAt0 - Mark From jarthana at in.ibm.com Tue Sep 6 16:47:15 2016 From: jarthana at in.ibm.com (Jayaprakash Arthanareeswaran) Date: Tue, 6 Sep 2016 16:47:15 +0000 Subject: Fw: Any word on the updated spec Message-ID: From blackdrag at gmx.org Tue Sep 6 20:25:03 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 6 Sep 2016 22:25:03 +0200 Subject: problem with Class#getResource In-Reply-To: <1c2e02e7-6b1a-acf7-15b0-e7b4ead4b412@oracle.com> References: <57CC2327.6020604@gmx.org> <2cedbfcf-28f1-fb9f-d6f4-ddf178ee0628@oracle.com> <57CD6FD7.60100@gmx.org> <57CD8642.7030500@gmx.org> <1c2e02e7-6b1a-acf7-15b0-e7b4ead4b412@oracle.com> Message-ID: <57CF261F.30509@gmx.org> On 05.09.2016 17:00, Alan Bateman wrote: > On 05/09/2016 15:50, Jochen Theodorou wrote: > >> >> getResource did not get caller sensitive, right? > The Class getResource/getResourceAsStream methods are but this is only > relevant if you are invoke them on classes in named modules. This is why > I was asking what "this.class" was in the previous mail. ok, turns out getResource is doing the right thing for me actually. The error was instead in the JVM forking code deeper down, that just surfaced strangely. Sorry for the false alarm bye Jochen From ropalka at redhat.com Tue Sep 6 22:31:51 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 7 Sep 2016 00:31:51 +0200 Subject: Upgradeable Modules Question Message-ID: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> Hi Jigsaw team, Can Jigsaw module be both upgreadeable and automatic? Thanks, Richard From alex.buckley at oracle.com Tue Sep 6 22:37:55 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 06 Sep 2016 15:37:55 -0700 Subject: Upgradeable Modules Question In-Reply-To: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> References: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> Message-ID: <57CF4543.3070402@oracle.com> On 9/6/2016 3:31 PM, Richard Opalka wrote: > Can Jigsaw module be both upgreadeable and automatic? No. By definition, an upgradeable module is a module linked into a runtime image. An automatic module is not linked into a runtime image. Alex From jwkozaczuk at gmail.com Wed Sep 7 01:07:13 2016 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Tue, 6 Sep 2016 21:07:13 -0400 Subject: Can jdeps resolve unnecessary dependencies? Message-ID: So jdeps can recursively identify all dependencies given a list of the jars that my application is made of. Assume my main application jar is app.jar and it depends (per gradle or maven dependencies resolution) on following libraries like so: app.jar ----> a.jar, b.jar a.jar --> x.jar, y.jar, z.jar x.jar -> profile1 y.jar -> profile2 z.jar -> profile3 And now assume that the app.jar in reality depends only on the part of a.jar that depends only on x.jar. In other words in reality statically (no reflection) my application does not really depend on y.jar and z.jar and only needs compact1 to execute properly. There are libraries that are "well focused" and have very few dependencies and there are those that pull ton of dependencies even though an application may only be using 5% of it. Would jdeps show only real or all dependencies in this case? If latter would it show enough information that can be analyzed to determine that y.jar and z.jar are not really needed and can be removed from my deployment? Would Java 9 jdeps work differently in this case? Would jlink be able to figure the "real" dependencies and only pull really needed JRE modules into the output image? Waldek From mandy.chung at oracle.com Wed Sep 7 02:24:56 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 6 Sep 2016 19:24:56 -0700 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: References: Message-ID: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> > On Sep 6, 2016, at 6:07 PM, Waldek Kozaczuk wrote: > > So jdeps can recursively identify all dependencies given a list of the > jars that my application is made of. Assume my main application jar is > app.jar and it depends (per gradle or maven dependencies resolution) on > following libraries like so: > > app.jar ----> a.jar, b.jar > a.jar --> x.jar, y.jar, z.jar > x.jar -> profile1 > y.jar -> profile2 > z.jar -> profile3 > > And now assume that the app.jar in reality depends only on the part of > a.jar that depends only on x.jar. In other words in reality statically > (no reflection) my application does not really depend on y.jar and z.jar > and only needs compact1 to execute properly. There are libraries that > are "well focused" and have very few dependencies and there are those > that pull ton of dependencies even though an application may only be > using 5% of it. > > Would jdeps show only real or all dependencies in this case? If latter > would it show enough information that can be analyzed to determine that > y.jar and z.jar are not really needed and can be removed from my deployment? > $ jdeps -R -s -cp a.jar:b.jar:x.jar:y.jar:z.jar app.jar This will recursively analyze the run-time view of the dependencies from app.jar. The -s option shows the summary and doesn?t list the package-level dependencies. It will start with all types in app.jar and then transitively analyze the referenced classes. y.jar and z.jar will not be shown in the output if no type from those jar files are used at runtime. $ jdeps ?-compile-time -s -cp a.jar:b.jar:x.jar:y.jar:z.jar app.jar This will recursively analyze the compile-time view from app.jar. It will start with app.jar and then recursively analyze the JAR files containing its referenced types. In other words, it will show the dependenencies as the example above. > Would Java 9 jdeps work differently in this case? jdeps -?compile-time option is a new option added in jdk9 jdeps. > Would jlink be able to > figure the "real" dependencies and only pull really needed JRE modules > into the output image? jlink will do the resolution per the specified root set and determine the resulting modules to be linked in to the output image. The dependences are declared in the module descriptors. You can refer the details in JEP 261 [1] and JEP 282 [2] Mandy [1] http://openjdk.java.net/jeps/261 [2] http://openjdk.java.net/jeps/282 From Alan.Bateman at oracle.com Wed Sep 7 06:24:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Sep 2016 07:24:40 +0100 Subject: Upgradeable Modules Question In-Reply-To: <57CF4543.3070402@oracle.com> References: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> <57CF4543.3070402@oracle.com> Message-ID: On 06/09/2016 23:37, Alex Buckley wrote: > On 9/6/2016 3:31 PM, Richard Opalka wrote: >> Can Jigsaw module be both upgreadeable and automatic? > > No. By definition, an upgradeable module is a module linked into a > runtime image. An automatic module is not linked into a runtime image. Maybe the question is asking if it's possible to deploy an automatic module on the upgrade module path to upgrade a module in the runtime image? That is possible of course (and necessary in the case of the java.transaction module because the EE version has dependences that aren't modules yet). -Alan From ropalka at redhat.com Wed Sep 7 07:49:53 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 7 Sep 2016 09:49:53 +0200 Subject: Upgradeable Modules Question In-Reply-To: References: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> <57CF4543.3070402@oracle.com> Message-ID: Hi Alan, On 09/07/2016 08:24 AM, Alan Bateman wrote: > On 06/09/2016 23:37, Alex Buckley wrote: > >> On 9/6/2016 3:31 PM, Richard Opalka wrote: >>> Can Jigsaw module be both upgreadeable and automatic? >> >> No. By definition, an upgradeable module is a module linked into a >> runtime image. An automatic module is not linked into a runtime image. > Maybe the question is asking if it's possible to deploy an automatic > module on the upgrade module path to upgrade a module in the runtime > image? That is possible of course (and necessary in the case of the > java.transaction module because the EE version has dependences that > aren't modules yet). > > -Alan Your guess was correct Alan (my english isn't perfect). Yes my distorted question was whether it should be possible to "upgrade" Jigsaw module with automatic module. Few more questions: * Module java.se.ee defines list of upgradeable modules (related to EE). Is it enforced by JDK (at both compile time and runtime) only upgradeable modules can be upgraded? There are no other upgradeable modules except those listed in java.se.ee, right? Or one could upgrade any module not provided by Boot loader? * Both AppClassLoader and PlatformClassLoader don't override ClassLoader.getResource(String) method which fallbacks to NOOP ClassLoader::findResource(String). Shouldn't they implement it? I'm asking because I upgraded JAXB module locally with automatic module. There's META-INF/services/javax.xml.bind.JAXBContext provided there but resourceLookup doesn't work. Richard From Alan.Bateman at oracle.com Wed Sep 7 08:32:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Sep 2016 09:32:54 +0100 Subject: Upgradeable Modules Question In-Reply-To: References: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> <57CF4543.3070402@oracle.com> Message-ID: <568db33a-66f6-f491-ffa8-7df1bbef4d50@oracle.com> On 07/09/2016 08:49, Richard Opalka wrote: > > Your guess was correct Alan (my english isn't perfect). > Yes my distorted question was whether it should be possible to > "upgrade" Jigsaw module with automatic module. Yes, you do can do this. > > Few more questions: > > * Module java.se.ee defines list of upgradeable modules (related to EE). > Is it enforced by JDK (at both compile time and runtime) > only upgradeable modules can be upgraded? It's not enforced at compile-time, there is an open issue (JDK-8133882) to ponder that point. It is enforced (by way of hashes) at link-time and run-time. > There are no other upgradeable modules except > those listed in java.se.ee, right? For the Java SE modules then that is correct. The list is of course something that the JSR for Java SE 9 will need to decide on. These APIs have always been upgradeable via the endorsed standards override mechanism (most have been leading a double life as standalone technologies too). There may be some other modules that are upgradeable. In the Oracle builds then the java.jnlp module is upgradable, as are the modules with Java Web Start and the Java Plugin. > Or one could upgrade any module not provided by Boot loader? None of the upgradeable modules are defined to the boot loader. > > * Both AppClassLoader and PlatformClassLoader don't override > ClassLoader.getResource(String) method which fallbacks to NOOP > ClassLoader::findResource(String). Shouldn't they implement it? They implement/override findResource/findResources. > > I'm asking because I upgraded JAXB module locally with automatic module. > There's > > META-INF/services/javax.xml.bind.JAXBContext > > provided there but resourceLookup doesn't work. Can you provide a bit more detail as to what you are using an the automatic module? Ideally it would be something like: --upgrade-module-path eemods --add-modules java.xml.bind but I'm guessing you might have artifacts like jaxb-api-.jar, in which case the derived module name isn't useful. One thing to mention is there are changes to JAXB to work with modules. Those changes are in the JDK and I believe are also in the upstream Metro project where the RI is maintained. The MR of JSR 222 hasn't been done yet so there isn't a released standalone version with the updated support. I only bring it up in case you might be running into issues here. AFAIK, the more significant update is the additional of new service type, javax.xml.bind.JAXBContextFactory and updates to the spec to work with ServiceLoader. At a guess then you might be using an old version that doesn't have any of this. One other thing is to ask is whether you see any difference with the Jigsaw EA builds. I ask because those builds don't have resource encapsulation, pending resolution of this issue in the JSR. -Alan From martin.lehmann at gmx.de Wed Sep 7 09:50:50 2016 From: martin.lehmann at gmx.de (Martin Lehmann) Date: Wed, 7 Sep 2016 11:50:50 +0200 Subject: A few questions on layers ... and a compile problem with split-package caused by automatic module In-Reply-To: References: <000a01d2079a$b24a0880$16de1980$@gmx.de> Message-ID: <000001d208ed$5152add0$f3f80970$@gmx.de> Hi Alan, thanks for your answers. Sorry for the late answer but I meanwhile uploaded the example to Github: https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-examples/e xample_layer-hierarchy mod.main: LayerBuilder does the startup of Jigsaw layers: https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/pkgmain/LayerBuilder.java ModuleCaller does the reflective calls to other modules: https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/pkgmain/ModuleCaller.java mod.x_bottom/middle/top have been mentioned already. The other modules are similar to mod.x*: mod.y* is for class derivation across module/layer boundaries. mod.z* is an example for delegation across module/layer boundaries. mod.layer for my own tree structure of layers: https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.layer It is constructed from a JSON file and each layer node in the tree has a name, keeps references to parent / child nodes in the tree.. and also a reference to the Jigsaw layer. PS: Do I understand correctly, that a Jigsaw layer can see its parent layer, but there is no API to retrieve its children layers? If not, is there any way to globally retrieve "all layers" for iteration? I think, that I once saw a similar question on this mailing list but cannot find the mail thread right now... > > Question 1) Is there any way to give a layer a name or an ID? My > > current workaround is to put my layers to a map which do the name <-> > > layer-instance mapping which is not nice. Please consider to allow layer names, thanks. > Layers don't have names. It's come up once or twice in the context of diagnosability as it's potentially useful to have in stack traces. I think TBD as to whether to do this or not, esp. given the number of fields that are now going into the stack trace element. Yes, please consider to add that functionality. Will also help in regression tests (as Layer.toString() will print a different hashCode every time, so result containing the layer info will differ). > > What's the visibility of modules (i.e. their classes) along the layer > > hierarchy / relationships? I had expected that a module (i.e. its > > classes) can only see modules (i.e. classes) in the same layer or in > > its parent or in any of its parent layers. > > I have tried this with a class hierarchy where a class in "bottom" is > > derived from a super class in "middle" which is again derived from a > > super class in "top". For that readability is needed from bottom -> middle -> top. > > Works as expected. > When using the Layer defineModulesWithXXX methods then the class loader delegation supports the readability graph. So from a module then you will be able to "see" any of the types in the packages exported by the modules that is > reads. In addition, I note in your example that you've specified the system class loader as the parent class loader. This means that you can "see" types that are visible via the system class loader too (assuming no overlapping packages in the graph of modules). Ok, thanks. > > On the other hand, my starter module mod.main is in the topmost boot layer. > > Via reflection, it can see and call anything from there in any module (i.e. > > also classes in "lower layers", i.e. in top, middle and bottom). > Are you using Class.forName and specifying the class loader for top, middle or bottom? No, I am not using Class.forName. Instead I am using layer.findLoader. See line #64 here: https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/pkgmain/ModuleCaller.java > Alternatively maybe one of the types in modules defined to these layers is leaking back to code in mod.main. Hm, no. There is no relationship from any of the mod.x* modules to mod.main, see here https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/module-info.java All is done via reflection. > > > > If readability and accessibility are given either statically in module-infos > > or dynamically at runtime, then are there any constraints of what can be > > seen / called? > If you are using the 3-arg Class.forName then this allows you to get a > reference to any type in any module. > > Question 3) > > Is there any way to add / delete modules from a given configuration? For > > now I used the 2 code lines above (***) to use the parent layer's > > configuration when creating a new configuration for a new layer. > > I have not found any API to add / delete modules "on the fly". Did I miss > > something? > No, that is different design. I think I am missing your point here... Do you mean "No, that would a different design and is (currently) not supported/available". Or do you mean: "Well, yes, there is a different API for that". (If the latter, which one?) Guess, it's not supported for now. > > Question 4) > > With using (***) I cannot "instantiate" a module twice along the layer > > hierarchy (which makes sense). So a module in a parent layer is already > > resolved and not added to the new layer again. Correct? > > Would it be possible to add the same module to two sibling layers (i.e. the > > children of the same parent layer)? Or to cousins or ... ;-) > > Is it needed to use the parentLayer's configuration? Or is there any way to > > create new configuration just for the new layer without "looking up the > > chain"? > No issue with overriding a module in a child layer or having two sibling layers with the same module. I note that in your code fragment that you specify "finder" as the second parameter to resolveRequires - this is the "after" ModuleFinder that is used when the module cannot be found by the "before" ModuleFinder and cannot be found in the parent layer. Yep, I can confirm that. Works perfect :-) > > Now I wanted to extend my mod.main module to parse a layer "topology" from a > > JSON file instead of hard-coding the top/middle/bottom hierarchy. I hence > > added javax.json-1.0.4.jar to amlib, added "requires javax.json;" to > > mod.main's module-info. Only by doing that I am running into these > > unexpected compile errors (checked with b127 and b132): > > error: module reads package pkgx from both mod.x_top and mod.x_middle > > error: module reads package pkgx from both mod.x_top and mod.x_bottom > > error: module javax.json reads package pkgx from both mod.x_top and > > mod.x_middle > > error: module javax.json reads package pkgx from both mod.x_top and > > mod.x_bottom > > 4 errors > > > > I assume that having added the automatic module javax.json , I now > > implicitely added a read-relationship to *all* other modules at compile > > time, i.e. also to mod.x* modules. With that, the split package problem now > > prevents compile success. Let me emphasize that I have no reads static > > relationship to the mod.x* modules *anywhere* (not in code, not via compiler > > command-line options). > Automatic modules read all other modules. I need to double check your observations because there was an issue with javac where it granted implied readability to all explicit modules when it should have only done so for automatic modules. I thought it had been fixed so needs to be checked. Ok, thanks. I can confirm, that this compile issue is still there with b134. From sundararajan.athijegannathan at oracle.com Wed Sep 7 11:43:39 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 7 Sep 2016 17:13:39 +0530 Subject: RFR 8165503: jlink exclude VM plugin's handling of jvmlibs is wrong Message-ID: Please review http://cr.openjdk.java.net/~sundar/8165503/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165503 Thanks, -Sundar From james.laskey at oracle.com Wed Sep 7 11:47:31 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 7 Sep 2016 08:47:31 -0300 Subject: RFR 8165503: jlink exclude VM plugin's handling of jvmlibs is wrong In-Reply-To: References: Message-ID: <4FD2DBDA-A256-4FCD-B68C-6382CA6C3F4F@oracle.com> +1 > On Sep 7, 2016, at 8:43 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8165503/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8165503 > > Thanks, > > -Sundar > From ropalka at redhat.com Wed Sep 7 12:43:16 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 7 Sep 2016 14:43:16 +0200 Subject: Upgradeable Modules Question In-Reply-To: <568db33a-66f6-f491-ffa8-7df1bbef4d50@oracle.com> References: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> <57CF4543.3070402@oracle.com> <568db33a-66f6-f491-ffa8-7df1bbef4d50@oracle.com> Message-ID: <5f5f5095-6c9e-56a8-d079-2c807481a557@redhat.com> On 09/07/2016 10:32 AM, Alan Bateman wrote: > On 07/09/2016 08:49, Richard Opalka wrote: > >> >> Your guess was correct Alan (my english isn't perfect). >> Yes my distorted question was whether it should be possible to >> "upgrade" Jigsaw module with automatic module. > Yes, you do can do this. Thanks for clarification. >> >> Few more questions: >> >> * Module java.se.ee defines list of upgradeable modules (related to >> EE). >> Is it enforced by JDK (at both compile time and runtime) >> only upgradeable modules can be upgraded? > It's not enforced at compile-time, there is an open issue > (JDK-8133882) to ponder that point. > > It is enforced (by way of hashes) at link-time and run-time. Thanks for clarification. > >> There are no other upgradeable modules except >> those listed in java.se.ee, right? > For the Java SE modules then that is correct. The list is of course > something that the JSR for Java SE 9 will need to decide on. These > APIs have always been upgradeable via the endorsed standards override > mechanism (most have been leading a double life as standalone > technologies too). > > There may be some other modules that are upgradeable. In the Oracle > builds then the java.jnlp module is upgradable, as are the modules > with Java Web Start and the Java Plugin. ok > > >> Or one could upgrade any module not provided by Boot loader? > None of the upgradeable modules are defined to the boot loader. > >> >> * Both AppClassLoader and PlatformClassLoader don't override >> ClassLoader.getResource(String) method which fallbacks to NOOP >> ClassLoader::findResource(String). Shouldn't they implement it? > They implement/override findResource/findResources. I oversaw it :( > >> >> I'm asking because I upgraded JAXB module locally with automatic module. >> There's >> >> META-INF/services/javax.xml.bind.JAXBContext >> >> provided there but resourceLookup doesn't work. > Can you provide a bit more detail as to what you are using an the > automatic module? Ideally it would be something like: > > --upgrade-module-path eemods --add-modules java.xml.bind That was my problem of course. I didn't activate that module (forgot they are off by default) and thus the jaxb-api from unnamed classpath module was used instead. There was no JAXB impl on classpath. Just in my upgradeable automatic module (that was off). > but I'm guessing you might have artifacts like jaxb-api-.jar, > in which case the derived module name isn't useful. I used exploded directory named java.xml.bind (of course without module-info.class). > > One thing to mention is there are changes to JAXB to work with > modules. Those changes are in the JDK and I believe are also in the > upstream Metro project where the RI is maintained. The MR of JSR 222 > hasn't been done yet so there isn't a released standalone version with > the updated support. I only bring it up in case you might be running > into issues here. AFAIK, the more significant update is the additional > of new service type, javax.xml.bind.JAXBContextFactory and updates to > the spec to work with ServiceLoader. At a guess then you might be > using an old version that doesn't have any of this. Yes, I am aware of this. > > One other thing is to ask is whether you see any difference with the > Jigsaw EA builds. I ask because those builds don't have resource > encapsulation, pending resolution of this issue in the JSR. I'm testing build Jigsaw EA b134 ATM. Seems working better than previous releases. I still see some testsuite failures (investigation goes on). > > -Alan > Richard From jwkozaczuk at gmail.com Wed Sep 7 14:12:56 2016 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Wed, 7 Sep 2016 10:12:56 -0400 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> Message-ID: Mandy, Thanks for you response. Will I be able to take advantage of jlink's ability to produce subset-only image of the JRE even if I do not use new Java 9 modular jars? In other words if my app.jar and other dependent jars are old java 8 ones and do not have any module descriptors will jlink be able to identify only needed JRE modules and produce minimal runtime image? Waldek On Tue, Sep 6, 2016 at 10:24 PM, Mandy Chung wrote: > > > On Sep 6, 2016, at 6:07 PM, Waldek Kozaczuk > wrote: > > > > So jdeps can recursively identify all dependencies given a list of the > > jars that my application is made of. Assume my main application jar is > > app.jar and it depends (per gradle or maven dependencies resolution) on > > following libraries like so: > > > > app.jar ----> a.jar, b.jar > > a.jar --> x.jar, y.jar, z.jar > > x.jar -> profile1 > > y.jar -> profile2 > > z.jar -> profile3 > > > > And now assume that the app.jar in reality depends only on the part of > > a.jar that depends only on x.jar. In other words in reality statically > > (no reflection) my application does not really depend on y.jar and z.jar > > and only needs compact1 to execute properly. There are libraries that > > are "well focused" and have very few dependencies and there are those > > that pull ton of dependencies even though an application may only be > > using 5% of it. > > > > Would jdeps show only real or all dependencies in this case? If latter > > would it show enough information that can be analyzed to determine that > > y.jar and z.jar are not really needed and can be removed from my > deployment? > > > > $ jdeps -R -s -cp a.jar:b.jar:x.jar:y.jar:z.jar app.jar > > This will recursively analyze the run-time view of the dependencies from > app.jar. The -s option shows the summary and doesn?t list the > package-level dependencies. It will start with all types in app.jar and > then transitively analyze the referenced classes. > > y.jar and z.jar will not be shown in the output if no type from those jar > files are used at runtime. > > $ jdeps ?-compile-time -s -cp a.jar:b.jar:x.jar:y.jar:z.jar app.jar > > This will recursively analyze the compile-time view from app.jar. It will > start with app.jar and then recursively analyze the JAR files containing > its referenced types. In other words, it will show the dependenencies as > the example above. > > > Would Java 9 jdeps work differently in this case? > > jdeps -?compile-time option is a new option added in jdk9 jdeps. > > > Would jlink be able to > > figure the "real" dependencies and only pull really needed JRE modules > > into the output image? > > jlink will do the resolution per the specified root set and determine the > resulting modules to be linked in to the output image. The dependences are > declared in the module descriptors. You can refer the details in JEP 261 > [1] and JEP 282 [2] > > Mandy > [1] http://openjdk.java.net/jeps/261 > [2] http://openjdk.java.net/jeps/282 > > From jay.a at outlook.in Wed Sep 7 14:50:54 2016 From: jay.a at outlook.in (Jayaprakash Artanareeswaran) Date: Wed, 7 Sep 2016 14:50:54 +0000 Subject: Any word on the updated spec Message-ID: Hello experts, Now that JDK 9 is feature complete, I was wondering if the JSR 376 has been updated recently. Specifically, I am interested in many of the useful information found in the "State of the Module", such as module graph. Now I understand that the SOTM is an informal document, so I assume that this would naturally find a place in one of the formal documents. Please shed some light on this. As a tool provider, we (Eclipse team) are also hoping that formal specification on some other things such as "restricted keywords, JMOD would soon be available, if not already. Some information on these would also be highly appreciated. Regards, Jay P.S: I already sent this earlier but the mails get filtered out for unknown reasons, so sending from a different mail account. From sander.mak at luminis.eu Wed Sep 7 15:07:10 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Wed, 7 Sep 2016 15:07:10 +0000 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> Message-ID: > On 07 Sep 2016, at 16:12, Waldek Kozaczuk wrote: > > Will I be able to take advantage of jlink's ability to produce subset-only > image of the JRE even if I do not use new Java 9 modular jars? In other > words if my app.jar and other dependent jars are old java 8 ones and do not > have any module descriptors will jlink be able to identify only needed JRE > modules and produce minimal runtime image? Jlink will not be able to do that for you without module descriptors, but there's an alternative solution. First, use jdeps to find all the platform modules your application needs. Then create an image using jlink with an --add-modules argument for each of the identified platform modules. You can then run your existing application with all application/library JARs on the classpath on top of the resulting image. Sander From mark.reinhold at oracle.com Wed Sep 7 15:59:37 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 07 Sep 2016 08:59:37 -0700 Subject: Any word on the updated spec In-Reply-To: References: Message-ID: <20160907085937.222013789eggemoggin.niobe.net> 2016/9/7 7:50:54 -0700, Jayaprakash Artanareeswaran : > Now that JDK 9 is feature complete, I was wondering if > the JSR 376 has been updated recently. Specifically, I am interested in > many of the useful information found in the "State of the Module", such > as module graph. Now I understand that the SOTM is an informal document, > so I assume that this would naturally find a place in one of the formal > documents. Please shed some light on this. We're still working through quite a number of open issues so please stay tuned for updates, both formal and informal. - Mark From mandy.chung at oracle.com Wed Sep 7 21:03:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 14:03:27 -0700 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> Message-ID: > On Sep 7, 2016, at 8:07 AM, Sander Mak wrote: > > >> On 07 Sep 2016, at 16:12, Waldek Kozaczuk wrote: >> >> Will I be able to take advantage of jlink's ability to produce subset-only >> image of the JRE even if I do not use new Java 9 modular jars? In other >> words if my app.jar and other dependent jars are old java 8 ones and do not >> have any module descriptors will jlink be able to identify only needed JRE >> modules and produce minimal runtime image? > > Jlink will not be able to do that for you without module descriptors, but there's an alternative solution. First, use jdeps to find all the platform modules your application needs. Then create an image using jlink with an --add-modules argument for each of the identified platform modules. You can then run your existing application with all application/library JARs on the classpath on top of the resulting image. As Sander said, jlink creates custom image from packaged modules only. You can create a minimal runtime image and your application and other libraries can be put on the classpath. The open issue of adding link-time support for automatic modules is JDK-8139947 [1]. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8130047 From jwkozaczuk at gmail.com Wed Sep 7 22:34:23 2016 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Wed, 7 Sep 2016 18:34:23 -0400 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> Message-ID: Thanks for your responses. So today I did some experimentation with Java 8 jdeps to analyze how my app.jar depends at class level on other jars and eventually individual JRE classes. I would run following command: jdeps -v -P -R -cp lib/* app.jar # where lib/ contains jars that app.jar depends on to run and libs did not contain app.jar It turns our that jdeps would find and present dependent classes in all jars irregardless if any class in app.jar would directly or indirectly depend on it per "->" references. The good example of it was log4j jar where jdeps showed number of classes that depend directly or indirectly on some java.awt.* or javax.swing.* classes. And I am sure that this app does not requires AWT nor Swing to execute. Is it because jdeps finds individual class dependencies by detecting reflection calls in bytecode of log4j? Or maybe this "greedy" behavior of jdeps is intende and I would need to build a tool that would process its generated dependency graph starting from app.jar and that way find the real subset of JRE it depends on? I am still thinking that jdeps would not be able to show me classes that were called through java.lang.reflect.* constructs or Class.forName(). Do my findings make sense? On Wed, Sep 7, 2016 at 5:03 PM, Mandy Chung wrote: > > > On Sep 7, 2016, at 8:07 AM, Sander Mak wrote: > > > > > >> On 07 Sep 2016, at 16:12, Waldek Kozaczuk wrote: > >> > >> Will I be able to take advantage of jlink's ability to produce > subset-only > >> image of the JRE even if I do not use new Java 9 modular jars? In other > >> words if my app.jar and other dependent jars are old java 8 ones and do > not > >> have any module descriptors will jlink be able to identify only needed > JRE > >> modules and produce minimal runtime image? > > > > Jlink will not be able to do that for you without module descriptors, > but there's an alternative solution. First, use jdeps to find all the > platform modules your application needs. Then create an image using jlink > with an --add-modules argument for each of the identified > platform modules. You can then run your existing application with all > application/library JARs on the classpath on top of the resulting image. > > As Sander said, jlink creates custom image from packaged modules only. You > can create a minimal runtime image and your application and other libraries > can be put on the classpath. > > The open issue of adding link-time support for automatic modules is > JDK-8139947 [1]. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8130047 > > > From jwkozaczuk at gmail.com Wed Sep 7 22:42:05 2016 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Wed, 7 Sep 2016 18:42:05 -0400 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> Message-ID: <95F0307F-EC7E-45AA-AF7A-1D7DF15AB201@gmail.com> My real question I am in pursuit of answering is this: is it in theory possible to build an automated process that would use jdeps to analyze my app to build a minimal JRE image it would run on? The latter could be done by rewriting rt.jar in Java 8 and using jlink in Java 9. Sent from my iPhone > On Sep 7, 2016, at 18:34, Waldek Kozaczuk wrote: > > Thanks for your responses. > > So today I did some experimentation with Java 8 jdeps to analyze how my app.jar depends at class level on other jars and eventually individual JRE classes. I would run following command: > > jdeps -v -P -R -cp lib/* app.jar # where lib/ contains jars that app.jar depends on to run and libs did not contain app.jar > > It turns our that jdeps would find and present dependent classes in all jars irregardless if any class in app.jar would directly or indirectly depend on it per "->" references. > > The good example of it was log4j jar where jdeps showed number of classes that depend directly or indirectly on some java.awt.* or javax.swing.* classes. And I am sure that this app does not requires AWT nor Swing to execute. Is it because jdeps finds individual class dependencies by detecting reflection calls in bytecode of log4j? > > Or maybe this "greedy" behavior of jdeps is intende and I would need to build a tool that would process its generated dependency graph starting from app.jar and that way find the real subset of JRE it depends on? I am still thinking that jdeps would not be able to show me classes that were called through java.lang.reflect.* constructs or Class.forName(). > > Do my findings make sense? > >> On Wed, Sep 7, 2016 at 5:03 PM, Mandy Chung wrote: >> >> > On Sep 7, 2016, at 8:07 AM, Sander Mak wrote: >> > >> > >> >> On 07 Sep 2016, at 16:12, Waldek Kozaczuk wrote: >> >> >> >> Will I be able to take advantage of jlink's ability to produce subset-only >> >> image of the JRE even if I do not use new Java 9 modular jars? In other >> >> words if my app.jar and other dependent jars are old java 8 ones and do not >> >> have any module descriptors will jlink be able to identify only needed JRE >> >> modules and produce minimal runtime image? >> > >> > Jlink will not be able to do that for you without module descriptors, but there's an alternative solution. First, use jdeps to find all the platform modules your application needs. Then create an image using jlink with an --add-modules argument for each of the identified platform modules. You can then run your existing application with all application/library JARs on the classpath on top of the resulting image. >> >> As Sander said, jlink creates custom image from packaged modules only. You can create a minimal runtime image and your application and other libraries can be put on the classpath. >> >> The open issue of adding link-time support for automatic modules is JDK-8139947 [1]. >> >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8130047 > From mandy.chung at oracle.com Thu Sep 8 01:58:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 18:58:02 -0700 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: <95F0307F-EC7E-45AA-AF7A-1D7DF15AB201@gmail.com> References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> <95F0307F-EC7E-45AA-AF7A-1D7DF15AB201@gmail.com> Message-ID: jdeps is only doing static analysis and doesn?t inspect reflection usage. It?s possible to build such an automated process but not reliable. Convert the app to modules with explict dependences will ensure reliable configuraton. AFAIK javapackager has a RFE to provide this functionality (analyze the static dependences and package the app with a minimal image) while this does not detect any reflective dependences. Mandy P.S. please try jdk9 jdeps and see if you get the same behavior. > On Sep 7, 2016, at 3:42 PM, Waldek Kozaczuk wrote: > > My real question I am in pursuit of answering is this: is it in theory possible to build an automated process that would use jdeps to analyze my app to build a minimal JRE image it would run on? The latter could be done by rewriting rt.jar in Java 8 and using jlink in Java 9. > > Sent from my iPhone > > On Sep 7, 2016, at 18:34, Waldek Kozaczuk wrote: > >> Thanks for your responses. >> >> So today I did some experimentation with Java 8 jdeps to analyze how my app.jar depends at class level on other jars and eventually individual JRE classes. I would run following command: >> >> jdeps -v -P -R -cp lib/* app.jar # where lib/ contains jars that app.jar depends on to run and libs did not contain app.jar >> >> It turns our that jdeps would find and present dependent classes in all jars irregardless if any class in app.jar would directly or indirectly depend on it per "->" references. >> >> The good example of it was log4j jar where jdeps showed number of classes that depend directly or indirectly on some java.awt.* or javax.swing.* classes. And I am sure that this app does not requires AWT nor Swing to execute. Is it because jdeps finds individual class dependencies by detecting reflection calls in bytecode of log4j? >> >> Or maybe this "greedy" behavior of jdeps is intende and I would need to build a tool that would process its generated dependency graph starting from app.jar and that way find the real subset of JRE it depends on? I am still thinking that jdeps would not be able to show me classes that were called through java.lang.reflect.* constructs or Class.forName(). >> >> Do my findings make sense? >> >> On Wed, Sep 7, 2016 at 5:03 PM, Mandy Chung wrote: >> >> > On Sep 7, 2016, at 8:07 AM, Sander Mak wrote: >> > >> > >> >> On 07 Sep 2016, at 16:12, Waldek Kozaczuk wrote: >> >> >> >> Will I be able to take advantage of jlink's ability to produce subset-only >> >> image of the JRE even if I do not use new Java 9 modular jars? In other >> >> words if my app.jar and other dependent jars are old java 8 ones and do not >> >> have any module descriptors will jlink be able to identify only needed JRE >> >> modules and produce minimal runtime image? >> > >> > Jlink will not be able to do that for you without module descriptors, but there's an alternative solution. First, use jdeps to find all the platform modules your application needs. Then create an image using jlink with an --add-modules argument for each of the identified platform modules. You can then run your existing application with all application/library JARs on the classpath on top of the resulting image. >> >> As Sander said, jlink creates custom image from packaged modules only. You can create a minimal runtime image and your application and other libraries can be put on the classpath. >> >> The open issue of adding link-time support for automatic modules is JDK-8139947 [1]. >> >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8130047 >> >> >> From dalibor.topic at oracle.com Thu Sep 8 10:29:10 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 8 Sep 2016 12:29:10 +0200 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: <95F0307F-EC7E-45AA-AF7A-1D7DF15AB201@gmail.com> References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> <95F0307F-EC7E-45AA-AF7A-1D7DF15AB201@gmail.com> Message-ID: <0fe2f17d-23f7-9b3a-2b1c-402438f8c025@oracle.com> As Mandy said, jdeps can't do that. There are other tools that perform bytecode engineering, optimization and shrinking that could assist you in determining a useful subset of all your application's classes to feed into jdeps for further analysis. cheers, dalibor topic On 08.09.2016 00:42, Waldek Kozaczuk wrote: > My real question I am in pursuit of answering is this: is it in theory possible to build an automated process that would use jdeps to analyze my app to build a minimal JRE image it would run on? The latter could be done by rewriting rt.jar in Java 8 and using jlink in Java 9. > > Sent from my iPhone > >> On Sep 7, 2016, at 18:34, Waldek Kozaczuk wrote: >> >> Thanks for your responses. >> >> So today I did some experimentation with Java 8 jdeps to analyze how my app.jar depends at class level on other jars and eventually individual JRE classes. I would run following command: >> >> jdeps -v -P -R -cp lib/* app.jar # where lib/ contains jars that app.jar depends on to run and libs did not contain app.jar >> >> It turns our that jdeps would find and present dependent classes in all jars irregardless if any class in app.jar would directly or indirectly depend on it per "->" references. >> >> The good example of it was log4j jar where jdeps showed number of classes that depend directly or indirectly on some java.awt.* or javax.swing.* classes. And I am sure that this app does not requires AWT nor Swing to execute. Is it because jdeps finds individual class dependencies by detecting reflection calls in bytecode of log4j? >> >> Or maybe this "greedy" behavior of jdeps is intende and I would need to build a tool that would process its generated dependency graph starting from app.jar and that way find the real subset of JRE it depends on? I am still thinking that jdeps would not be able to show me classes that were called through java.lang.reflect.* constructs or Class.forName(). >> >> Do my findings make sense? >> >>> On Wed, Sep 7, 2016 at 5:03 PM, Mandy Chung wrote: >>> >>>> On Sep 7, 2016, at 8:07 AM, Sander Mak wrote: >>>> >>>> >>>>> On 07 Sep 2016, at 16:12, Waldek Kozaczuk wrote: >>>>> >>>>> Will I be able to take advantage of jlink's ability to produce subset-only >>>>> image of the JRE even if I do not use new Java 9 modular jars? In other >>>>> words if my app.jar and other dependent jars are old java 8 ones and do not >>>>> have any module descriptors will jlink be able to identify only needed JRE >>>>> modules and produce minimal runtime image? >>>> >>>> Jlink will not be able to do that for you without module descriptors, but there's an alternative solution. First, use jdeps to find all the platform modules your application needs. Then create an image using jlink with an --add-modules argument for each of the identified platform modules. You can then run your existing application with all application/library JARs on the classpath on top of the resulting image. >>> >>> As Sander said, jlink creates custom image from packaged modules only. You can create a minimal runtime image and your application and other libraries can be put on the classpath. >>> >>> The open issue of adding link-time support for automatic modules is JDK-8139947 [1]. >>> >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8130047 >> -- 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 From Alan.Bateman at oracle.com Thu Sep 8 10:50:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 11:50:02 +0100 Subject: Upgradeable Modules Question In-Reply-To: <5f5f5095-6c9e-56a8-d079-2c807481a557@redhat.com> References: <51667b7b-28d9-cec5-2416-4c59433215b0@redhat.com> <57CF4543.3070402@oracle.com> <568db33a-66f6-f491-ffa8-7df1bbef4d50@oracle.com> <5f5f5095-6c9e-56a8-d079-2c807481a557@redhat.com> Message-ID: On 07/09/2016 13:43, Richard Opalka wrote: > >> but I'm guessing you might have artifacts like >> jaxb-api-.jar, in which case the derived module name isn't >> useful. > I used exploded directory named java.xml.bind (of course without > module-info.class). I'm not sure that I understand this as it won't be treated as an automatic module in that case. -Alan From sander.mak at luminis.eu Thu Sep 8 11:15:50 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Thu, 8 Sep 2016 11:15:50 +0000 Subject: Can jdeps resolve unnecessary dependencies? In-Reply-To: References: <2697A662-24A2-471A-98AC-FB9FED17D129@oracle.com> Message-ID: <10D74F39-81B3-43CE-B936-20DF5FB06FC5@luminis.eu> Hi Waldek, I feel the other responses focus too much on your side-remark on reflection. What you're seeing here with jdeps is not unexpected behavior, I believe. For example, log4j *does* reference awt code [0], even though you might not expect it. Same holds true for swing classes [1]. It's just when you run it on a full JDK, you're not aware of this dependency! Hurray for modularity, making it clear that you need awt to use log4j... (and therefore, transitively your app.jar if it uses log4j classes). Now this ColorRule [0] class may never be loaded in any of your usage scenarios, but that doesn't mean the dependency is not there. Hope this helps, Sander [0] https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/rule/ColorRule.java#L20 [1] https://github.com/apache/log4j/search?utf8=?&q=swing On 08 Sep 2016, at 00:34, Waldek Kozaczuk > wrote: Thanks for your responses. So today I did some experimentation with Java 8 jdeps to analyze how my app.jar depends at class level on other jars and eventually individual JRE classes. I would run following command: jdeps -v -P -R -cp lib/* app.jar # where lib/ contains jars that app.jar depends on to run and libs did not contain app.jar It turns our that jdeps would find and present dependent classes in all jars irregardless if any class in app.jar would directly or indirectly depend on it per "->" references. The good example of it was log4j jar where jdeps showed number of classes that depend directly or indirectly on some java.awt.* or javax.swing.* classes. And I am sure that this app does not requires AWT nor Swing to execute. Is it because jdeps finds individual class dependencies by detecting reflection calls in bytecode of log4j? Or maybe this "greedy" behavior of jdeps is intende and I would need to build a tool that would process its generated dependency graph starting from app.jar and that way find the real subset of JRE it depends on? I am still thinking that jdeps would not be able to show me classes that were called through java.lang.reflect.* constructs or Class.forName(). Do my findings make sense? On Wed, Sep 7, 2016 at 5:03 PM, Mandy Chung > wrote: On Sep 7, 2016, at 8:07 AM, Sander Mak > wrote: On 07 Sep 2016, at 16:12, Waldek Kozaczuk > wrote: Will I be able to take advantage of jlink's ability to produce subset-only image of the JRE even if I do not use new Java 9 modular jars? In other words if my app.jar and other dependent jars are old java 8 ones and do not have any module descriptors will jlink be able to identify only needed JRE modules and produce minimal runtime image? Jlink will not be able to do that for you without module descriptors, but there's an alternative solution. First, use jdeps to find all the platform modules your application needs. Then create an image using jlink with an --add-modules argument for each of the identified platform modules. You can then run your existing application with all application/library JARs on the classpath on top of the resulting image. As Sander said, jlink creates custom image from packaged modules only. You can create a minimal runtime image and your application and other libraries can be put on the classpath. The open issue of adding link-time support for automatic modules is JDK-8139947 [1]. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8130047 From jwkozaczuk at gmail.com Thu Sep 8 13:11:16 2016 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Thu, 8 Sep 2016 09:11:16 -0400 Subject: Possibility to create modular jars out of old non-modular ones Message-ID: Imagine you have pre-jigsaw jar like log4j 1.x that happens to depend on java.awt.* and swing (it does in fact) but I know for a fact my app does not use this part of it. Would it be possible to create a modular jar out of non-modular by simply repackaging it and adding module-info.java that specifies what specifically my app depends on (is exposed in log4j jar) and what that log4j in my case "requires" from Java 9 in terms of modules? If possible then jlink could rely on this information and build according minimal image. From sundararajan.athijegannathan at oracle.com Thu Sep 8 14:32:15 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 8 Sep 2016 20:02:15 +0530 Subject: RFR 8165697: jlink running on Mac with Windows jmods produces non-runnable image Message-ID: Please review http://cr.openjdk.java.net/~sundar/8165697/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165697 Thanks -Sundar From claes.redestad at oracle.com Thu Sep 8 14:39:24 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 8 Sep 2016 16:39:24 +0200 Subject: RFR 8165697: jlink running on Mac with Windows jmods produces non-runnable image In-Reply-To: References: Message-ID: <57D1781C.3000309@oracle.com> Looks good. /Claes On 2016-09-08 16:32, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8165697/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8165697 > > Thanks > > -Sundar > From james.laskey at oracle.com Thu Sep 8 14:40:05 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 8 Sep 2016 11:40:05 -0300 Subject: RFR 8165697: jlink running on Mac with Windows jmods produces non-runnable image In-Reply-To: References: Message-ID: <6F71994A-0FEF-4A5B-BAF5-ABDCBD18CA2A@oracle.com> +1 > On Sep 8, 2016, at 11:32 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8165697/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8165697 > > Thanks > > -Sundar > From alex.buckley at oracle.com Thu Sep 8 18:55:11 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 08 Sep 2016 11:55:11 -0700 Subject: Possibility to create modular jars out of old non-modular ones In-Reply-To: References: Message-ID: <57D1B40F.9090605@oracle.com> On 9/8/2016 6:11 AM, Waldek Kozaczuk wrote: > Imagine you have pre-jigsaw jar like log4j 1.x that happens to depend on > java.awt.* and swing (it does in fact) but I know for a fact my app does > not use this part of it. > > Would it be possible to create a modular jar out of non-modular by simply > repackaging it and adding module-info.java that specifies what specifically > my app depends on (is exposed in log4j jar) Yes. By all means, add module-info.class to your app JAR. The following thread from August will be helpful if you want to compile just module-info.java for JDK 9: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009177.html > and what that log4j in my case "requires" from Java 9 in terms of > modules? The module-info.class file in your app JAR is the declaration of your application module. It can't contain dependencies for some other module. If you want your application module to say 'requires log4j', then your choices are to put log4j on the modulepath as an automatic module, or to find a version of log4j that is already a modular JAR. Alex From rfscholte at apache.org Thu Sep 8 20:15:50 2016 From: rfscholte at apache.org (Robert Scholte) Date: Thu, 08 Sep 2016 22:15:50 +0200 Subject: [MRJAR] Entry order matters? In-Reply-To: <823816d2-3b34-5a2a-76d8-84f6123d276c@oracle.com> References: <223e2860-386f-fa40-7621-a01352130a68@oracle.com> <823816d2-3b34-5a2a-76d8-84f6123d276c@oracle.com> Message-ID: Confirmed there's an issue; jar should have been recognized as a multirelease jar. https://bugs.openjdk.java.net/browse/JDK-8165723 thanks, Robert On Mon, 05 Sep 2016 09:10:56 +0200, Alan Bateman wrote: > > > On 04/09/2016 21:56, Robert Scholte wrote: >> : >> >>> Also if you "unzip -d " then does everything look okay? >>> >> >> hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_failure.jar | grep >> class >> hboutemy testing: base/Base.class OK >> hboutemy testing: META-INF/versions/9/mr/A.class OK >> hboutemy testing: META-INF/versions/8/mr/A.class OK >> hboutemy testing: mr/A.class OK >> hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_success.jar | grep >> class >> hboutemy testing: base/Base.class OK >> hboutemy testing: META-INF/versions/8/mr/A.class OK >> hboutemy testing: mr/A.class OK >> hboutemy testing: META-INF/versions/9/mr/A.class OK >> >> Looks good to me. > I think I need to see multirelease-0.8-SNAPSHOT_failure.jar to > understand this as I suspect there is more going on that is obvious > here. I'll see if I can duplicate it. > > -Alan From david.lloyd at redhat.com Thu Sep 8 22:29:36 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 8 Sep 2016 17:29:36 -0500 Subject: Using non-parallel custom class loaders for Layer configurations Message-ID: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> Is it not necessary that any class loader in use by a Layer must be parallel-capable? Otherwise it seems like deadlocks could occur in certain situations when there are references that are cyclic with respect to class loaders mapped by the mapping function. On that note, there is in fact no good way for user code to determine whether or not a class loader is indeed parallel-capable, which is often a critical question in module systems, especially when users can provide specialized class loader implementations. Right now you can only do something (awful) like this (e.g. in your base ClassLoader constructor): if (getClassLoadingLock("$TEST$") == this) { throw new Error("Cannot instantiate non-parallel subclass"); } Would it be possible to include a method like this (pretty old patch I had laying around): diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java index 1bb1580..3def10e 100644 --- a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java +++ b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java @@ -469,6 +477,15 @@ public abstract class ClassLoader { return lock; } + /** + * Determine whether this class loader is parallel-capable. + * + * @return {@code true} if the class loader is parallel-capable, {@code false} otherwise + */ + protected final boolean isParallelCapable() { + return ParallelLoaders.isRegistered(getClass()); + } + // This method is invoked by the virtual machine to load a class. private Class loadClassInternal(String name) throws ClassNotFoundException Alternatively, the method could be made static and protected, only returning true if the calling class is a class loader that is parallel capable, something like this (against a newer branch): diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java index 0139123..06a5909 100644 --- a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java +++ b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java @@ -1421,6 +1421,19 @@ public abstract class ClassLoader { } /** + * Determine whether the calling class is a parallel-capable class loader. + * + * @return true if the caller is a parallel-capable class loader and false otherwise + * + * @since 9 + */ + @CallerSensitive + protected static boolean isParallelCapable() { + final Class callerClass = Reflection.getCallerClass(); + return ClassLoader.class.isAssignableFrom(callerClass) && ParallelLoaders.isRegistered(callerClass.asSubclass(ClassLoader.class)); + } + + /** * Find a resource of the specified name from the search path used to load * classes. This method locates the resource through the system class * loader (see {@link #getSystemClassLoader()}). WDYT? -- - DML From mandy.chung at oracle.com Thu Sep 8 23:48:12 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Sep 2016 16:48:12 -0700 Subject: Using non-parallel custom class loaders for Layer configurations In-Reply-To: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> References: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> Message-ID: <789BC05B-7D50-40F7-9E79-270AA8881B32@oracle.com> > On Sep 8, 2016, at 3:29 PM, David M. Lloyd wrote: > > Would it be possible to include a method like this (pretty old patch I had laying around): > > diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java > index 1bb1580..3def10e 100644 > --- a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java > +++ b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java > @@ -469,6 +477,15 @@ public abstract class ClassLoader { > return lock; > } > > + /** > + * Determine whether this class loader is parallel-capable. > + * > + * @return {@code true} if the class loader is parallel-capable, {@code false} otherwise > + */ > + protected final boolean isParallelCapable() { > + return ParallelLoaders.isRegistered(getClass()); > + } > + This seems a fine method to add. I think it can be a public method (I don?t see any reason it has to be protected) Mandy From mandy.chung at oracle.com Fri Sep 9 00:44:23 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:44:23 +0000 Subject: hg: jigsaw/jake: 13 new changesets Message-ID: <201609090044.u890iNWr000924@aojmv0008.oracle.com> Changeset: f60c6d0cc585 Author: mchung Date: 2016-08-30 17:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f60c6d0cc585 8160851: Remove old launcher module-related options Reviewed-by: jjg, alanb ! make/CompileJavaModules.gmk ! make/common/SetupJavaCompilers.gmk Changeset: b6f21e99011e Author: redestad Date: 2016-08-31 14:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b6f21e99011e 8164858: Enable build-time use of java.lang.invoke resolve tracing Reviewed-by: erikj, vlivanov ! make/Images.gmk Changeset: dcce309ab6a6 Author: erikj Date: 2016-08-19 16:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/dcce309ab6a6 8164297: Jtreg test exeinvoke fails to link on Ubuntu Reviewed-by: tbell, dholmes ! make/common/TestFilesCompilation.gmk Changeset: 2a8815d86b93 Author: ctornqvi Date: 2016-08-19 10:09 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2a8815d86b93 8157957: ClassNotFoundException: jdk.test.lib.JDKToolFinder Reviewed-by: coleenp, gtriantafill, mseledtsov, iignatyev, dholmes, dsamersoff ! make/test/BuildTestLib.gmk + test/lib/ClassFileInstaller.java + test/lib/RedefineClassHelper.java + test/lib/jdk/test/lib/Asserts.java + test/lib/jdk/test/lib/BuildHelper.java + test/lib/jdk/test/lib/ByteCodeLoader.java + test/lib/jdk/test/lib/DynamicVMOption.java + test/lib/jdk/test/lib/FileInstaller.java + test/lib/jdk/test/lib/InMemoryJavaCompiler.java + test/lib/jdk/test/lib/JDKToolFinder.java + test/lib/jdk/test/lib/JDKToolLauncher.java + test/lib/jdk/test/lib/Platform.java + test/lib/jdk/test/lib/Utils.java + test/lib/jdk/test/lib/apps/LingeredApp.java + test/lib/jdk/test/lib/apps/LingeredAppWithDeadlock.java + test/lib/jdk/test/lib/cli/CPUSpecificCommandLineOptionTest.java + test/lib/jdk/test/lib/cli/CommandLineOptionTest.java + test/lib/jdk/test/lib/cli/predicate/AndPredicate.java + test/lib/jdk/test/lib/cli/predicate/CPUSpecificPredicate.java + test/lib/jdk/test/lib/cli/predicate/NotPredicate.java + test/lib/jdk/test/lib/cli/predicate/OrPredicate.java + test/lib/jdk/test/lib/dcmd/CommandExecutor.java + test/lib/jdk/test/lib/dcmd/CommandExecutorException.java + test/lib/jdk/test/lib/dcmd/FileJcmdExecutor.java + test/lib/jdk/test/lib/dcmd/JMXExecutor.java + test/lib/jdk/test/lib/dcmd/JcmdExecutor.java + test/lib/jdk/test/lib/dcmd/MainClassJcmdExecutor.java + test/lib/jdk/test/lib/dcmd/PidJcmdExecutor.java + test/lib/jdk/test/lib/hprof/HprofParser.java + test/lib/jdk/test/lib/hprof/README + test/lib/jdk/test/lib/hprof/model/AbstractJavaHeapObjectVisitor.java + test/lib/jdk/test/lib/hprof/model/ArrayTypeCodes.java + test/lib/jdk/test/lib/hprof/model/HackJavaValue.java + test/lib/jdk/test/lib/hprof/model/JavaBoolean.java + test/lib/jdk/test/lib/hprof/model/JavaByte.java + test/lib/jdk/test/lib/hprof/model/JavaChar.java + test/lib/jdk/test/lib/hprof/model/JavaClass.java + test/lib/jdk/test/lib/hprof/model/JavaDouble.java + test/lib/jdk/test/lib/hprof/model/JavaField.java + test/lib/jdk/test/lib/hprof/model/JavaFloat.java + test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java + test/lib/jdk/test/lib/hprof/model/JavaHeapObjectVisitor.java + test/lib/jdk/test/lib/hprof/model/JavaInt.java + test/lib/jdk/test/lib/hprof/model/JavaLazyReadObject.java + test/lib/jdk/test/lib/hprof/model/JavaLong.java + test/lib/jdk/test/lib/hprof/model/JavaObject.java + test/lib/jdk/test/lib/hprof/model/JavaObjectArray.java + test/lib/jdk/test/lib/hprof/model/JavaObjectRef.java + test/lib/jdk/test/lib/hprof/model/JavaShort.java + test/lib/jdk/test/lib/hprof/model/JavaStatic.java + test/lib/jdk/test/lib/hprof/model/JavaThing.java + test/lib/jdk/test/lib/hprof/model/JavaValue.java + test/lib/jdk/test/lib/hprof/model/JavaValueArray.java + test/lib/jdk/test/lib/hprof/model/ReachableExcludes.java + test/lib/jdk/test/lib/hprof/model/ReachableExcludesImpl.java + test/lib/jdk/test/lib/hprof/model/ReachableObjects.java + test/lib/jdk/test/lib/hprof/model/ReferenceChain.java + test/lib/jdk/test/lib/hprof/model/Root.java + test/lib/jdk/test/lib/hprof/model/Snapshot.java + test/lib/jdk/test/lib/hprof/model/StackFrame.java + test/lib/jdk/test/lib/hprof/model/StackTrace.java + test/lib/jdk/test/lib/hprof/parser/FileReadBuffer.java + test/lib/jdk/test/lib/hprof/parser/HprofReader.java + test/lib/jdk/test/lib/hprof/parser/MappedReadBuffer.java + test/lib/jdk/test/lib/hprof/parser/PositionDataInputStream.java + test/lib/jdk/test/lib/hprof/parser/PositionInputStream.java + test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java + test/lib/jdk/test/lib/hprof/parser/Reader.java + test/lib/jdk/test/lib/hprof/util/ArraySorter.java + test/lib/jdk/test/lib/hprof/util/Comparer.java + test/lib/jdk/test/lib/hprof/util/CompositeEnumeration.java + test/lib/jdk/test/lib/hprof/util/Misc.java + test/lib/jdk/test/lib/hprof/util/VectorSorter.java + test/lib/jdk/test/lib/process/ExitCode.java + test/lib/jdk/test/lib/process/OutputAnalyzer.java + test/lib/jdk/test/lib/process/OutputBuffer.java + test/lib/jdk/test/lib/process/ProcessTools.java + test/lib/jdk/test/lib/process/StreamPumper.java + test/lib/jdk/test/lib/util/Pair.java + test/lib/jdk/test/lib/util/Triple.java + test/lib/jdk/test/lib/wrappers/InfiniteLoop.java + test/lib/jdk/test/lib/wrappers/TimeLimitedRunner.java - test/lib/share/classes/jdk/test/lib/Asserts.java - test/lib/share/classes/jdk/test/lib/JDKToolFinder.java - test/lib/share/classes/jdk/test/lib/JDKToolLauncher.java - test/lib/share/classes/jdk/test/lib/Platform.java - test/lib/share/classes/jdk/test/lib/Utils.java - test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java - test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java - test/lib/share/classes/jdk/test/lib/hprof/HprofParser.java - test/lib/share/classes/jdk/test/lib/hprof/README - test/lib/share/classes/jdk/test/lib/hprof/model/AbstractJavaHeapObjectVisitor.java - test/lib/share/classes/jdk/test/lib/hprof/model/ArrayTypeCodes.java - test/lib/share/classes/jdk/test/lib/hprof/model/HackJavaValue.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaBoolean.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaByte.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaChar.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaClass.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaDouble.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaField.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaFloat.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaHeapObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaHeapObjectVisitor.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaInt.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaLazyReadObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaLong.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObjectArray.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObjectRef.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaShort.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaStatic.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaThing.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaValue.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaValueArray.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableExcludes.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableExcludesImpl.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableObjects.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReferenceChain.java - test/lib/share/classes/jdk/test/lib/hprof/model/Root.java - test/lib/share/classes/jdk/test/lib/hprof/model/Snapshot.java - test/lib/share/classes/jdk/test/lib/hprof/model/StackFrame.java - test/lib/share/classes/jdk/test/lib/hprof/model/StackTrace.java - test/lib/share/classes/jdk/test/lib/hprof/parser/FileReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/HprofReader.java - test/lib/share/classes/jdk/test/lib/hprof/parser/MappedReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/PositionDataInputStream.java - test/lib/share/classes/jdk/test/lib/hprof/parser/PositionInputStream.java - test/lib/share/classes/jdk/test/lib/hprof/parser/ReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/Reader.java - test/lib/share/classes/jdk/test/lib/hprof/util/ArraySorter.java - test/lib/share/classes/jdk/test/lib/hprof/util/Comparer.java - test/lib/share/classes/jdk/test/lib/hprof/util/CompositeEnumeration.java - test/lib/share/classes/jdk/test/lib/hprof/util/Misc.java - test/lib/share/classes/jdk/test/lib/hprof/util/VectorSorter.java - test/lib/share/classes/jdk/test/lib/process/OutputAnalyzer.java - test/lib/share/classes/jdk/test/lib/process/OutputBuffer.java - test/lib/share/classes/jdk/test/lib/process/ProcessTools.java - test/lib/share/classes/jdk/test/lib/process/StreamPumper.java Changeset: c78d2aaf2119 Author: ctornqvi Date: 2016-08-19 18:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c78d2aaf2119 Merge Changeset: 3f84cc5e4f12 Author: amurillo Date: 2016-08-19 12:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3f84cc5e4f12 Merge Changeset: e3690ab59881 Author: amurillo Date: 2016-08-26 10:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e3690ab59881 Merge - test/lib/share/classes/jdk/test/lib/Asserts.java - test/lib/share/classes/jdk/test/lib/JDKToolFinder.java - test/lib/share/classes/jdk/test/lib/JDKToolLauncher.java - test/lib/share/classes/jdk/test/lib/Platform.java - test/lib/share/classes/jdk/test/lib/Utils.java - test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java - test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java - test/lib/share/classes/jdk/test/lib/hprof/HprofParser.java - test/lib/share/classes/jdk/test/lib/hprof/README - test/lib/share/classes/jdk/test/lib/hprof/model/AbstractJavaHeapObjectVisitor.java - test/lib/share/classes/jdk/test/lib/hprof/model/ArrayTypeCodes.java - test/lib/share/classes/jdk/test/lib/hprof/model/HackJavaValue.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaBoolean.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaByte.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaChar.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaClass.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaDouble.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaField.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaFloat.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaHeapObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaHeapObjectVisitor.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaInt.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaLazyReadObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaLong.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObjectArray.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObjectRef.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaShort.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaStatic.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaThing.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaValue.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaValueArray.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableExcludes.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableExcludesImpl.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableObjects.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReferenceChain.java - test/lib/share/classes/jdk/test/lib/hprof/model/Root.java - test/lib/share/classes/jdk/test/lib/hprof/model/Snapshot.java - test/lib/share/classes/jdk/test/lib/hprof/model/StackFrame.java - test/lib/share/classes/jdk/test/lib/hprof/model/StackTrace.java - test/lib/share/classes/jdk/test/lib/hprof/parser/FileReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/HprofReader.java - test/lib/share/classes/jdk/test/lib/hprof/parser/MappedReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/PositionDataInputStream.java - test/lib/share/classes/jdk/test/lib/hprof/parser/PositionInputStream.java - test/lib/share/classes/jdk/test/lib/hprof/parser/ReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/Reader.java - test/lib/share/classes/jdk/test/lib/hprof/util/ArraySorter.java - test/lib/share/classes/jdk/test/lib/hprof/util/Comparer.java - test/lib/share/classes/jdk/test/lib/hprof/util/CompositeEnumeration.java - test/lib/share/classes/jdk/test/lib/hprof/util/Misc.java - test/lib/share/classes/jdk/test/lib/hprof/util/VectorSorter.java - test/lib/share/classes/jdk/test/lib/process/OutputAnalyzer.java - test/lib/share/classes/jdk/test/lib/process/OutputBuffer.java - test/lib/share/classes/jdk/test/lib/process/ProcessTools.java - test/lib/share/classes/jdk/test/lib/process/StreamPumper.java Changeset: f497fafdc02e Author: amurillo Date: 2016-08-31 09:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f497fafdc02e Merge Changeset: e7038398e5a9 Author: erikj Date: 2016-09-01 10:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e7038398e5a9 8165158: Fix zero builds for non-listed architectures Reviewed-by: tbell Contributed-by: doko at ubuntu.com ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: 6d01bcd91f8a Author: lana Date: 2016-09-02 02:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6d01bcd91f8a Merge - test/lib/share/classes/jdk/test/lib/Asserts.java - test/lib/share/classes/jdk/test/lib/JDKToolFinder.java - test/lib/share/classes/jdk/test/lib/JDKToolLauncher.java - test/lib/share/classes/jdk/test/lib/Platform.java - test/lib/share/classes/jdk/test/lib/Utils.java - test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java - test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java - test/lib/share/classes/jdk/test/lib/hprof/HprofParser.java - test/lib/share/classes/jdk/test/lib/hprof/README - test/lib/share/classes/jdk/test/lib/hprof/model/AbstractJavaHeapObjectVisitor.java - test/lib/share/classes/jdk/test/lib/hprof/model/ArrayTypeCodes.java - test/lib/share/classes/jdk/test/lib/hprof/model/HackJavaValue.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaBoolean.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaByte.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaChar.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaClass.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaDouble.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaField.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaFloat.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaHeapObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaHeapObjectVisitor.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaInt.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaLazyReadObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaLong.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObject.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObjectArray.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaObjectRef.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaShort.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaStatic.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaThing.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaValue.java - test/lib/share/classes/jdk/test/lib/hprof/model/JavaValueArray.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableExcludes.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableExcludesImpl.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReachableObjects.java - test/lib/share/classes/jdk/test/lib/hprof/model/ReferenceChain.java - test/lib/share/classes/jdk/test/lib/hprof/model/Root.java - test/lib/share/classes/jdk/test/lib/hprof/model/Snapshot.java - test/lib/share/classes/jdk/test/lib/hprof/model/StackFrame.java - test/lib/share/classes/jdk/test/lib/hprof/model/StackTrace.java - test/lib/share/classes/jdk/test/lib/hprof/parser/FileReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/HprofReader.java - test/lib/share/classes/jdk/test/lib/hprof/parser/MappedReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/PositionDataInputStream.java - test/lib/share/classes/jdk/test/lib/hprof/parser/PositionInputStream.java - test/lib/share/classes/jdk/test/lib/hprof/parser/ReadBuffer.java - test/lib/share/classes/jdk/test/lib/hprof/parser/Reader.java - test/lib/share/classes/jdk/test/lib/hprof/util/ArraySorter.java - test/lib/share/classes/jdk/test/lib/hprof/util/Comparer.java - test/lib/share/classes/jdk/test/lib/hprof/util/CompositeEnumeration.java - test/lib/share/classes/jdk/test/lib/hprof/util/Misc.java - test/lib/share/classes/jdk/test/lib/hprof/util/VectorSorter.java - test/lib/share/classes/jdk/test/lib/process/OutputAnalyzer.java - test/lib/share/classes/jdk/test/lib/process/OutputBuffer.java - test/lib/share/classes/jdk/test/lib/process/ProcessTools.java - test/lib/share/classes/jdk/test/lib/process/StreamPumper.java Changeset: 82b94cb5f342 Author: erikj Date: 2016-09-05 10:10 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/82b94cb5f342 8165314: Javac server process left running if build fails on Windows Reviewed-by: tbell, wetmore ! make/Init.gmk Changeset: 0b50a0d179fd Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0b50a0d179fd Added tag jdk-9+135 for changeset 82b94cb5f342 ! .hgtags Changeset: 774d24a28d52 Author: mchung Date: 2016-09-08 17:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/774d24a28d52 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/common/SetupJavaCompilers.gmk From mandy.chung at oracle.com Fri Sep 9 00:44:32 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:44:32 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201609090044.u890iWrf001059@aojmv0008.oracle.com> Changeset: aa053a3faf26 Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/aa053a3faf26 Added tag jdk-9+135 for changeset 094d0db606db ! .hgtags Changeset: d9b3cf2dd4d2 Author: mchung Date: 2016-09-08 17:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/d9b3cf2dd4d2 Merge From mandy.chung at oracle.com Fri Sep 9 00:44:54 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:44:54 +0000 Subject: hg: jigsaw/jake/hotspot: 52 new changesets Message-ID: <201609090044.u890itBq001170@aojmv0008.oracle.com> Changeset: 65a32a1c9bf9 Author: mchung Date: 2016-08-30 17:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/65a32a1c9bf9 8160851: Remove old launcher module-related options Reviewed-by: alanb ! test/runtime/Unsafe/NestedUnsafe.java Changeset: e3a19a55f062 Author: dsamersoff Date: 2016-08-18 12:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3a19a55f062 8151345: compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot Reviewed-by: sla, dsamersoff ! test/compiler/codecache/jmx/CodeCacheUtils.java ! test/compiler/codecache/jmx/PeakUsageTest.java Changeset: 1657775e680a Author: dsamersoff Date: 2016-08-18 14:07 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1657775e680a 8157236: attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file Summary: Add more diagnostic to attach code Reviewed-by: dholmes, alanb ! src/os/aix/vm/attachListener_aix.cpp ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/share/vm/logging/logTag.hpp Changeset: e99e410e78e1 Author: dsamersoff Date: 2016-08-18 11:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e99e410e78e1 Merge Changeset: 0aadda927071 Author: coleenp Date: 2016-08-18 10:47 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0aadda927071 8037138: x86: problem with JVMTI breakpoint Summary: do aload(0) after rewriting aload bytecodes to fast version for frequent pairs. Reviewed-by: dlong, dholmes, dcubed ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86.cpp Changeset: 6c29c7f73ca1 Author: dholmes Date: 2016-08-18 21:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6c29c7f73ca1 8152849: share/vm/runtime/mutex.cpp:1161 assert(((uintptr_t(_owner))|(uintptr_t(_LockWord.FullWord))|(uintptr_t(_EntryList))|(uintptr_t(_WaitSet))|(uintptr_t(_OnDeck))) == 0) failed Reviewed-by: dcubed ! src/share/vm/runtime/mutex.cpp Changeset: af4f7418af3e Author: ysuenaga Date: 2016-08-19 01:20 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/af4f7418af3e 8164319: CLHSDB dumpcodecache throws StackOverflowError Reviewed-by: dholmes, dsamersoff ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java Changeset: b2c07de32ca7 Author: erikj Date: 2016-08-19 16:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b2c07de32ca7 8164297: Jtreg test exeinvoke fails to link on Ubuntu Reviewed-by: tbell, dholmes ! make/test/JtregNative.gmk Changeset: 1cbffa2beba6 Author: ctornqvi Date: 2016-08-19 10:06 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1cbffa2beba6 8157957: ClassNotFoundException: jdk.test.lib.JDKToolFinder Reviewed-by: coleenp, gtriantafill, mseledtsov, iignatyev, dholmes, dsamersoff ! test/compiler/arguments/BMISupportedCPUTest.java ! test/compiler/arguments/BMIUnsupportedCPUTest.java ! test/compiler/arguments/CheckCICompilerCount.java ! test/compiler/arguments/CheckCompileThresholdScaling.java ! test/compiler/arguments/TestUseBMI1InstructionsOnSupportedCPU.java ! test/compiler/arguments/TestUseBMI1InstructionsOnUnsupportedCPU.java ! test/compiler/arguments/TestUseCountLeadingZerosInstructionOnSupportedCPU.java ! test/compiler/arguments/TestUseCountLeadingZerosInstructionOnUnsupportedCPU.java ! test/compiler/arguments/TestUseCountTrailingZerosInstructionOnSupportedCPU.java ! test/compiler/arguments/TestUseCountTrailingZerosInstructionOnUnsupportedCPU.java ! test/compiler/arraycopy/TestArrayCopyNoInitDeopt.java ! test/compiler/c2/PolynomialRoot.java ! test/compiler/c2/Test5057225.java ! test/compiler/c2/Test6603011.java ! test/compiler/c2/Test6800154.java ! test/compiler/c2/Test6805724.java ! test/compiler/c2/Test6857159.java ! test/compiler/c2/Test7068051.java ! test/compiler/c2/Test7177917.java ! test/compiler/c2/cr6589834/Test_ia32.java ! test/compiler/c2/stemmer/Stemmer.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2NativeTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeInterface2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeInterface2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeInterface2NativeTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeSpecial2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeSpecial2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeSpecial2NativeTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeStatic2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeStatic2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeStatic2NativeTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeVirtual2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeVirtual2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeVirtual2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeInterface2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeInterface2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeInterface2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeSpecial2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeSpecial2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeSpecial2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeStatic2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeStatic2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeStatic2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeVirtual2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeVirtual2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeVirtual2NativeTest.java ! test/compiler/calls/fromNative/NativeInvokeSpecial2CompiledTest.java ! test/compiler/calls/fromNative/NativeInvokeSpecial2InterpretedTest.java ! test/compiler/calls/fromNative/NativeInvokeSpecial2NativeTest.java ! test/compiler/calls/fromNative/NativeInvokeStatic2CompiledTest.java ! test/compiler/calls/fromNative/NativeInvokeStatic2InterpretedTest.java ! test/compiler/calls/fromNative/NativeInvokeStatic2NativeTest.java ! test/compiler/calls/fromNative/NativeInvokeVirtual2CompiledTest.java ! test/compiler/calls/fromNative/NativeInvokeVirtual2InterpretedTest.java ! test/compiler/calls/fromNative/NativeInvokeVirtual2NativeTest.java ! test/compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java ! test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java ! test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java ! test/compiler/codecache/CheckSegmentedCodeCache.java ! test/compiler/codecache/CheckUpperLimit.java ! test/compiler/codecache/OverflowCodeCacheTest.java ! test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java ! test/compiler/codecache/cli/codeheapsize/CodeCacheFreeSpaceRunner.java ! test/compiler/codecache/cli/codeheapsize/JVMStartupRunner.java ! test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java ! test/compiler/codecache/cli/printcodecache/PrintCodeCacheRunner.java ! test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java + test/compiler/codecache/dtrace/DtraceResultsAnalyzer.java + test/compiler/codecache/dtrace/DtraceRunner.java ! test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java ! test/compiler/codecache/jmx/BeanTypeTest.java ! test/compiler/codecache/jmx/CodeHeapBeanPresenceTest.java ! test/compiler/codecache/jmx/GetUsageTest.java ! test/compiler/codecache/jmx/InitialAndMaxUsageTest.java ! test/compiler/codecache/jmx/ManagerNamesTest.java ! test/compiler/codecache/jmx/MemoryPoolsPresenceTest.java ! test/compiler/codecache/jmx/PeakUsageTest.java ! test/compiler/codecache/jmx/PoolsIndependenceTest.java ! test/compiler/codecache/jmx/ThresholdNotificationsTest.java ! test/compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java ! test/compiler/codecache/jmx/UsageThresholdExceededTest.java ! test/compiler/codecache/jmx/UsageThresholdIncreasedTest.java ! test/compiler/codecache/jmx/UsageThresholdNotExceededTest.java ! test/compiler/codecache/stress/CodeCacheStressRunner.java ! test/compiler/codecache/stress/Helper.java ! test/compiler/codecache/stress/OverloadCompileQueueTest.java ! test/compiler/codecache/stress/RandomAllocationTest.java ! test/compiler/codecache/stress/UnexpectedDeoptimizationTest.java ! test/compiler/codegen/Test6823354.java ! test/compiler/codegen/Test6896617.java ! test/compiler/codegen/Test7100757.java ! test/compiler/codegen/aes/TestAESMain.java ! test/compiler/compilercontrol/InlineMatcherTest.java ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityBase.java ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java ! test/compiler/compilercontrol/commandfile/CompileOnlyTest.java ! test/compiler/compilercontrol/commandfile/ExcludeTest.java ! test/compiler/compilercontrol/commandfile/LogTest.java ! test/compiler/compilercontrol/commandfile/PrintTest.java ! test/compiler/compilercontrol/commands/CompileOnlyTest.java ! test/compiler/compilercontrol/commands/ExcludeTest.java ! test/compiler/compilercontrol/commands/LogTest.java ! test/compiler/compilercontrol/commands/PrintTest.java ! test/compiler/compilercontrol/directives/CompileOnlyTest.java ! test/compiler/compilercontrol/directives/ExcludeTest.java ! test/compiler/compilercontrol/directives/LogTest.java ! test/compiler/compilercontrol/directives/PrintTest.java ! test/compiler/compilercontrol/jcmd/AddAndRemoveTest.java ! test/compiler/compilercontrol/jcmd/AddCompileOnlyTest.java ! test/compiler/compilercontrol/jcmd/AddExcludeTest.java ! test/compiler/compilercontrol/jcmd/AddLogTest.java ! test/compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java ! test/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java ! test/compiler/compilercontrol/jcmd/ClearDirectivesStackTest.java ! test/compiler/compilercontrol/jcmd/PrintDirectivesTest.java ! test/compiler/compilercontrol/jcmd/StressAddJcmdBase.java ! test/compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java ! test/compiler/compilercontrol/logcompilation/LogTest.java ! test/compiler/compilercontrol/matcher/MethodMatcherTest.java ! test/compiler/compilercontrol/mixed/RandomCommandsTest.java ! test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java ! test/compiler/compilercontrol/parser/DirectiveParserTest.java ! test/compiler/compilercontrol/parser/DirectiveStressTest.java ! test/compiler/compilercontrol/parser/HugeDirectiveUtil.java ! test/compiler/compilercontrol/share/AbstractTestBase.java ! test/compiler/compilercontrol/share/actions/BaseAction.java ! test/compiler/compilercontrol/share/actions/CompileAction.java ! test/compiler/compilercontrol/share/method/MethodDescriptor.java ! test/compiler/compilercontrol/share/method/MethodGenerator.java ! test/compiler/compilercontrol/share/pool/MethodHolder.java ! test/compiler/compilercontrol/share/pool/PoolHelper.java ! test/compiler/compilercontrol/share/pool/SubMethodHolder.java ! test/compiler/compilercontrol/share/processors/CommandProcessor.java ! test/compiler/compilercontrol/share/processors/LogProcessor.java ! test/compiler/compilercontrol/share/processors/PrintDirectivesProcessor.java ! test/compiler/compilercontrol/share/processors/PrintProcessor.java ! test/compiler/compilercontrol/share/scenario/AbstractCommandBuilder.java ! test/compiler/compilercontrol/share/scenario/DirectiveBuilder.java ! test/compiler/compilercontrol/share/scenario/Executor.java ! test/compiler/compilercontrol/share/scenario/JcmdStateBuilder.java ! test/compiler/compilercontrol/share/scenario/Scenario.java ! test/compiler/cpuflags/RestoreMXCSR.java ! test/compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java ! test/compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java ! test/compiler/debug/VerifyAdapterSharing.java ! test/compiler/eliminateAutobox/UnsignedLoads.java ! test/compiler/floatingpoint/TestPow2.java ! test/compiler/gcbarriers/PreserveFPRegistersTest.java ! test/compiler/inlining/InlineAccessors.java ! test/compiler/interpreter/DisableOSRTest.java ! test/compiler/intrinsics/IntrinsicAvailableTest.java ! test/compiler/intrinsics/IntrinsicDisabledTest.java ! test/compiler/intrinsics/bigInteger/MontgomeryMultiplyTest.java ! test/compiler/intrinsics/bmi/BMITestRunner.java ! test/compiler/intrinsics/bmi/TestAndnI.java ! test/compiler/intrinsics/bmi/TestAndnL.java ! test/compiler/intrinsics/bmi/TestBlsiI.java ! test/compiler/intrinsics/bmi/TestBlsiL.java ! test/compiler/intrinsics/bmi/TestBlsmskI.java ! test/compiler/intrinsics/bmi/TestBlsmskL.java ! test/compiler/intrinsics/bmi/TestBlsrI.java ! test/compiler/intrinsics/bmi/TestBlsrL.java ! test/compiler/intrinsics/bmi/TestLzcntI.java ! test/compiler/intrinsics/bmi/TestLzcntL.java ! test/compiler/intrinsics/bmi/TestTzcntI.java ! test/compiler/intrinsics/bmi/TestTzcntL.java ! test/compiler/intrinsics/bmi/verifycode/AndnTestI.java ! test/compiler/intrinsics/bmi/verifycode/AndnTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsiTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsiTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsmskTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsmskTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsrTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsrTestL.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestL.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestL.java ! test/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java ! test/compiler/intrinsics/mathexact/AddExactIConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactILoadTest.java ! test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/AddExactLConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/DecExactITest.java ! test/compiler/intrinsics/mathexact/DecExactLTest.java ! test/compiler/intrinsics/mathexact/IncExactITest.java ! test/compiler/intrinsics/mathexact/IncExactLTest.java ! test/compiler/intrinsics/mathexact/MulExactIConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactILoadTest.java ! test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/MulExactLConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactIConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactILoadTest.java ! test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactLConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactICondTest.java ! test/compiler/intrinsics/mathexact/SubExactIConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactILoadTest.java ! test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/sanity/AddExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/AddExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java ! test/compiler/intrinsics/object/TestClone.java ! test/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java ! test/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java ! test/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java ! test/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java ! test/compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java ! test/compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java ! test/compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java ! test/compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java ! test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForOtherCPU.java ! test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedCPU.java ! test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedAArch64CPU.java ! test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedSparcCPU.java ! test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedX86CPU.java ! test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java ! test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedCPU.java ! test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedCPU.java ! test/compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java ! test/compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java ! test/compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java ! test/compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java ! test/compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java ! test/compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java ! test/compiler/intrinsics/string/TestHasNegatives.java ! test/compiler/intrinsics/string/TestStringIntrinsicMemoryFlow.java ! test/compiler/intrinsics/string/TestStringIntrinsicRangeChecks.java ! test/compiler/intrinsics/string/TestStringIntrinsics2.java ! test/compiler/intrinsics/unsafe/DirectByteBufferTest.java ! test/compiler/intrinsics/unsafe/HeapByteBufferTest.java ! test/compiler/intrinsics/unsafe/TestUnsafeMismatchedArrayFieldAccess.java ! test/compiler/jsr292/ConcurrentClassLoadingTest.java ! test/compiler/jsr292/ContinuousCallSiteTargetChange.java ! test/compiler/jsr292/MHInlineTest.java ! test/compiler/jsr292/NonInlinedCall/Agent.java ! test/compiler/jsr292/NonInlinedCall/GCTest.java ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java ! test/compiler/jsr292/NonInlinedCall/RedefineTest.java ! test/compiler/jsr292/PollutedTrapCounts.java ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java ! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/CollectCountersTest.java ! test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java ! test/compiler/jvmci/compilerToVM/DebugOutputTest.java ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java ! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java ! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java ! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java ! test/compiler/jvmci/compilerToVM/GetImplementorTest.java ! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java ! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java ! test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java ! test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java ! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java ! test/compiler/jvmci/compilerToVM/GetSymbolTest.java ! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java ! test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/IsMatureTest.java ! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupMethodInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameAndTypeRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupSignatureInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupTypeTest.java ! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java ! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java ! test/compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java ! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java ! test/compiler/jvmci/errors/TestInvalidCompilationResult.java ! test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/compiler/jvmci/events/JvmciShutdownEventTest.java ! test/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java ! test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/HotSpotConstantReflectionProviderTest.java ! test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderTest.java ! test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/compiler/jvmci/meta/StableFieldTest.java ! test/compiler/loopopts/UseCountedLoopSafepoints.java ! test/compiler/loopopts/superword/TestVectorizationWithInvariant.java ! test/compiler/onSpinWait/TestOnSpinWait.java ! test/compiler/oracle/CheckCompileCommandOption.java ! test/compiler/oracle/GetMethodOptionTest.java ! test/compiler/oracle/MethodMatcherTest.java ! test/compiler/oracle/TestCompileCommand.java ! test/compiler/print/TestProfileReturnTypePrinting.java ! test/compiler/profiling/spectrapredefineclass/Launcher.java ! test/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java ! test/compiler/rangechecks/TestExplicitRangeChecks.java ! test/compiler/rangechecks/TestRangeCheckSmearing.java ! test/compiler/rtm/cli/RTMGenericCommandLineOptionTest.java ! test/compiler/rtm/cli/RTMLockingAwareTest.java ! test/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java ! test/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestRTMAbortThresholdOption.java ! test/compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java ! test/compiler/rtm/cli/TestRTMLockingThresholdOption.java ! test/compiler/rtm/cli/TestRTMRetryCountOption.java ! test/compiler/rtm/cli/TestRTMSpinLoopCountOption.java ! test/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java ! test/compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java ! test/compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java ! test/compiler/rtm/locking/TestRTMAbortRatio.java ! test/compiler/rtm/locking/TestRTMAbortThreshold.java ! test/compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java ! test/compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java ! test/compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java ! test/compiler/rtm/locking/TestRTMLockingCalculationDelay.java ! test/compiler/rtm/locking/TestRTMLockingThreshold.java ! test/compiler/rtm/locking/TestRTMRetryCount.java ! test/compiler/rtm/locking/TestRTMSpinLoopCount.java ! test/compiler/rtm/locking/TestRTMTotalCountIncrRate.java ! test/compiler/rtm/locking/TestUseRTMAfterLockInflation.java ! test/compiler/rtm/locking/TestUseRTMDeopt.java ! test/compiler/rtm/locking/TestUseRTMForInflatedLocks.java ! test/compiler/rtm/locking/TestUseRTMForStackLocks.java ! test/compiler/rtm/locking/TestUseRTMXendForLockBusy.java ! test/compiler/rtm/method_options/TestNoRTMLockElidingOption.java ! test/compiler/rtm/method_options/TestUseRTMLockElidingOption.java ! test/compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java ! test/compiler/runtime/Test8010927.java ! test/compiler/runtime/cr8015436/Test8015436.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/stable/TestStableUByte.java ! test/compiler/stable/TestStableUShort.java ! test/compiler/startup/NumCompilerThreadsCheck.java ! test/compiler/startup/SmallCodeCacheStartup.java ! test/compiler/startup/StartupOutput.java ! test/compiler/testlibrary/rtm/RTMTestBase.java ! test/compiler/tiered/ConstantGettersTransitionsTest.java ! test/compiler/tiered/LevelTransitionTest.java ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/tiered/TieredLevelsTest.java ! test/compiler/tiered/TransitionsTestExecutor.java ! test/compiler/types/TestMeetIncompatibleInterfaceArrays.java ! test/compiler/types/correctness/CorrectnessTest.java ! test/compiler/types/correctness/OffTest.java ! test/compiler/uncommontrap/DeoptReallocFailure.java ! test/compiler/uncommontrap/Test8009761.java ! test/compiler/uncommontrap/TestUnstableIfTrap.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/compiler/unsafe/UnsafeGetStableArrayElement.java ! test/compiler/unsafe/UnsafeRaw.java ! test/compiler/whitebox/AllocationCodeBlobTest.java ! test/compiler/whitebox/BlockingCompilation.java ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeFramesTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/DeoptimizeMultipleOSRTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/ForceNMethodSweepTest.java ! test/compiler/whitebox/GetCodeHeapEntriesTest.java ! test/compiler/whitebox/GetNMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/LockCompilationTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/gc/CondCardMark/Basic.java ! test/gc/TestCardTablePageCommits.java ! test/gc/TestDisableExplicitGC.java ! test/gc/TestObjectAlignment.java ! test/gc/TestSmallHeap.java ! test/gc/TestSoftReferencesBehaviorOnOOME.java ! test/gc/TestVerifyDuringStartup.java ! test/gc/TestVerifySilently.java ! test/gc/TestVerifySubSet.java + test/gc/arguments/AllocationHelper.java + test/gc/arguments/HeapRegionUsageTool.java ! test/gc/arguments/TestArrayAllocatorMallocLimit.java ! test/gc/arguments/TestCMSHeapSizeFlags.java ! test/gc/arguments/TestCompressedClassFlags.java ! test/gc/arguments/TestDisableDefaultGC.java ! test/gc/arguments/TestDynMaxHeapFreeRatio.java ! test/gc/arguments/TestDynMinHeapFreeRatio.java ! test/gc/arguments/TestG1ConcMarkStepDurationMillis.java ! test/gc/arguments/TestG1ConcRefinementThreads.java ! test/gc/arguments/TestG1HeapRegionSize.java ! test/gc/arguments/TestG1HeapSizeFlags.java ! test/gc/arguments/TestG1PercentageOptions.java ! test/gc/arguments/TestHeapFreeRatio.java ! test/gc/arguments/TestInitialTenuringThreshold.java ! test/gc/arguments/TestMaxHeapSizeTools.java ! test/gc/arguments/TestMaxMinHeapFreeRatioFlags.java ! test/gc/arguments/TestMaxNewSize.java ! test/gc/arguments/TestMinAndInitialSurvivorRatioFlags.java ! test/gc/arguments/TestMinInitialErgonomics.java ! test/gc/arguments/TestNewRatioFlag.java ! test/gc/arguments/TestNewSizeFlags.java ! test/gc/arguments/TestNewSizeThreadIncrease.java ! test/gc/arguments/TestObjectTenuringFlags.java ! test/gc/arguments/TestParallelGCThreads.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestSelectDefaultGC.java ! test/gc/arguments/TestSerialHeapSizeFlags.java ! test/gc/arguments/TestShrinkHeapInSteps.java ! test/gc/arguments/TestSurvivorAlignmentInBytesOption.java ! test/gc/arguments/TestSurvivorRatioFlag.java ! test/gc/arguments/TestTargetSurvivorRatioFlag.java ! test/gc/arguments/TestUnrecognizedVMOptionsHandling.java ! test/gc/arguments/TestUseCompressedOopsErgo.java ! test/gc/arguments/TestUseCompressedOopsErgoTools.java ! test/gc/arguments/TestUseNUMAInterleaving.java ! test/gc/arguments/TestVerifyBeforeAndAfterGCFlags.java ! test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java ! test/gc/class_unloading/TestG1ClassUnloadingHWM.java ! test/gc/cms/GuardShrinkWarning.java ! test/gc/ergonomics/TestDynamicNumberOfGCThreads.java ! test/gc/ergonomics/TestInitialGCThreadLogging.java ! test/gc/g1/Test2GbHeap.java ! test/gc/g1/TestEagerReclaimHumongousRegions.java ! test/gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java ! test/gc/g1/TestEagerReclaimHumongousRegionsWithRefs.java ! test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java ! test/gc/g1/TestGCLogMessages.java ! test/gc/g1/TestHumongousAllocInitialMark.java ! test/gc/g1/TestHumongousAllocNearlyFullRegion.java ! test/gc/g1/TestHumongousCodeCacheRoots.java ! test/gc/g1/TestHumongousShrinkHeap.java ! test/gc/g1/TestLargePageUseForAuxMemory.java ! test/gc/g1/TestNoEagerReclaimOfHumongousRegions.java ! test/gc/g1/TestPLABOutput.java ! test/gc/g1/TestPLABSizeBounds.java ! test/gc/g1/TestPrintRegionRememberedSetInfo.java ! test/gc/g1/TestRegionLivenessPrint.java ! test/gc/g1/TestRemsetLogging.java ! test/gc/g1/TestRemsetLoggingPerRegion.java ! test/gc/g1/TestRemsetLoggingThreads.java ! test/gc/g1/TestRemsetLoggingTools.java ! test/gc/g1/TestShrinkAuxiliaryData.java ! test/gc/g1/TestShrinkAuxiliaryData00.java ! test/gc/g1/TestShrinkAuxiliaryData05.java ! test/gc/g1/TestShrinkAuxiliaryData10.java ! test/gc/g1/TestShrinkAuxiliaryData15.java ! test/gc/g1/TestShrinkAuxiliaryData20.java ! test/gc/g1/TestShrinkAuxiliaryData25.java ! test/gc/g1/TestShrinkAuxiliaryData30.java ! test/gc/g1/TestShrinkDefragmentedHeap.java ! test/gc/g1/TestStringDeduplicationAgeThreshold.java ! test/gc/g1/TestStringDeduplicationFullGC.java ! test/gc/g1/TestStringDeduplicationInterned.java ! test/gc/g1/TestStringDeduplicationPrintOptions.java ! test/gc/g1/TestStringDeduplicationTableRehash.java ! test/gc/g1/TestStringDeduplicationTableResize.java ! test/gc/g1/TestStringDeduplicationTools.java ! test/gc/g1/TestStringDeduplicationYoungGC.java ! test/gc/g1/TestStringSymbolTableStats.java ! test/gc/g1/humongousObjects/TestHeapCounters.java ! test/gc/g1/humongousObjects/TestHumongousClassLoader.java ! test/gc/g1/humongousObjects/TestHumongousMovement.java ! test/gc/g1/humongousObjects/TestHumongousNonArrayAllocation.java ! test/gc/g1/humongousObjects/TestHumongousThreshold.java ! test/gc/g1/humongousObjects/TestNoAllocationsInHRegions.java ! test/gc/g1/humongousObjects/TestObjectCollected.java ! test/gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java ! test/gc/g1/ihop/TestIHOPErgo.java ! test/gc/g1/ihop/TestIHOPStatic.java ! test/gc/g1/ihop/lib/IhopUtils.java ! test/gc/g1/mixedgc/TestLogging.java ! test/gc/g1/plab/TestPLABEvacuationFailure.java ! test/gc/g1/plab/TestPLABPromotion.java ! test/gc/g1/plab/TestPLABResize.java ! test/gc/g1/plab/lib/PLABUtils.java ! test/gc/logging/TestDeprecatedPrintFlags.java ! test/gc/logging/TestGCId.java ! test/gc/logging/TestPrintReferences.java ! test/gc/logging/TestUnifiedLoggingSwitchStress.java ! test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java + test/gc/metaspace/InputArguments.java ! test/gc/metaspace/PerfCounters.java ! test/gc/metaspace/TestCapacityUntilGCWrapAround.java ! test/gc/metaspace/TestMetaspaceCMSCancel.java ! test/gc/metaspace/TestMetaspaceInitialization.java ! test/gc/metaspace/TestMetaspaceMemoryPool.java ! test/gc/metaspace/TestMetaspacePerfCounters.java ! test/gc/metaspace/TestMetaspaceSizeFlags.java ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java ! test/gc/parallel/AdaptiveGCBoundary.java ! test/gc/parallel/TestDynShrinkHeap.java ! test/gc/parallel/TestPrintGCDetailsVerbose.java ! test/gc/serial/HeapChangeLogging.java ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestDefNewCMS.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParNewSerialOld.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java ! test/gc/stress/TestMultiThreadStressRSet.java ! test/gc/stress/TestStressRSetCoarsening.java ! test/gc/survivorAlignment/TestAllocationInEden.java ! test/gc/survivorAlignment/TestPromotionFromEdenToTenured.java ! test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterFullGC.java ! test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java ! test/gc/survivorAlignment/TestPromotionToSurvivor.java ! test/gc/testlibrary/Helpers.java ! test/gc/whitebox/TestConcMarkCycleWB.java ! test/gc/whitebox/TestWBGC.java ! test/native/GTestWrapper.java ! test/runtime/8026365/InvokeSpecialAnonTest.java ! test/runtime/BadObjectClass/BootstrapRedefine.java ! test/runtime/BoolReturn/NativeSmallIntCallsTest.java ! test/runtime/BootClassAppendProp/BootClassPathAppend.java ! test/runtime/BootClassAppendProp/BootClassPathAppendProp.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/ClassFile/JsrRewriting.java ! test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java ! test/runtime/ClassFile/UnsupportedClassFileVersion.java ! test/runtime/ClassUnload/KeepAliveClass.java ! test/runtime/ClassUnload/KeepAliveClassLoader.java ! test/runtime/ClassUnload/KeepAliveObject.java ! test/runtime/ClassUnload/KeepAliveSoftReference.java ! test/runtime/ClassUnload/UnloadTest.java ! test/runtime/CommandLine/BooleanFlagWithInvalidValue.java ! test/runtime/CommandLine/CompilerConfigFileWarning.java ! test/runtime/CommandLine/ConfigFileParsing.java ! test/runtime/CommandLine/ConfigFileWarning.java ! test/runtime/CommandLine/FlagWithInvalidValue.java ! test/runtime/CommandLine/IgnoreUnrecognizedVMOptions.java ! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java ! test/runtime/CommandLine/ObsoleteFlagErrorMessage.java ! test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRangesDynamic.java ! test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java ! test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java ! test/runtime/CommandLine/PrintTouchedMethods.java ! test/runtime/CommandLine/TestHexArguments.java ! test/runtime/CommandLine/TestLongUnrecognizedVMOption.java ! test/runtime/CommandLine/TestNullTerminatedFlags.java ! test/runtime/CommandLine/TestVMOptions.java ! test/runtime/CommandLine/TraceExceptionsTest.java ! test/runtime/CommandLine/UnrecognizedVMOption.java ! test/runtime/CommandLine/VMAliasOptions.java ! test/runtime/CommandLine/VMDeprecatedOptions.java ! test/runtime/CommandLine/VMOptionWarning.java ! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java ! test/runtime/CompressedOops/CompressedClassPointers.java ! test/runtime/CompressedOops/CompressedClassSpaceSize.java ! test/runtime/CompressedOops/CompressedKlassPointerAndOops.java ! test/runtime/CompressedOops/ObjectAlignment.java ! test/runtime/CompressedOops/UseCompressedOops.java ! test/runtime/ConstantPool/BadMethodHandles.java ! test/runtime/ConstantPool/IntfMethod.java ! test/runtime/EnclosingMethodAttr/EnclMethodAttr.java ! test/runtime/ErrorHandling/CreateCoredumpOnCrash.java ! test/runtime/ErrorHandling/ErrorHandler.java ! test/runtime/ErrorHandling/ProblematicFrameTest.java ! test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java ! test/runtime/ErrorHandling/SecondaryErrorTest.java ! test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java ! test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java ! test/runtime/ErrorHandling/TestOnError.java ! test/runtime/ErrorHandling/TestOnOutOfMemoryError.java ! test/runtime/Final/TestPutMain.java ! test/runtime/LoadClass/LoadClassNegative.java ! test/runtime/LocalVariableTable/TestLVT.java ! test/runtime/Metaspace/FragmentMetaspace.java ! test/runtime/NMT/AutoshutdownNMT.java ! test/runtime/NMT/BaselineWithParameter.java ! test/runtime/NMT/ChangeTrackingLevel.java ! test/runtime/NMT/CheckForProperDetailStackTrace.java ! test/runtime/NMT/CommandLineDetail.java ! test/runtime/NMT/CommandLineEmptyArgument.java ! test/runtime/NMT/CommandLineInvalidArgument.java ! test/runtime/NMT/CommandLineSummary.java ! test/runtime/NMT/CommandLineTurnOffNMT.java ! test/runtime/NMT/CommitOverlappingRegions.java ! test/runtime/NMT/JcmdBaselineDetail.java ! test/runtime/NMT/JcmdDetailDiff.java ! test/runtime/NMT/JcmdScale.java ! test/runtime/NMT/JcmdScaleDetail.java ! test/runtime/NMT/JcmdSummaryDiff.java ! test/runtime/NMT/JcmdWithNMTDisabled.java ! test/runtime/NMT/MallocRoundingReportTest.java ! test/runtime/NMT/MallocSiteHashOverflow.java ! test/runtime/NMT/MallocStressTest.java ! test/runtime/NMT/MallocTestType.java ! test/runtime/NMT/MallocTrackingVerify.java ! test/runtime/NMT/NMTWithCDS.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java ! test/runtime/NMT/ReleaseCommittedMemory.java ! test/runtime/NMT/ReleaseNoCommit.java ! test/runtime/NMT/ShutdownTwice.java ! test/runtime/NMT/SummaryAfterShutdown.java ! test/runtime/NMT/SummarySanityCheck.java ! test/runtime/NMT/ThreadedMallocTestType.java ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/runtime/PerfMemDestroy/PerfMemDestroy.java ! test/runtime/RedefineObject/TestRedefineObject.java ! test/runtime/RedefineTests/RedefineAnnotations.java ! test/runtime/RedefineTests/RedefineFinalizer.java ! test/runtime/RedefineTests/RedefineRunningMethods.java ! test/runtime/RedefineTests/RedefineRunningMethodsWithBacktrace.java ! test/runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java ! test/runtime/ReservedStack/ReservedStackTest.java ! test/runtime/ReservedStack/ReservedStackTestCompiler.java ! test/runtime/Safepoint/AssertSafepointCheckConsistency1.java ! test/runtime/Safepoint/AssertSafepointCheckConsistency2.java ! test/runtime/Safepoint/AssertSafepointCheckConsistency3.java ! test/runtime/Safepoint/AssertSafepointCheckConsistency4.java ! test/runtime/SameObject/SameObject.java ! test/runtime/SelectionResolution/AbstractMethodErrorTest.java ! test/runtime/SelectionResolution/IllegalAccessErrorTest.java ! test/runtime/SelectionResolution/InvokeInterfaceICCE.java ! test/runtime/SelectionResolution/InvokeInterfaceSuccessTest.java ! test/runtime/SelectionResolution/InvokeSpecialICCE.java ! test/runtime/SelectionResolution/InvokeSpecialSuccessTest.java ! test/runtime/SelectionResolution/InvokeStaticICCE.java ! test/runtime/SelectionResolution/InvokeStaticSuccessTest.java ! test/runtime/SelectionResolution/InvokeVirtualICCE.java ! test/runtime/SelectionResolution/InvokeVirtualSuccessTest.java ! test/runtime/SelectionResolution/NoSuchMethodErrorTest.java ! test/runtime/SharedArchiveFile/ArchiveDoesNotExist.java ! test/runtime/SharedArchiveFile/BootAppendTests.java ! test/runtime/SharedArchiveFile/CdsDifferentCompactStrings.java ! test/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java ! test/runtime/SharedArchiveFile/DefaultUseWithClient.java ! test/runtime/SharedArchiveFile/DumpSymbolAndStringTable.java ! test/runtime/SharedArchiveFile/LimitSharedSizes.java ! test/runtime/SharedArchiveFile/MaxMetaspaceSize.java ! test/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java ! test/runtime/SharedArchiveFile/SASymbolTableTest.java ! test/runtime/SharedArchiveFile/SharedArchiveFile.java ! test/runtime/SharedArchiveFile/SharedBaseAddress.java ! test/runtime/SharedArchiveFile/SharedStrings.java ! test/runtime/SharedArchiveFile/SharedStringsDedup.java ! test/runtime/SharedArchiveFile/SharedStringsRunAuto.java ! test/runtime/SharedArchiveFile/SharedSymbolTableBucketSize.java ! test/runtime/SharedArchiveFile/SpaceUtilizationCheck.java ! test/runtime/Thread/Fibonacci.java ! test/runtime/Thread/TestThreadDumpMonitorContention.java ! test/runtime/Thread/ThreadPriorities.java ! test/runtime/ThreadSignalMask/ThreadSignalMask.java ! test/runtime/Throwable/StackTraceLogging.java ! test/runtime/Throwable/TestThrowable.java ! test/runtime/Throwable/ThrowableIntrospectionSegfault.java ! test/runtime/Unsafe/AllocateInstance.java ! test/runtime/Unsafe/AllocateMemory.java ! test/runtime/Unsafe/CopyMemory.java ! test/runtime/Unsafe/DefineClass.java ! test/runtime/Unsafe/FieldOffset.java ! test/runtime/Unsafe/GetField.java ! test/runtime/Unsafe/GetPutAddress.java ! test/runtime/Unsafe/GetPutBoolean.java ! test/runtime/Unsafe/GetPutByte.java ! test/runtime/Unsafe/GetPutChar.java ! test/runtime/Unsafe/GetPutDouble.java ! test/runtime/Unsafe/GetPutFloat.java ! test/runtime/Unsafe/GetPutInt.java ! test/runtime/Unsafe/GetPutLong.java ! test/runtime/Unsafe/GetPutObject.java ! test/runtime/Unsafe/GetPutShort.java ! test/runtime/Unsafe/GetUncompressedObject.java ! test/runtime/Unsafe/NestedUnsafe.java ! test/runtime/Unsafe/PageSize.java ! test/runtime/Unsafe/PrimitiveHostClass.java ! test/runtime/Unsafe/RangeCheck.java ! test/runtime/Unsafe/Reallocate.java ! test/runtime/Unsafe/SetMemory.java ! test/runtime/Unsafe/ThrowException.java ! test/runtime/XCheckJniJsig/XCheckJSig.java ! test/runtime/classFileParserBug/ClassFileParserBug.java ! test/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java ! test/runtime/contended/Options.java ! test/runtime/duplAttributes/DuplAttributesTest.java ! test/runtime/execstack/Testexecstack.java ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/runtime/interned/SanityTest.java ! test/runtime/jni/ToStringInInterfaceTest/ToStringTest.java ! test/runtime/libadimalloc.solaris.sparc/Testlibadimalloc.java ! test/runtime/logging/BiasedLockingTest.java ! test/runtime/logging/ClassInitializationTest.java ! test/runtime/logging/ClassLoadUnloadTest.java ! test/runtime/logging/ClassResolutionTest.java ! test/runtime/logging/CompressedOopsTest.java ! test/runtime/logging/DefaultMethodsTest.java ! test/runtime/logging/ExceptionsTest.java ! test/runtime/logging/ItablesTest.java ! test/runtime/logging/LoaderConstraintsTest.java ! test/runtime/logging/ModulesTest.java ! test/runtime/logging/MonitorInflationTest.java ! test/runtime/logging/MonitorMismatchTest.java ! test/runtime/logging/OsCpuLoggingTest.java ! test/runtime/logging/ProtectionDomainVerificationTest.java ! test/runtime/logging/RemovedDevelopFlagsTest.java ! test/runtime/logging/SafepointCleanupTest.java ! test/runtime/logging/SafepointTest.java ! test/runtime/logging/StartupTimeTest.java ! test/runtime/logging/ThreadLoggingTest.java ! test/runtime/logging/VMOperationTest.java ! test/runtime/logging/VerificationTest.java ! test/runtime/logging/VtablesTest.java ! test/runtime/memory/LargePages/TestLargePageSizeInBytes.java ! test/runtime/memory/LargePages/TestLargePagesFlags.java ! test/runtime/memory/ReadFromNoaccessArea.java ! test/runtime/memory/ReadVMPageSize.java ! test/runtime/memory/ReserveMemory.java ! test/runtime/memory/RunUnitTestsConcurrently.java ! test/runtime/memory/StressVirtualSpaceResize.java ! test/runtime/modules/AccModuleTest.java ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodDiffCL_Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_Umod.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_Umod.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod_UmodUpkg.java ! test/runtime/modules/AccessCheckAllUnnamed.java ! test/runtime/modules/AccessCheckExp.java ! test/runtime/modules/AccessCheckJavaBase.java ! test/runtime/modules/AccessCheckRead.java ! test/runtime/modules/AccessCheckSuper.java ! test/runtime/modules/AccessCheckUnnamed.java ! test/runtime/modules/AccessCheckWorks.java ! test/runtime/modules/ExportTwice.java ! test/runtime/modules/IgnoreModulePropertiesTest.java ! test/runtime/modules/JVMAddModuleExportToAllUnnamed.java ! test/runtime/modules/JVMAddModuleExports.java ! test/runtime/modules/JVMAddModuleExportsToAll.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMAddReadsModule.java ! test/runtime/modules/JVMCanReadModule.java ! test/runtime/modules/JVMDefineModule.java ! test/runtime/modules/JVMGetModuleByPkgName.java ! test/runtime/modules/JVMIsExportedToModule.java ! test/runtime/modules/LoadUnloadModuleStress.java ! test/runtime/modules/ModuleOptionsTest.java ! test/runtime/modules/ModuleOptionsWarn.java ! test/runtime/modules/ModuleStress/ExportModuleStressTest.java ! test/runtime/modules/ModuleStress/ModuleStress.java ! test/runtime/modules/ModuleStress/ModuleStressGC.java ! test/runtime/modules/PatchModule/BasicJarBuilder.java ! test/runtime/modules/PatchModule/PatchModule2Dirs.java ! test/runtime/modules/PatchModule/PatchModuleCDS.java ! test/runtime/modules/PatchModule/PatchModuleDupJavaBase.java ! test/runtime/modules/PatchModule/PatchModuleDupModule.java ! test/runtime/modules/PatchModule/PatchModuleJavaBase.java ! test/runtime/modules/PatchModule/PatchModuleTest.java ! test/runtime/modules/PatchModule/PatchModuleTestJar.java ! test/runtime/modules/PatchModule/PatchModuleTestJarDir.java ! test/runtime/modules/PatchModule/PatchModuleTraceCL.java ! test/runtime/modules/Visibility/PatchModuleVisibility.java ! test/runtime/modules/Visibility/XbootcpNoVisibility.java ! test/runtime/modules/Visibility/XbootcpVisibility.java ! test/runtime/os/AvailableProcessors.java ! test/runtime/verifier/OverriderMsg.java ! test/runtime/verifier/TestANewArray.java ! test/runtime/verifier/TestMultiANewArray.java ! test/runtime/verifier/TraceClassRes.java ! test/runtime/whitebox/WBStackSize.java ! test/sanity/MismatchedWhiteBox/WhiteBox.java ! test/sanity/WBApi.java ! test/serviceability/ParserTest.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/attach/AttachWithStalePidFile.java ! test/serviceability/dcmd/compiler/CodeCacheTest.java ! test/serviceability/dcmd/compiler/CodelistTest.java ! test/serviceability/dcmd/compiler/CompilerDirectivesDCMDTest.java ! test/serviceability/dcmd/compiler/CompilerQueueTest.java ! test/serviceability/dcmd/framework/HelpTest.java ! test/serviceability/dcmd/framework/InvalidCommandTest.java ! test/serviceability/dcmd/framework/VMVersionTest.java ! test/serviceability/dcmd/gc/ClassHistogramAllTest.java ! test/serviceability/dcmd/gc/ClassHistogramTest.java ! test/serviceability/dcmd/gc/FinalizerInfoTest.java ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java ! test/serviceability/dcmd/gc/HeapInfoTest.java ! test/serviceability/dcmd/gc/RunFinalizationTest.java ! test/serviceability/dcmd/gc/RunGCTest.java ! test/serviceability/dcmd/jvmti/DataDumpDcmdTest.java ! test/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java ! test/serviceability/dcmd/thread/PrintConcurrentLocksTest.java ! test/serviceability/dcmd/thread/PrintTest.java ! test/serviceability/dcmd/vm/ClassHierarchyTest.java ! test/serviceability/dcmd/vm/ClassLoaderStatsTest.java ! test/serviceability/dcmd/vm/CommandLineTest.java ! test/serviceability/dcmd/vm/DynLibsTest.java ! test/serviceability/dcmd/vm/FlagsTest.java ! test/serviceability/dcmd/vm/SetVMFlagTest.java ! test/serviceability/dcmd/vm/SystemPropertiesTest.java ! test/serviceability/dcmd/vm/UptimeTest.java ! test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java ! test/serviceability/jvmti/GetObjectSizeClass.java ! test/serviceability/jvmti/GetObjectSizeOverflow.java ! test/serviceability/jvmti/TestLambdaFormRetransformation.java ! test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java ! test/serviceability/logging/TestBasicLogOutput.java ! test/serviceability/logging/TestDefaultLogOutput.java ! test/serviceability/logging/TestLogRotation.java ! test/serviceability/logging/TestMultipleXlogArgs.java ! test/serviceability/logging/TestQuotedLogOutputs.java ! test/serviceability/sa/DeadlockDetectionTest.java ! test/serviceability/sa/TestInstanceKlassSize.java ! test/serviceability/sa/TestInstanceKlassSizeForInterface.java ! test/serviceability/sa/jmap-hashcode/Test8028623.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/serviceability/sa/sadebugd/SADebugDTest.java ! test/serviceability/threads/TestFalseDeadLock.java ! test/serviceability/tmtools/jstack/DaemonThreadTest.java ! test/serviceability/tmtools/jstack/JstackThreadTest.java ! test/serviceability/tmtools/jstack/SpreadLockTest.java ! test/serviceability/tmtools/jstack/ThreadNamesTest.java ! test/serviceability/tmtools/jstack/TraveledLockTest.java ! test/serviceability/tmtools/jstack/WaitNotifyThreadTest.java ! test/serviceability/tmtools/jstat/GcCapacityTest.java ! test/serviceability/tmtools/jstat/GcCauseTest01.java ! test/serviceability/tmtools/jstat/GcCauseTest02.java ! test/serviceability/tmtools/jstat/GcCauseTest03.java ! test/serviceability/tmtools/jstat/GcNewTest.java ! test/serviceability/tmtools/jstat/GcTest01.java ! test/serviceability/tmtools/jstat/GcTest02.java - test/testlibrary/ClassFileInstaller.java - test/testlibrary/RedefineClassHelper.java - test/testlibrary/jdk/test/lib/AllocationHelper.java - test/testlibrary/jdk/test/lib/Asserts.java - test/testlibrary/jdk/test/lib/BuildHelper.java - test/testlibrary/jdk/test/lib/ByteCodeLoader.java - test/testlibrary/jdk/test/lib/DynamicVMOption.java - test/testlibrary/jdk/test/lib/ExitCode.java - test/testlibrary/jdk/test/lib/FileInstaller.java - test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java - test/testlibrary/jdk/test/lib/InMemoryJavaCompiler.java - test/testlibrary/jdk/test/lib/InfiniteLoop.java - test/testlibrary/jdk/test/lib/InputArguments.java - test/testlibrary/jdk/test/lib/JDKToolFinder.java - test/testlibrary/jdk/test/lib/JDKToolLauncher.java - test/testlibrary/jdk/test/lib/OutputAnalyzer.java - test/testlibrary/jdk/test/lib/OutputBuffer.java - test/testlibrary/jdk/test/lib/Pair.java - test/testlibrary/jdk/test/lib/Platform.java - test/testlibrary/jdk/test/lib/ProcessTools.java - test/testlibrary/jdk/test/lib/StreamPumper.java - test/testlibrary/jdk/test/lib/TimeLimitedRunner.java - test/testlibrary/jdk/test/lib/Triple.java - test/testlibrary/jdk/test/lib/Utils.java - test/testlibrary/jdk/test/lib/cli/CPUSpecificCommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/CommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/predicate/AndPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/CPUSpecificPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/NotPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/OrPredicate.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutor.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutorException.java - test/testlibrary/jdk/test/lib/dcmd/FileJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JMXExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/MainClassJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/PidJcmdExecutor.java - test/testlibrary/jdk/test/lib/dtrace/DtraceResultsAnalyzer.java - test/testlibrary/jdk/test/lib/dtrace/DtraceRunner.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/Automatic.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/AssignmentOperatorImplFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryArithmeticOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryBitwiseOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryComparisonOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryEqualityOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryLogicOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryShiftOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/BinaryStringPlusFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/CompoundArithmeticAssignmentOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/CompoundBitwiseAssignmentOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/factories/CompoundShiftAssignmentOperatorFactory.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/jtreg/JitTesterDriver.java ! test/testlibrary/jittester/src/jdk/test/lib/jittester/visitors/ByteCodeVisitor.java ! test/testlibrary_tests/AssertsTest.java ! test/testlibrary_tests/OutputAnalyzerReportingTest.java ! test/testlibrary_tests/OutputAnalyzerTest.java ! test/testlibrary_tests/RandomGeneratorTest.java ! test/testlibrary_tests/RedefineClassTest.java ! test/testlibrary_tests/SimpleClassFileLoadHookTest.java ! test/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java ! test/testlibrary_tests/TestPlatformIsTieredSupported.java ! test/testlibrary_tests/ctw/ClassesDirTest.java ! test/testlibrary_tests/ctw/ClassesListTest.java ! test/testlibrary_tests/ctw/CtwTest.java ! test/testlibrary_tests/ctw/JarDirTest.java ! test/testlibrary_tests/ctw/JarsTest.java ! test/testlibrary_tests/whitebox/BlobSanityTest.java ! test/testlibrary_tests/whitebox/vm_flags/BooleanTest.java ! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java ! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java ! test/testlibrary_tests/whitebox/vm_flags/SizeTTest.java ! test/testlibrary_tests/whitebox/vm_flags/StringTest.java ! test/testlibrary_tests/whitebox/vm_flags/Uint64Test.java ! test/testlibrary_tests/whitebox/vm_flags/UintxTest.java ! test/testlibrary_tests/whitebox/vm_flags/VmFlagTest.java Changeset: 7971fae4be0f Author: ctornqvi Date: 2016-08-19 18:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7971fae4be0f Merge Changeset: 95b257c9d186 Author: acorn Date: 2016-08-19 11:32 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/95b257c9d186 8163808: Fix asserts and logging for old classfile vtable construction Reviewed-by: coleenp, lfoltan, rprotacio, ctornqvi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp + test/runtime/TransitiveOverrideCFV50/TransitiveOverrideCFV50.java ! test/runtime/logging/VtablesTest.java Changeset: b57963fcd4f3 Author: acorn Date: 2016-08-19 20:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b57963fcd4f3 Merge ! test/runtime/logging/VtablesTest.java Changeset: c8aaea51e2eb Author: coleenp Date: 2016-08-19 14:54 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c8aaea51e2eb 8145964: NoClassDefFound error in transforming lambdas Summary: Skip VM anonymous classes in retransformation and give an error for redefinition. Reviewed-by: dholmes, dcubed, never ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp + test/runtime/RedefineTests/ModifyAnonymous.java Changeset: 56f8dd524acd Author: coleenp Date: 2016-08-19 22:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/56f8dd524acd Merge Changeset: ceeef8652c08 Author: amurillo Date: 2016-08-19 12:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ceeef8652c08 Merge Changeset: baf6c0d9209f Author: amurillo Date: 2016-08-19 22:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/baf6c0d9209f Merge Changeset: 15b34ff488bd Author: kbarrett Date: 2016-08-14 21:19 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/15b34ff488bd 8155043: BitMap set operations assume clear bits beyond unaligned end Summary: Be more circumspect in handling of sets with unaligned sizes. Reviewed-by: stefank, jmasa ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp + test/native/utilities/test_bitMap_setops.cpp Changeset: 3ef0d42f4d51 Author: kbarrett Date: 2016-08-19 23:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3ef0d42f4d51 Merge Changeset: 64466ec652ed Author: ctornqvi Date: 2016-08-20 09:35 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/64466ec652ed 8164521: compiler/rangechecks/TestRangeCheckSmearing.java is missing @build for sun.hotspot.WhiteBox Reviewed-by: coleenp ! test/compiler/rangechecks/TestRangeCheckSmearing.java Changeset: 7f23e809f6cf Author: iveresov Date: 2016-08-15 14:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7f23e809f6cf 8163962: [JVMCI] integrate VarHandles Summary: add VarHandle support to JVMCI Reviewed-by: psandoz, iveresov Contributed-by: Doug Simon ! src/share/vm/jvmci/jvmciEnv.cpp Changeset: fefcad79cedf Author: aph Date: 2016-08-16 17:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fefcad79cedf 8164113: AArch64: follow-up the fix for 8161598 Reviewed-by: dlong ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp ! src/cpu/aarch64/vm/frame_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.hpp ! src/cpu/aarch64/vm/javaFrameAnchor_aarch64.hpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp ! src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp ! src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp Changeset: ef326749824a Author: dlong Date: 2016-08-16 09:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ef326749824a 8161598: Kitchensink fails: assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod/CompiledMethod Summary: skip unwalkable frames in Reviewed-by: fparain, coleenp, aph ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/javaFrameAnchor_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp Changeset: 60afc42d5013 Author: dlong Date: 2016-08-16 17:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/60afc42d5013 Merge Changeset: 6a8930622dc3 Author: thartmann Date: 2016-08-17 08:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6a8930622dc3 8164091: VM fails during startup with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" Summary: Don't throw java_lang_VirtualMachineError during VM initialization. Reviewed-by: zmajo, dlong, dholmes ! src/share/vm/oops/method.cpp ! test/compiler/startup/StartupOutput.java Changeset: 031f53ef620a Author: thartmann Date: 2016-08-17 06:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/031f53ef620a Merge Changeset: 1f1af771296a Author: vlivanov Date: 2016-08-17 22:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f1af771296a 8164103: C2: Broken cmpxchgb encoding on x86 Reviewed-by: kvn, shade, psandoz ! src/cpu/x86/vm/x86_64.ad Changeset: f7fab4512ba1 Author: neliasso Date: 2016-08-15 16:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f7fab4512ba1 8156659: assert(CodeCache::find_blob_unsafe(_pc) == _cb) failed: inconsistent Summary: Stackwalking from corrupt frame Reviewed-by: dlong, thartmann ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp Changeset: 19ff411141d1 Author: neliasso Date: 2016-08-17 22:34 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/19ff411141d1 Merge Changeset: f932a58df902 Author: iignatyev Date: 2016-08-18 11:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f932a58df902 8164035: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java failing with Agent JAR not found or no Agent-Class attribute Reviewed-by: kvn ! test/compiler/profiling/spectrapredefineclass/Agent.java ! test/compiler/profiling/spectrapredefineclass/Launcher.java ! test/compiler/profiling/spectrapredefineclass_classloaders/Agent.java ! test/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: c3f20f5f5876 Author: iveresov Date: 2016-08-19 14:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c3f20f5f5876 Merge ! test/compiler/profiling/spectrapredefineclass/Launcher.java ! test/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java ! test/compiler/startup/StartupOutput.java Changeset: 63d56d2b3435 Author: iveresov Date: 2016-08-19 18:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/63d56d2b3435 Merge Changeset: 5e7fdebf5132 Author: iveresov Date: 2016-08-21 06:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5e7fdebf5132 Merge Changeset: d0fbf661cc16 Author: dholmes Date: 2016-08-21 20:56 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d0fbf661cc16 8157907: Incorrect inclusion of atomic.hpp instead of atomic.inline.hpp Summary: Remove atomic.inline.hpp and move the contents back into atomic.hpp Reviewed-by: stefank, pliden, simonis ! src/cpu/aarch64/vm/vm_version_aarch64.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp + src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp - src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp + src/os_cpu/bsd_x86/vm/atomic_bsd_x86.hpp - src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp + src/os_cpu/bsd_zero/vm/atomic_bsd_zero.hpp - src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp + src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp - src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp ! src/os_cpu/linux_aarch64/vm/orderAccess_linux_aarch64.inline.hpp + src/os_cpu/linux_ppc/vm/atomic_linux_ppc.hpp - src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp + src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp - src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp + src/os_cpu/linux_zero/vm/atomic_linux_zero.hpp - src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp + src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp - src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp + src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp - src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp + src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp - src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/g1/collectionSetChooser.cpp ! src/share/vm/gc/g1/dirtyCardQueue.cpp ! src/share/vm/gc/g1/g1CardLiveData.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1EvacStats.inline.hpp ! src/share/vm/gc/g1/g1HotCardCache.cpp ! src/share/vm/gc/g1/g1MarkSweep.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc/g1/g1StringDedup.cpp ! src/share/vm/gc/g1/g1StringDedup.hpp ! src/share/vm/gc/g1/g1StringDedupQueue.cpp ! src/share/vm/gc/g1/g1StringDedupThread.cpp ! src/share/vm/gc/g1/heapRegion.cpp ! src/share/vm/gc/g1/heapRegion.inline.hpp ! src/share/vm/gc/g1/heapRegionRemSet.cpp ! src/share/vm/gc/g1/sparsePRT.cpp ! src/share/vm/gc/parallel/gcTaskThread.cpp ! src/share/vm/gc/parallel/mutableNUMASpace.cpp ! src/share/vm/gc/parallel/mutableSpace.cpp ! src/share/vm/gc/parallel/parMarkBitMap.cpp ! src/share/vm/gc/parallel/psCompactionManager.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/serial/defNewGeneration.cpp ! src/share/vm/gc/shared/cardTableRS.cpp ! src/share/vm/gc/shared/gcLocker.cpp ! src/share/vm/gc/shared/plab.inline.hpp ! src/share/vm/gc/shared/space.cpp ! src/share/vm/gc/shared/taskqueue.cpp ! src/share/vm/gc/shared/taskqueue.inline.hpp ! src/share/vm/gc/shared/workgroup.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/logging/logOutputList.cpp ! src/share/vm/logging/logOutputList.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/atomic.hpp - src/share/vm/runtime/atomic.inline.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/orderAccess.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.inline.hpp ! src/share/vm/services/mallocTracker.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/virtualMemoryTracker.cpp ! src/share/vm/shark/sharkRuntime.cpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/vmError.cpp Changeset: a558c122df17 Author: mlarsson Date: 2016-07-14 09:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a558c122df17 8061219: Implement unit-tests for UL Reviewed-by: coleenp, mockner, rprotacio ! src/share/vm/logging/logDecorations.hpp ! src/share/vm/logging/logOutputList.hpp + test/native/logging/logTestFixture.cpp + test/native/logging/logTestFixture.hpp + test/native/logging/logTestUtils.inline.hpp + test/native/logging/test_logConfiguration.cpp + test/native/logging/test_logDecorations.cpp + test/native/logging/test_logDecorators.cpp + test/native/logging/test_logFileOutput.cpp + test/native/logging/test_logLevel.cpp + test/native/logging/test_logOutputList.cpp + test/native/logging/test_logTag.cpp + test/native/logging/test_logTagLevelExpression.cpp + test/native/logging/test_logTagSet.cpp Changeset: d26c860f0a99 Author: sjohanss Date: 2016-08-22 16:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d26c860f0a99 8163413: gc/metaspace/TestMetaspacePerfCounters failure Reviewed-by: ehelin, dfazunen ! test/gc/metaspace/TestMetaspacePerfCounters.java Changeset: b463577dbb68 Author: rprotacio Date: 2016-08-22 11:06 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b463577dbb68 8163973: VM Anonymous classes should not call Class File Load Hooks Summary: Ensures CFLH's are not called for VM anonymous classes Reviewed-by: lfoltan, dholmes, coleenp, vlivanov, acorn ! src/share/vm/classfile/klassFactory.cpp Changeset: 8c8e9b96bd7c Author: rprotacio Date: 2016-08-22 15:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c8e9b96bd7c Merge Changeset: e3adb424b86e Author: ctornqvi Date: 2016-08-23 13:20 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3adb424b86e 8155964: Create a set of tests for verifying the Minimal VM Reviewed-by: gtriantafill, dholmes, lmesnik, cjplummer ! test/TEST.groups + test/runtime/MinimalVM/CDS.java + test/runtime/MinimalVM/CheckJNI.java + test/runtime/MinimalVM/Instrumentation.java + test/runtime/MinimalVM/JMX.java + test/runtime/MinimalVM/JVMTI.java + test/runtime/MinimalVM/NMT.java + test/runtime/MinimalVM/Xprof.java Changeset: 19a793d62419 Author: ctornqvi Date: 2016-08-23 17:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/19a793d62419 Merge Changeset: ff4b74f6fa40 Author: coleenp Date: 2016-08-23 13:44 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ff4b74f6fa40 8038797: JVMTI FollowReferences does not report roots reachable from nmethods Summary: Also follow nmethods found on the execution stack. Reviewed-by: dlong, mgerdin ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: b6e25862a8d2 Author: coleenp Date: 2016-08-23 19:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b6e25862a8d2 Merge Changeset: abeecea0351c Author: egahlin Date: 2016-08-23 19:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/abeecea0351c 8164523: Clean up metadata for event based tracing Reviewed-by: mlarsson, mgronlun ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc/g1/heapRegionTracer.cpp ! src/share/vm/gc/shared/allocTracer.cpp ! src/share/vm/gc/shared/gcTraceSend.cpp ! src/share/vm/gc/shared/objectCountEventSender.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/trace/traceevents.xml ! src/share/vm/trace/tracerelationdecls.xml ! src/share/vm/trace/tracetypes.xml Changeset: edc3be6aed36 Author: egahlin Date: 2016-08-23 20:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/edc3be6aed36 Merge Changeset: 293e4aad6d35 Author: egahlin Date: 2016-08-23 22:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/293e4aad6d35 Merge Changeset: 03762a0cf7e1 Author: ctornqvi Date: 2016-08-23 21:49 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/03762a0cf7e1 8163146: Remove os::check_heap on Windows Reviewed-by: gtriantafill, coleenp, stuefe ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/vmThread.cpp ! test/gc/arguments/TestVerifyBeforeAndAfterGCFlags.java Changeset: 162138df46f7 Author: rehn Date: 2016-08-24 20:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/162138df46f7 8164208: Update tests with redefine classes UL options and tags? Reviewed-by: coleenp, gtriantafill ! test/runtime/RedefineObject/TestRedefineObject.java ! test/runtime/RedefineTests/RedefineRunningMethods.java ! test/runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java Changeset: a8b9f9ed30ff Author: dholmes Date: 2016-08-24 19:54 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a8b9f9ed30ff 8157904: Atomic::cmpxchg for jbyte is missing a fence on initial failure Reviewed-by: simonis, aph, kbarrett ! src/share/vm/runtime/atomic.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 750d4378c4a6 Author: amurillo Date: 2016-08-26 10:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/750d4378c4a6 Merge - src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp - src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp - src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp - src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp - src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp - src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp - src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp - src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp - src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp - src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp - src/share/vm/runtime/atomic.inline.hpp - test/testlibrary/ClassFileInstaller.java - test/testlibrary/RedefineClassHelper.java - test/testlibrary/jdk/test/lib/AllocationHelper.java - test/testlibrary/jdk/test/lib/Asserts.java - test/testlibrary/jdk/test/lib/BuildHelper.java - test/testlibrary/jdk/test/lib/ByteCodeLoader.java - test/testlibrary/jdk/test/lib/DynamicVMOption.java - test/testlibrary/jdk/test/lib/ExitCode.java - test/testlibrary/jdk/test/lib/FileInstaller.java - test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java - test/testlibrary/jdk/test/lib/InMemoryJavaCompiler.java - test/testlibrary/jdk/test/lib/InfiniteLoop.java - test/testlibrary/jdk/test/lib/InputArguments.java - test/testlibrary/jdk/test/lib/JDKToolFinder.java - test/testlibrary/jdk/test/lib/JDKToolLauncher.java - test/testlibrary/jdk/test/lib/OutputAnalyzer.java - test/testlibrary/jdk/test/lib/OutputBuffer.java - test/testlibrary/jdk/test/lib/Pair.java - test/testlibrary/jdk/test/lib/Platform.java - test/testlibrary/jdk/test/lib/ProcessTools.java - test/testlibrary/jdk/test/lib/StreamPumper.java - test/testlibrary/jdk/test/lib/TimeLimitedRunner.java - test/testlibrary/jdk/test/lib/Triple.java - test/testlibrary/jdk/test/lib/Utils.java - test/testlibrary/jdk/test/lib/cli/CPUSpecificCommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/CommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/predicate/AndPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/CPUSpecificPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/NotPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/OrPredicate.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutor.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutorException.java - test/testlibrary/jdk/test/lib/dcmd/FileJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JMXExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/MainClassJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/PidJcmdExecutor.java - test/testlibrary/jdk/test/lib/dtrace/DtraceResultsAnalyzer.java - test/testlibrary/jdk/test/lib/dtrace/DtraceRunner.java Changeset: c1471e013d89 Author: amurillo Date: 2016-08-31 09:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c1471e013d89 Merge ! test/runtime/Unsafe/NestedUnsafe.java Changeset: 3b1c4562953d Author: lana Date: 2016-09-02 02:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3b1c4562953d Merge - src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp - src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp - src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp - src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp - src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp - src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp - src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp - src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp - src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp - src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp - src/share/vm/runtime/atomic.inline.hpp - test/testlibrary/ClassFileInstaller.java - test/testlibrary/RedefineClassHelper.java - test/testlibrary/jdk/test/lib/AllocationHelper.java - test/testlibrary/jdk/test/lib/Asserts.java - test/testlibrary/jdk/test/lib/BuildHelper.java - test/testlibrary/jdk/test/lib/ByteCodeLoader.java - test/testlibrary/jdk/test/lib/DynamicVMOption.java - test/testlibrary/jdk/test/lib/ExitCode.java - test/testlibrary/jdk/test/lib/FileInstaller.java - test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java - test/testlibrary/jdk/test/lib/InMemoryJavaCompiler.java - test/testlibrary/jdk/test/lib/InfiniteLoop.java - test/testlibrary/jdk/test/lib/InputArguments.java - test/testlibrary/jdk/test/lib/JDKToolFinder.java - test/testlibrary/jdk/test/lib/JDKToolLauncher.java - test/testlibrary/jdk/test/lib/OutputAnalyzer.java - test/testlibrary/jdk/test/lib/OutputBuffer.java - test/testlibrary/jdk/test/lib/Pair.java - test/testlibrary/jdk/test/lib/Platform.java - test/testlibrary/jdk/test/lib/ProcessTools.java - test/testlibrary/jdk/test/lib/StreamPumper.java - test/testlibrary/jdk/test/lib/TimeLimitedRunner.java - test/testlibrary/jdk/test/lib/Triple.java - test/testlibrary/jdk/test/lib/Utils.java - test/testlibrary/jdk/test/lib/cli/CPUSpecificCommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/CommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/predicate/AndPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/CPUSpecificPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/NotPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/OrPredicate.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutor.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutorException.java - test/testlibrary/jdk/test/lib/dcmd/FileJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JMXExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/MainClassJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/PidJcmdExecutor.java - test/testlibrary/jdk/test/lib/dtrace/DtraceResultsAnalyzer.java - test/testlibrary/jdk/test/lib/dtrace/DtraceRunner.java Changeset: a20da289f646 Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a20da289f646 Added tag jdk-9+135 for changeset 3b1c4562953d ! .hgtags Changeset: 909fa4cc8395 Author: mchung Date: 2016-09-08 17:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/909fa4cc8395 Merge ! .hgtags ! make/test/JtregNative.gmk ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/jvmci/jvmciEnv.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/trace/tracetypes.xml ! test/compiler/c2/Test5057225.java ! test/compiler/c2/Test6603011.java ! test/compiler/c2/Test6800154.java ! test/compiler/c2/Test6805724.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2NativeTest.java ! test/compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java ! test/compiler/codegen/Test6823354.java ! test/compiler/codegen/Test6896617.java ! test/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java ! test/compiler/jsr292/NonInlinedCall/GCTest.java ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java ! test/compiler/jsr292/NonInlinedCall/RedefineTest.java ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java ! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/CollectCountersTest.java ! test/compiler/jvmci/compilerToVM/DebugOutputTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java ! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java ! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java ! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java ! test/compiler/jvmci/compilerToVM/GetImplementorTest.java ! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java ! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java ! test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java ! test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java ! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java ! test/compiler/jvmci/compilerToVM/GetSymbolTest.java ! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java ! test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java ! test/compiler/jvmci/compilerToVM/IsMatureTest.java ! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupTypeTest.java ! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java ! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java ! test/compiler/jvmci/errors/TestInvalidCompilationResult.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/compiler/jvmci/events/JvmciShutdownEventTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/compiler/runtime/Test8010927.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/uncommontrap/TestUnstableIfTrap.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/compiler/unsafe/UnsafeRaw.java ! test/gc/TestSmallHeap.java ! test/gc/arguments/TestG1HeapRegionSize.java ! test/gc/arguments/TestTargetSurvivorRatioFlag.java ! test/gc/arguments/TestUseCompressedOopsErgo.java ! test/gc/g1/TestHumongousShrinkHeap.java ! test/gc/g1/TestLargePageUseForAuxMemory.java ! test/gc/g1/TestRemsetLogging.java ! test/gc/g1/TestRemsetLoggingPerRegion.java ! test/gc/g1/TestRemsetLoggingThreads.java ! test/gc/g1/TestShrinkAuxiliaryData.java ! test/gc/g1/TestShrinkAuxiliaryData00.java ! test/gc/g1/TestShrinkAuxiliaryData05.java ! test/gc/g1/TestShrinkAuxiliaryData10.java ! test/gc/g1/TestShrinkAuxiliaryData15.java ! test/gc/g1/TestShrinkAuxiliaryData20.java ! test/gc/g1/TestShrinkAuxiliaryData25.java ! test/gc/g1/TestShrinkAuxiliaryData30.java ! test/gc/g1/TestShrinkDefragmentedHeap.java ! test/gc/g1/TestStringDeduplicationAgeThreshold.java ! test/gc/g1/TestStringDeduplicationFullGC.java ! test/gc/g1/TestStringDeduplicationInterned.java ! test/gc/g1/TestStringDeduplicationPrintOptions.java ! test/gc/g1/TestStringDeduplicationTableRehash.java ! test/gc/g1/TestStringDeduplicationTableResize.java ! test/gc/g1/TestStringDeduplicationTools.java ! test/gc/g1/TestStringDeduplicationYoungGC.java ! test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java ! test/gc/metaspace/TestMetaspacePerfCounters.java ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java ! test/gc/parallel/TestDynShrinkHeap.java ! test/gc/survivorAlignment/TestAllocationInEden.java ! test/gc/survivorAlignment/TestPromotionFromEdenToTenured.java ! test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterFullGC.java ! test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java ! test/gc/survivorAlignment/TestPromotionToSurvivor.java ! test/runtime/8026365/InvokeSpecialAnonTest.java ! test/runtime/BadObjectClass/BootstrapRedefine.java ! test/runtime/BootClassAppendProp/BootClassPathAppendProp.java ! test/runtime/ClassFile/UnsupportedClassFileVersion.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/ErrorHandling/CreateCoredumpOnCrash.java ! test/runtime/ErrorHandling/ProblematicFrameTest.java ! test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java ! test/runtime/NMT/BaselineWithParameter.java ! test/runtime/NMT/JcmdBaselineDetail.java ! test/runtime/NMT/JcmdScale.java ! test/runtime/NMT/JcmdScaleDetail.java ! test/runtime/NMT/JcmdSummaryDiff.java ! test/runtime/NMT/JcmdWithNMTDisabled.java ! test/runtime/NMT/MallocRoundingReportTest.java ! test/runtime/NMT/MallocTestType.java ! test/runtime/NMT/MallocTrackingVerify.java ! test/runtime/NMT/ReleaseNoCommit.java ! test/runtime/NMT/ShutdownTwice.java ! test/runtime/NMT/SummaryAfterShutdown.java ! test/runtime/NMT/SummarySanityCheck.java ! test/runtime/NMT/ThreadedMallocTestType.java ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/runtime/RedefineTests/RedefineAnnotations.java ! test/runtime/RedefineTests/RedefineFinalizer.java ! test/runtime/RedefineTests/RedefineRunningMethods.java ! test/runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java ! test/runtime/ReservedStack/ReservedStackTest.java ! test/runtime/SharedArchiveFile/BootAppendTests.java ! test/runtime/SharedArchiveFile/DumpSymbolAndStringTable.java ! test/runtime/SharedArchiveFile/LimitSharedSizes.java ! test/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java ! test/runtime/SharedArchiveFile/SASymbolTableTest.java ! test/runtime/SharedArchiveFile/SharedArchiveFile.java ! test/runtime/SharedArchiveFile/SharedStrings.java ! test/runtime/Thread/ThreadPriorities.java ! test/runtime/Unsafe/AllocateInstance.java ! test/runtime/Unsafe/AllocateMemory.java ! test/runtime/Unsafe/CopyMemory.java ! test/runtime/Unsafe/DefineClass.java ! test/runtime/Unsafe/FieldOffset.java ! test/runtime/Unsafe/GetField.java ! test/runtime/Unsafe/GetPutAddress.java ! test/runtime/Unsafe/GetPutBoolean.java ! test/runtime/Unsafe/GetPutByte.java ! test/runtime/Unsafe/GetPutChar.java ! test/runtime/Unsafe/GetPutDouble.java ! test/runtime/Unsafe/GetPutFloat.java ! test/runtime/Unsafe/GetPutInt.java ! test/runtime/Unsafe/GetPutLong.java ! test/runtime/Unsafe/GetPutObject.java ! test/runtime/Unsafe/GetPutShort.java ! test/runtime/Unsafe/GetUncompressedObject.java ! test/runtime/Unsafe/PageSize.java ! test/runtime/Unsafe/RangeCheck.java ! test/runtime/Unsafe/Reallocate.java ! test/runtime/Unsafe/SetMemory.java ! test/runtime/Unsafe/ThrowException.java ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/runtime/logging/ModulesTest.java ! test/runtime/modules/AccModuleTest.java ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodDiffCL_Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_Umod.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_Umod.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod_UmodUpkg.java ! test/runtime/modules/AccessCheckAllUnnamed.java ! test/runtime/modules/AccessCheckExp.java ! test/runtime/modules/AccessCheckRead.java ! test/runtime/modules/AccessCheckSuper.java ! test/runtime/modules/AccessCheckUnnamed.java ! test/runtime/modules/AccessCheckWorks.java ! test/runtime/modules/ExportTwice.java ! test/runtime/modules/IgnoreModulePropertiesTest.java ! test/runtime/modules/JVMAddModuleExportToAllUnnamed.java ! test/runtime/modules/JVMAddModuleExports.java ! test/runtime/modules/JVMAddModuleExportsToAll.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMAddReadsModule.java ! test/runtime/modules/JVMCanReadModule.java ! test/runtime/modules/JVMDefineModule.java ! test/runtime/modules/JVMIsExportedToModule.java ! test/runtime/modules/LoadUnloadModuleStress.java ! test/runtime/modules/ModuleOptionsTest.java ! test/runtime/modules/ModuleStress/ExportModuleStressTest.java ! test/runtime/modules/ModuleStress/ModuleStressGC.java ! test/runtime/modules/PatchModule/PatchModule2Dirs.java ! test/runtime/modules/PatchModule/PatchModuleCDS.java ! test/runtime/modules/PatchModule/PatchModuleDupJavaBase.java ! test/runtime/modules/PatchModule/PatchModuleDupModule.java ! test/runtime/modules/PatchModule/PatchModuleJavaBase.java ! test/runtime/modules/PatchModule/PatchModuleTest.java ! test/runtime/modules/PatchModule/PatchModuleTestJar.java ! test/runtime/modules/PatchModule/PatchModuleTestJarDir.java ! test/runtime/modules/PatchModule/PatchModuleTraceCL.java ! test/runtime/modules/Visibility/PatchModuleVisibility.java ! test/runtime/modules/Visibility/XbootcpNoVisibility.java ! test/runtime/modules/Visibility/XbootcpVisibility.java ! test/runtime/verifier/OverriderMsg.java ! test/runtime/verifier/TestANewArray.java ! test/runtime/verifier/TestMultiANewArray.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/attach/AttachWithStalePidFile.java ! test/serviceability/dcmd/compiler/CodeCacheTest.java ! test/serviceability/dcmd/compiler/CodelistTest.java ! test/serviceability/dcmd/compiler/CompilerQueueTest.java ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java ! test/serviceability/dcmd/jvmti/DataDumpDcmdTest.java ! test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java ! test/serviceability/sa/jmap-hashcode/Test8028623.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary_tests/RedefineClassTest.java ! test/testlibrary_tests/ctw/ClassesDirTest.java ! test/testlibrary_tests/ctw/ClassesListTest.java ! test/testlibrary_tests/ctw/JarDirTest.java ! test/testlibrary_tests/ctw/JarsTest.java ! test/testlibrary_tests/whitebox/vm_flags/BooleanTest.java ! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java ! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java ! test/testlibrary_tests/whitebox/vm_flags/SizeTTest.java ! test/testlibrary_tests/whitebox/vm_flags/StringTest.java ! test/testlibrary_tests/whitebox/vm_flags/Uint64Test.java ! test/testlibrary_tests/whitebox/vm_flags/UintxTest.java From mandy.chung at oracle.com Fri Sep 9 00:45:11 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:45:11 +0000 Subject: hg: jigsaw/jake/jaxp: 7 new changesets Message-ID: <201609090045.u890jCSe001255@aojmv0008.oracle.com> Changeset: 2bb277192648 Author: mchung Date: 2016-08-30 17:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/2bb277192648 8160851: Remove old launcher module-related options Reviewed-by: jjg, alanb ! test/javax/xml/jaxp/module/ServiceProviderTest/BasicModularXMLParserTest.java Changeset: 4561cb852f38 Author: joehw Date: 2016-08-31 14:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4561cb852f38 8162431: CatalogUriResolver with circular/self referencing catalog file is not throwing CatalogException as expected Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogReader.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java ! src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java ! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java + test/javax/xml/jaxp/unittest/catalog/catalogReferCircle-itself.xml + test/javax/xml/jaxp/unittest/catalog/catalogReferCircle-left.xml + test/javax/xml/jaxp/unittest/catalog/catalogReferCircle-right.xml Changeset: 68d7d15cf44a Author: aefimov Date: 2016-09-01 17:12 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/68d7d15cf44a 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message Reviewed-by: joehw, clanger ! test/ProblemList.txt ! test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java ! test/javax/xml/jaxp/unittest/common/ValidationWarningsTest.java ! test/javax/xml/jaxp/unittest/common/WarningsTestBase.java Changeset: 1defcc790c15 Author: joehw Date: 2016-09-01 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1defcc790c15 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present Reviewed-by: aefimov, lancea, dfuchs ! src/java.xml/share/classes/jdk/xml/internal/JdkXmlFeatures.java ! test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java Changeset: f695240370c7 Author: lana Date: 2016-09-02 02:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f695240370c7 Merge Changeset: 38f97dc17141 Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/38f97dc17141 Added tag jdk-9+135 for changeset f695240370c7 ! .hgtags Changeset: 7352361f6243 Author: mchung Date: 2016-09-08 17:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/7352361f6243 Merge From mandy.chung at oracle.com Fri Sep 9 00:45:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:45:15 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201609090045.u890jFZ5001306@aojmv0008.oracle.com> Changeset: 09ec13a99f50 Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/09ec13a99f50 Added tag jdk-9+135 for changeset 22631824f551 ! .hgtags Changeset: 09dff41baed2 Author: mchung Date: 2016-09-08 17:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/09dff41baed2 Merge From mandy.chung at oracle.com Fri Sep 9 00:45:34 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:45:34 +0000 Subject: hg: jigsaw/jake/jdk: 73 new changesets Message-ID: <201609090045.u890jaCV001429@aojmv0008.oracle.com> Changeset: 5e0ff917eab1 Author: amlu Date: 2016-08-30 09:31 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5e0ff917eab1 8163934: Remove intermittent key from java/lang/ProcessBuilder/Zombies.java Reviewed-by: darcy ! test/java/lang/ProcessBuilder/Zombies.java Changeset: 7f730240145e Author: amlu Date: 2016-08-30 09:36 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f730240145e 8164545: Mark java/net/URLPermission/nstest/lookup.sh as intermittently failing Reviewed-by: dfuchs ! test/java/net/URLPermission/nstest/lookup.sh Changeset: f7026b128452 Author: okutsu Date: 2016-08-30 14:16 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f7026b128452 8157792: After Integrating tzdata2016d the test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and "Asia/Qyzylorda" Timezones Reviewed-by: peytoia ! test/sun/util/calendar/zi/TestZoneInfo310.java ! test/sun/util/calendar/zi/Zoneinfo.java Changeset: 556549260289 Author: igerasim Date: 2016-08-30 15:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/556549260289 6474807: (smartcardio) CardTerminal.connect() throws CardException instead of CardNotPresentException Reviewed-by: valeriep ! src/java.smartcardio/share/classes/sun/security/smartcardio/TerminalImpl.java Changeset: d55a21a736b7 Author: shurailine Date: 2016-08-30 14:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d55a21a736b7 8164859: Fix module dependences in java/text tests Reviewed-by: naoto ! test/java/text/Bidi/BidiConformance.java ! test/java/text/Bidi/BidiEmbeddingTest.java ! test/java/text/Bidi/Bug7042148.java ! test/java/text/Bidi/Bug7051769.java ! test/java/text/BreakIterator/NewVSOld_th_TH.java ! test/java/text/Collator/APITest.java ! test/java/text/Collator/CollationKeyTest.java ! test/java/text/Collator/DanishTest.java ! test/java/text/Collator/FinnishTest.java ! test/java/text/Collator/FrenchTest.java ! test/java/text/Collator/G7Test.java ! test/java/text/Collator/JapaneseTest.java ! test/java/text/Collator/KoreanTest.java ! test/java/text/Collator/Regression.java ! test/java/text/Collator/ThaiTest.java ! test/java/text/Collator/TurkishTest.java ! test/java/text/Collator/VietnameseTest.java ! test/java/text/Format/DateFormat/Bug4823811.java ! test/java/text/Format/DateFormat/Bug6683975.java ! test/java/text/Format/DateFormat/Bug8139572.java ! test/java/text/Format/DateFormat/ContextMonthNamesTest.java ! test/java/text/Format/DateFormat/DateFormatTest.java ! test/java/text/Format/DateFormat/LocaleDateFormats.java ! test/java/text/Format/DateFormat/NonGregorianFormatTest.java ! test/java/text/Format/DateFormat/bug4117335.java ! test/java/text/Format/MessageFormat/LargeMessageFormat.java ! test/java/text/Format/NumberFormat/Bug8132125.java ! test/java/text/Format/NumberFormat/CurrencyFormat.java ! test/java/text/Format/NumberFormat/IntlTestNumberFormatAPI.java ! test/java/text/Format/NumberFormat/NumberRegression.java ! test/java/text/Format/NumberFormat/NumberTest.java Changeset: ea6b16200114 Author: mchung Date: 2016-08-30 17:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ea6b16200114 8160851: Remove old launcher module-related options Reviewed-by: jjg, alanb ! src/java.base/share/native/libjli/java.c Changeset: 000459da7aa8 Author: redestad Date: 2016-08-31 14:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/000459da7aa8 8164858: Enable build-time use of java.lang.invoke resolve tracing Reviewed-by: erikj, vlivanov ! make/GenerateClasslist.gmk ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/tools/jlink/plugins/GenerateJLIClassesPluginTest.java Changeset: b46447382c84 Author: ssahoo Date: 2016-08-31 08:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b46447382c84 8015595: Test sun/security/krb5/auto/Unreachable.java fails with Timeout error Summary: Unreachable.java was getting timeout due to PortUnreachableException was not thrown Reviewed-by: weijun ! test/ProblemList.txt ! test/sun/security/krb5/auto/Unreachable.java - test/sun/security/krb5/auto/unreachable.krb5.conf Changeset: 077a8cd3df68 Author: ssahoo Date: 2016-08-31 08:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/077a8cd3df68 8164922: sun/security/provider/SecureRandom/AutoReseed.java failed with timeout in Ubuntu Linux. Summary: The test timeout waiting to get seed in an exhausted Linux platform. Reviewed-by: weijun ! test/sun/security/provider/SecureRandom/AutoReseed.java Changeset: 6f390eafc676 Author: shurailine Date: 2016-08-31 09:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6f390eafc676 8164982: Fix legal notices in java/lang, java/net, java/util tests. Reviewed-by: darcy, iris ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/Class/GetPackageTest.java ! test/java/lang/ClassLoader/GetSystemPackage.java ! test/java/lang/ClassLoader/deadlock/GetResource.java ! test/java/lang/ProcessBuilder/CloseRace.java ! test/java/lang/ProcessBuilder/PipelineTest.java ! test/java/lang/StackWalker/CountLocalSlots.java ! test/java/lang/StackWalker/LocalsAndOperands.java ! test/java/lang/StackWalker/LocalsCrash.java ! test/java/lang/String/concat/CompactStringsInitialCoder.java ! test/java/lang/String/concat/StringConcatFactoryEmptyMethods.java ! test/java/lang/String/concat/WithSecurityManager.java ! test/java/lang/Thread/ThreadStateController.java ! test/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java ! test/java/lang/instrument/NMTHelper.java ! test/java/lang/invoke/6987555/Test6987555.java ! test/java/lang/invoke/6991596/Test6991596.java ! test/java/lang/invoke/6998541/Test6998541.java ! test/java/lang/invoke/7087570/Test7087570.java ! test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/7196190/ClassForNameTest.java ! test/java/lang/invoke/7196190/GetUnsafeTest.java ! test/java/lang/invoke/8009222/Test8009222.java ! test/java/lang/invoke/8022701/BogoLoader.java ! test/java/lang/invoke/8022701/InvokeSeveralWays.java ! test/java/lang/invoke/8022701/Invoker.java ! test/java/lang/invoke/8022701/MHIllegalAccess.java ! test/java/lang/invoke/8022701/MethodSupplier.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/CallStaticInitOrder.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/Test.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/p1/T2.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/p2/T3.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeString.java ! test/java/lang/invoke/accessProtectedSuper/BogoLoader.java ! test/java/lang/invoke/accessProtectedSuper/MethodInvoker.java ! test/java/lang/invoke/accessProtectedSuper/Test.java ! test/java/lang/invoke/accessProtectedSuper/anotherpkg/MethodSupplierOuter.java ! test/java/lang/management/GarbageCollectorMXBean/GcInfoCompositeType.java ! test/java/net/Inet4Address/textToNumericFormat.java ! test/java/net/ProxySelector/B8035158.java ! test/java/net/URLClassLoader/definePackage/SplitPackage.java ! test/java/net/URLPermission/nstest/LookupTest.java ! test/java/net/httpclient/BasicAuthTest.java ! test/java/net/httpclient/HeadersTest1.java ! test/java/net/httpclient/ImmutableHeaders.java ! test/java/net/httpclient/security/Driver.java ! test/java/net/httpclient/security/Security.java ! test/java/util/Arrays/Correct.java ! test/java/util/Map/FunctionalCMEs.java ! test/java/util/Objects/CheckIndex.java ! test/java/util/concurrent/FutureTask/NegativeTimeout.java ! test/java/util/logging/Logger/entering/LoggerEnteringWithParams.java ! test/java/util/logging/XMLFormatterDate.java ! test/java/util/regex/PatternStreamTest.java ! test/java/util/zip/TestCRC32.java ! test/java/util/zip/TestCRC32C.java ! test/java/util/zip/ZipFile/TestZipFile.java Changeset: f754ada66386 Author: dsamersoff Date: 2016-08-18 13:19 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f754ada66386 8157236: attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file Summary: Add more diagnostic to attach code Reviewed-by: dholmes, alanb ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Changeset: b61ee43309f3 Author: ctornqvi Date: 2016-08-19 10:09 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b61ee43309f3 8157957: ClassNotFoundException: jdk.test.lib.JDKToolFinder Reviewed-by: coleenp, gtriantafill, mseledtsov, iignatyev, dholmes, dsamersoff ! test/com/sun/jdi/SunBootClassPathEmptyTest.java ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/java/lang/ProcessHandle/Basic.java ! test/java/lang/ProcessHandle/InfoTest.java ! test/java/lang/ProcessHandle/OnExitTest.java ! test/java/lang/ProcessHandle/TreeTest.java ! test/java/lang/ref/CleanerTest.java ! test/java/security/SecureRandom/DrbgParametersSpec.java ! test/jdk/internal/ref/Cleaner/ExitOnThrow.java ! test/lib/testlibrary/jdk/testlibrary/Asserts.java ! test/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java ! test/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/OutputBuffer.java ! test/lib/testlibrary/jdk/testlibrary/Platform.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/lib/testlibrary/jdk/testlibrary/StreamPumper.java ! test/lib/testlibrary/jdk/testlibrary/Utils.java ! test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java ! test/sun/misc/SunMiscSignalTest.java ! test/sun/security/tools/jarsigner/AltProvider.java ! test/sun/tools/jhsdb/BasicLauncherTest.java ! test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java ! test/sun/tools/jinfo/JInfoTest.java ! test/sun/tools/jmap/BasicJMapTest.java ! test/sun/tools/jps/TestJpsSanity.java ! test/sun/tools/jstack/DeadlockDetectionTest.java ! test/tools/jar/multiRelease/Basic.java Changeset: 8dd36c04cfaf Author: amurillo Date: 2016-08-19 12:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8dd36c04cfaf Merge Changeset: 88b20e3124c9 Author: ctornqvi Date: 2016-08-20 09:36 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88b20e3124c9 8164520: java/lang/ProcessHandle/Basic.java is missing @library tag Reviewed-by: coleenp ! test/java/lang/ProcessHandle/Basic.java Changeset: 5d5653c5bcab Author: dsamersoff Date: 2016-08-22 21:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5d5653c5bcab 8162530: src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly Summary: Exceptions are checked after calling NewStringUTF Reviewed-by: dholmes, sla Contributed-by: amit.sapre at oracle.com ! src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c Changeset: fff545bf536f Author: rehn Date: 2016-08-24 20:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fff545bf536f 8164208: Update tests with redefine classes UL options and tags? Reviewed-by: coleenp, gtriantafill ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh ! test/java/lang/instrument/RetransformBigClass.sh Changeset: 5f9f12b3024f Author: rehn Date: 2016-08-24 20:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f9f12b3024f 8158628: test/java/lang/instrument/NativeMethodPrefixAgent.java: Error occurred during initialization of VM: Failed to start tracing backend. Reviewed-by: sla, gtriantafill ! test/java/lang/instrument/NativeMethodPrefixAgent.java Changeset: 6124931a770f Author: amurillo Date: 2016-08-26 10:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6124931a770f Merge Changeset: 80f8d74959a0 Author: amurillo Date: 2016-08-31 09:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/80f8d74959a0 Merge - make/data/cryptopolicy/limited/default_local.policy - make/data/cryptopolicy/limited/exempt_local.policy - make/data/cryptopolicy/unlimited/default_US_export.policy - make/data/cryptopolicy/unlimited/default_local.policy - make/gendata/GendataPolicyJars.gmk - test/sun/security/krb5/auto/unreachable.krb5.conf Changeset: 85acda36fccb Author: amurillo Date: 2016-08-31 13:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/85acda36fccb Merge Changeset: 591a6dddaf28 Author: henryjen Date: 2016-08-31 11:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/591a6dddaf28 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c Reviewed-by: ksrini ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h Changeset: 02e6e285b1f7 Author: mchung Date: 2016-08-31 15:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02e6e285b1f7 8165180: Provide a shared secret to access non-public ServerSocket constructor Reviewed-by: chegar ! src/java.base/share/classes/java/net/ServerSocket.java + src/java.base/share/classes/jdk/internal/misc/JavaNetSocketAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java Changeset: fe9b221a269d Author: rhalade Date: 2016-08-31 16:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fe9b221a269d 8164229: Redundant "sun/net/www/protocol/https" tests in jdk_security3 group Reviewed-by: chegar ! test/TEST.groups Changeset: bab6edbd731b Author: jlahoda Date: 2016-09-01 10:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bab6edbd731b 8131023: JShell: System.in does not work Summary: Read prompt lentgh directly from the terminal Reviewed-by: rfield ! src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java Changeset: f7eb17f55377 Author: vtewari Date: 2016-09-01 15:02 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f7eb17f55377 8164609: javax/management/remote/mandatory/notif/DeadListenerTest.java fails with Assertion Error Summary: Increased test timeout to ensure test case gets all notifications. Reviewed-by: dholmes Contributed-by: amit.sapre at oracle.com ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java Changeset: 1c28399f1b50 Author: coffeys Date: 2016-09-01 11:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c28399f1b50 8164846: CertificateException missing cause of underlying exception Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! test/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java Changeset: c07be59d7160 Author: azvegint Date: 2016-08-16 22:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c07be59d7160 8155691: Update GIFlib library to the latest up-to-date Reviewed-by: serb ! src/java.desktop/share/native/libsplashscreen/giflib/dgif_lib.c ! src/java.desktop/share/native/libsplashscreen/giflib/gif_lib.h ! src/java.desktop/share/native/libsplashscreen/giflib/gifalloc.c + src/java.desktop/share/native/libsplashscreen/giflib/openbsd-reallocarray.c Changeset: cc9d1ec8fd5f Author: serb Date: 2016-08-16 23:07 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cc9d1ec8fd5f 8159898: Negative array size in java/beans/Introspector/Test8027905.java Reviewed-by: alexsch, yan ! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java ! test/java/beans/Introspector/Test8027905.java Changeset: b209cf7b5b91 Author: aniyogi Date: 2016-08-17 14:42 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b209cf7b5b91 8163169: [PIT][TEST_BUG] fix to JDK-8161470 doesn't work Reviewed-by: alexsch, rchamyal ! test/javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java Changeset: acb15b493fd3 Author: rchamyal Date: 2016-08-17 14:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/acb15b493fd3 8161913: [PIT] java/awt/Window/8159168/SetShapeTest.java mostly fails Reviewed-by: alexsch, aniyogi Contributed-by: rajeev.chamyal at oracle.com ! test/java/awt/Window/8159168/SetShapeTest.java Changeset: 9f38d4f86e3d Author: psadhukhan Date: 2016-08-18 10:46 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9f38d4f86e3d 8164205: [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile Reviewed-by: prr ! test/javax/print/attribute/ServiceDlgPageRangeTest.java Changeset: acbf6dae58cf Author: jdv Date: 2016-08-19 12:22 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/acbf6dae58cf 8163258: Getting NullPointerException from ImageIO.getReaderWriterInfo due to failure to check for null Reviewed-by: prr, psadhukhan ! src/java.desktop/share/classes/javax/imageio/ImageIO.java + test/javax/imageio/GetReaderWriterInfoNullTest.java Changeset: 82d35714476e Author: alexsch Date: 2016-08-19 16:48 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/82d35714476e 8151303: [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it 8156182: [macosx] HiDPI/Retina icons do not work for disabled JButton/JMenuItem etc. Reviewed-by: flar, prr ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/share/classes/javax/swing/GrayFilter.java ! src/java.desktop/share/classes/sun/awt/image/MultiResolutionCachedImage.java ! src/java.desktop/share/classes/sun/awt/image/MultiResolutionToolkitImage.java + test/java/awt/image/MultiResolutionImage/MultiResolutionDisabledImageTest.java + test/javax/swing/JButton/8151303/PressedIconTest.java Changeset: 0e34c2d67363 Author: serb Date: 2016-08-20 18:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0e34c2d67363 8148109: [SWT] Provide a supported mechanism to use EmbeddedFrame Reviewed-by: alanb, prr ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt/mapfile-vers-linux ! make/mapfiles/libawt_xawt/mapfile-vers ! src/java.desktop/macosx/native/libawt_lwawt/awt/awt_DrawingSurface.m ! src/java.desktop/macosx/native/libjawt/jawt.m ! src/java.desktop/share/native/include/jawt.h ! src/java.desktop/unix/native/common/awt/awt_DrawingSurface.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_DrawingSurface.c ! src/java.desktop/unix/native/libjawt/jawt.c ! src/java.desktop/windows/native/libawt/windows/awt_DrawingSurface.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DrawingSurface.h ! src/java.desktop/windows/native/libjawt/jawt.cpp Changeset: e32729a8e1d8 Author: serb Date: 2016-08-22 01:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e32729a8e1d8 8164104: Cleanup of javaclient related mapfiles Reviewed-by: prr ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt/mapfile-vers ! make/mapfiles/libawt/mapfile-vers-linux ! make/mapfiles/libawt_headless/mapfile-vers ! make/mapfiles/libawt_xawt/mapfile-vers ! make/mapfiles/libjawt/mapfile-vers ! make/mapfiles/libjpeg/mapfile-vers ! make/mapfiles/libjsound/mapfile-vers ! make/mapfiles/libjsoundalsa/mapfile-vers ! make/mapfiles/libsplashscreen/mapfile-vers Changeset: 1b69905bd882 Author: rchamyal Date: 2016-08-22 14:41 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b69905bd882 8163160: [PIT][TEST_BUG] Some issues in java/awt/image/multiresolution/MultiResolutionIcon/IconTest.java Reviewed-by: serb, yan Contributed-by: rajeev.chamyal at oracle.com ! test/java/awt/image/multiresolution/MultiResolutionIcon/IconTest.java Changeset: c71e15b5a016 Author: mhalder Date: 2016-08-22 18:23 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c71e15b5a016 8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null Reviewed-by: mcherkas, serb Contributed-by: manajit.halder at oracle.com ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java + test/java/awt/dnd/URLDragTest/DragLinkFromBrowser.java Changeset: 1c3ef7e04a28 Author: prr Date: 2016-08-22 10:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c3ef7e04a28 8145901: Printed content is overlapping. Reviewed-by: serb, psadhukhan ! src/java.desktop/share/native/libfontmanager/HBShaper.c ! src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc ! src/java.desktop/share/native/libfontmanager/hb-jdk.h Changeset: 64e7af0827e4 Author: ddehaven Date: 2016-08-22 10:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64e7af0827e4 Merge - src/java.base/share/classes/java/lang/reflect/AbstractClassLoaderValue.java - src/java.base/share/classes/java/lang/reflect/ClassLoaderValue.java - test/java/lang/reflect/ClassLoaderValue/Driver.java - test/java/lang/reflect/ClassLoaderValue/java.base/java/lang/reflect/ClassLoaderValueTest.java Changeset: 2193be826227 Author: psadhukhan Date: 2016-08-23 10:27 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2193be826227 8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! test/javax/print/attribute/ServiceDialogValidateTest.java Changeset: f13b9035ff2b Author: rgoel Date: 2016-08-23 15:35 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f13b9035ff2b 8163362: Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class Reviewed-by: naoto, okutsu, prr ! src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java Changeset: 7fb7ead73775 Author: pnarayanan Date: 2016-08-23 14:47 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7fb7ead73775 8158524: Adding a test case to compare the rendered output of VolatileImage with that of BufferedImage Reviewed-by: serb, psadhukhan + test/java/awt/image/VolatileImage/TransparentVImage.java + test/java/awt/image/VolatileImage/duke.gif Changeset: 02afb762b2bf Author: azvegint Date: 2016-08-23 18:15 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02afb762b2bf 8162840: Desktop. enableSuddenTermination() has no effect Reviewed-by: serb ! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppMiscHandlers.java Changeset: 3c2bb0f0f129 Author: serb Date: 2016-08-23 20:45 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3c2bb0f0f129 8160217: JavaSound should clean up resources better Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/media/sound/ModelByteBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java ! test/javax/sound/sampled/AudioInputStream/FrameLengthAfterConversion.java ! test/javax/sound/sampled/spi/AudioFileWriter/WriteUnsupportedAudioFormat.java Changeset: dc69f25a52aa Author: alexsch Date: 2016-08-24 00:23 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dc69f25a52aa 8129854: Remove reflection from AWT/Swing classes Reviewed-by: serb ! src/java.desktop/macosx/classes/apple/laf/JRSUIConstants.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppDockIconHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaIcon.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CImage.java ! src/java.desktop/share/classes/java/awt/AWTEvent.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/SequencedEvent.java ! src/java.desktop/share/classes/java/awt/event/InputEvent.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleBundle.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleContext.java ! src/java.desktop/share/classes/javax/swing/ImageIcon.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/text/GlyphView.java ! src/java.desktop/share/classes/javax/swing/text/ParagraphView.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/java.desktop/share/classes/sun/applet/AppletPanel.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/swing/SwingAccessor.java ! src/java.desktop/unix/classes/sun/awt/X11/XComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMouseDragGestureRecognizer.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java Changeset: 03c615dd3bdd Author: peytoia Date: 2016-08-24 09:45 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03c615dd3bdd 8164628: update copyright header in java.awt.font.JavaAWTFontAccessImpl class Reviewed-by: prr, iris ! src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java Changeset: 4ae7185436e5 Author: bpb Date: 2016-08-24 10:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4ae7185436e5 8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node Summary: Add a throws clause to the TIFFField.createFromMetadataNode method specification stating that the supplied Node parameter must adhere to the TIFFField element structure defined by the TIFF native image metadata DTD. Reviewed-by: prr, darcy, serb ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java ! test/javax/imageio/plugins/tiff/TIFFFieldTest.java Changeset: ed5e8630c975 Author: prr Date: 2016-08-24 12:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ed5e8630c975 8164752: Extraneous debugging printf in hb-jdk-font.cc Reviewed-by: bpb ! src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc Changeset: 19a5e7c4df79 Author: prr Date: 2016-08-24 13:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19a5e7c4df79 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts Reviewed-by: serb, vadim ! src/java.desktop/macosx/classes/sun/font/CFont.java + test/java/awt/font/TextLayout/StyledFontLayoutTest.java Changeset: 070f06d1aa31 Author: aniyogi Date: 2016-08-25 13:46 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/070f06d1aa31 8163161: [PIT][TEST_BUG] increase timeout in javax/swing/plaf/nimbus/8057791/bug8057791.java Reviewed-by: alexsch, rchamyal ! test/javax/swing/plaf/nimbus/8057791/bug8057791.java Changeset: ca2ebc3de28c Author: aghaisas Date: 2016-08-25 14:12 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ca2ebc3de28c 8158356: SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees Reviewed-by: flar, prr ! src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageScanPoly.c ! src/java.desktop/share/native/libmlib_image/safe_math.h + test/java/awt/geom/AffineTransform/InvalidTransformParameterTest.java Changeset: e6c75f01a054 Author: psadhukhan Date: 2016-08-25 16:01 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e6c75f01a054 8154218: Non-usage of owner Frame when Frame object is passed to getPrintJob() Reviewed-by: prr, jdv ! src/java.desktop/share/classes/javax/print/ServiceUI.java + test/java/awt/PrintJob/TestPrintJobFrameAssociation.java Changeset: 8e45b8f5a16a Author: goetz Date: 2016-07-20 15:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e45b8f5a16a 8161923: Fix free in awt_PrintControl. Reviewed-by: vadim ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp Changeset: 470628a12878 Author: prr Date: 2016-08-29 08:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/470628a12878 Merge - make/data/cryptopolicy/limited/default_local.policy - make/data/cryptopolicy/limited/exempt_local.policy - make/data/cryptopolicy/unlimited/default_US_export.policy - make/data/cryptopolicy/unlimited/default_local.policy - make/gendata/GendataPolicyJars.gmk Changeset: 145d979bb1fb Author: psadhukhan Date: 2016-08-30 11:07 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/145d979bb1fb 6357887: selected printertray is ignored under linux Reviewed-by: prr, vadim ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/unix/classes/sun/print/UnixPrintJob.java + test/java/awt/print/PrinterJob/TestMediaTraySelection.java Changeset: 6c9eebfedd13 Author: prr Date: 2016-08-30 08:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c9eebfedd13 Merge Changeset: ce0716535c7e Author: prr Date: 2016-09-01 08:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ce0716535c7e Merge - test/sun/security/krb5/auto/unreachable.krb5.conf Changeset: 74cfa7836890 Author: psandoz Date: 2016-09-01 10:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/74cfa7836890 8161444: VarHandles should provide access bitwise atomics 8162107: Add acquire/release variants for getAndSet and getAndAdd Reviewed-by: shade, redestad ! make/gensrc/GensrcVarHandles.gmk ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodType.java.template ! test/java/lang/invoke/VarHandles/generate-vh-tests.sh Changeset: 9cb5558f968d Author: psandoz Date: 2016-09-01 10:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9cb5558f968d 8162106: Remove VarHandle.addAndGet Reviewed-by: shade, redestad ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeShort.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodType.java.template Changeset: e2d28c613133 Author: psandoz Date: 2016-09-01 13:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e2d28c613133 8162108: Rename weakCompareAndSetVolatile to weakCompareAndSet Reviewed-by: martin ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/FutureTask.java ! src/java.base/share/classes/java/util/concurrent/Phaser.java ! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodType.java.template Changeset: c7601cc83d0f Author: lana Date: 2016-09-02 02:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c7601cc83d0f Merge - test/sun/security/krb5/auto/unreachable.krb5.conf Changeset: 04b6837b1be5 Author: sundar Date: 2016-09-02 14:46 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/04b6837b1be5 8157992: Improve jlink help message on optimization-related options Reviewed-by: redestad, alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties Changeset: 3dc9d5deab5d Author: rpatil Date: 2016-09-01 10:35 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3dc9d5deab5d 8161016: Strange behavior of URLConnection with proxy Reviewed-by: shade, chegar ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/HttpURLConWithProxy.java Changeset: 4c4391db8060 Author: rriggs Date: 2016-09-02 12:30 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4c4391db8060 8155102: (Process) Process.toString could include pid, isAlive, exitStatus Reviewed-by: rriggs Contributed-by: andrey.dyachkov at gmail.com ! src/java.base/unix/classes/java/lang/ProcessImpl.java ! src/java.base/windows/classes/java/lang/ProcessImpl.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: 594b8b4fef69 Author: bpb Date: 2016-09-02 12:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/594b8b4fef69 8165000: Selector.select(timeout) throws IOException when timeout is a large long Summary: Clamp the timeout passed to kevent0 to the largest value that does not provoke the error. Reviewed-by: clanger, alanb ! src/java.base/macosx/native/libnio/ch/KQueueArrayWrapper.c + test/java/nio/channels/Selector/SelectTimeout.java Changeset: a81f30fb7d8c Author: igerasim Date: 2016-09-03 13:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a81f30fb7d8c 8165243: Base64.Encoder.wrap(os).write(byte[],int,int) with incorrect arguments should not produce output Reviewed-by: rriggs, alanb, sherman ! src/java.base/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: 40c3550625a2 Author: clanger Date: 2016-09-05 10:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/40c3550625a2 8163181: Further improvements for Unix NetworkInterface native implementation Reviewed-by: chegar, msheppar ! src/java.base/unix/native/libnet/NetworkInterface.c Changeset: eb84b64427a4 Author: vtewari Date: 2016-09-06 13:57 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb84b64427a4 8164730: Make it clear that 'cl' parameter passed to RMIConnector.OISWL is never null. Summary: Added checks inside constructor of ObjectInputStreamWithLoader inner class. Test case added. Reviewed-by: dfuchs, alanb Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java + test/javax/management/remote/mandatory/connection/ObjectInputStreamWithLoaderNullCheckTest.java Changeset: 1d8df40040ed Author: vtewari Date: 2016-09-06 14:11 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1d8df40040ed 8131061: Use of -Dcom.sun.management.snmp needs to be examined for modules Reviewed-by: mchung, dfuchs ! src/java.management/share/classes/module-info.java ! src/java.management/share/classes/sun/management/Agent.java + src/java.management/share/classes/sun/management/spi/AgentProvider.java Changeset: c320f2d8b078 Author: sundar Date: 2016-09-06 18:16 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c320f2d8b078 8163952: jlink exclude VM plugin does not support static libraries Reviewed-by: jlaskey ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java Changeset: 021369229cfd Author: alanbur Date: 2016-09-06 13:09 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/021369229cfd 8161360: Deprecated vfork() should not be used on Solaris Reviewed-by: rriggs, dsamersoff ! src/java.base/unix/native/libjava/ProcessImpl_md.c Changeset: 02d65bf86352 Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02d65bf86352 Added tag jdk-9+135 for changeset 021369229cfd ! .hgtags Changeset: 69eb6d4c5a69 Author: mchung Date: 2016-09-08 17:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/69eb6d4c5a69 Merge ! .hgtags ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/sun/applet/AppletPanel.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management/share/classes/module-info.java ! src/java.management/share/classes/sun/management/Agent.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/ProblemList.txt ! test/TEST.groups ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/ClassLoader/GetSystemPackage.java ! test/java/lang/instrument/NativeMethodPrefixAgent.java ! test/java/lang/management/GarbageCollectorMXBean/GcInfoCompositeType.java ! test/java/net/URLPermission/nstest/lookup.sh ! test/java/util/regex/PatternStreamTest.java ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java ! test/sun/tools/jmap/BasicJMapTest.java ! test/sun/tools/jps/TestJpsSanity.java From mandy.chung at oracle.com Fri Sep 9 00:45:53 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:45:53 +0000 Subject: hg: jigsaw/jake/langtools: 17 new changesets Message-ID: <201609090045.u890jr4I001589@aojmv0008.oracle.com> Changeset: e15a551a81b5 Author: smarks Date: 2016-08-29 13:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e15a551a81b5 8164837: fix jdeprscan TestLoad and TestScan failures on Windows Reviewed-by: darcy ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java ! test/ProblemList.txt Changeset: 047d4d42b466 Author: mchung Date: 2016-08-30 17:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/047d4d42b466 8160851: Remove old launcher module-related options Reviewed-by: jjg, alanb ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformDescription.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/package-info.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java Changeset: 98d653e53a0a Author: mchung Date: 2016-08-30 20:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/98d653e53a0a 8165109: langtools/test switches to use new CLI options Reviewed-by: jjg, amlu ! test/jdk/javadoc/tool/ReleaseOption.java ! test/tools/javac/T8139474/DashRelease7DashVerboseTest.java ! test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java ! test/tools/javac/file/MultiReleaseJar/MultiReleaseJarAwareSJFM.java ! test/tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java ! test/tools/javac/modules/AnachronisticModuleInfo/AnachronisticModuleInfoTest.java ! test/tools/javac/modules/UpgradeModulePathTest.java ! test/tools/javac/options/release/ReleaseOption.java ! test/tools/javac/options/release/ReleaseOptionClashes.java ! test/tools/javac/options/release/ReleaseOptionThroughAPI.java ! test/tools/javac/platform/PlatformProviderTest.java ! test/tools/javac/sym/ElementStructureTest.java ! test/tools/javac/synthesize/Main.java ! test/tools/javadoc/ReleaseOption.java ! test/tools/lib/toolbox/ModuleBuilder.java Changeset: d2959c941df3 Author: rfield Date: 2016-08-31 10:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d2959c941df3 8164518: JShell: Add failover case of explicitly listening to "localhost" Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/JShell.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JDIDefaultExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JDIInitiator.java + test/jdk/jshell/JDILaunchingExecutionControlTest.java ! test/jdk/jshell/JDIListeningExecutionControlTest.java + test/jdk/jshell/JDIListeningLocalhostExecutionControlTest.java ! test/jdk/jshell/UserJDIUserRemoteTest.java Changeset: d87cef2896aa Author: shinyafox Date: 2016-09-01 11:07 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d87cef2896aa 8164825: jshell tool: Completion for subcommand Reviewed-by: jlahoda + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ContinuousCompletionProvider.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/jdk/jshell/CommandCompletionTest.java Changeset: 8d4de635981a Author: amlu Date: 2016-09-01 13:18 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8d4de635981a 8165193: Workaround intermittent failures of JavacTreeScannerTest and SourceTreeScannerTest due to C2 memory usage Reviewed-by: darcy ! test/tools/javac/tree/JavacTreeScannerTest.java ! test/tools/javac/tree/SourceTreeScannerTest.java Changeset: fdff20865f5f Author: jlahoda Date: 2016-09-01 10:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fdff20865f5f 8131023: JShell: System.in does not work Summary: Pass user input to snippets/remote agent Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/DemultiplexInput.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JDIDefaultExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/MultiplexingOutputStream.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/PipeInputStream.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java ! test/jdk/jshell/ReplToolTesting.java ! test/jdk/jshell/StartOptionTest.java + test/jdk/jshell/UserInputTest.java ! test/jdk/jshell/UserJDIUserRemoteTest.java Changeset: 5a2d38a840cc Author: jlahoda Date: 2016-08-29 15:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5a2d38a840cc 8165008: javac -Xmodule compiles the module in a way that reads the unnamed module Summary: Ensuring proper separation between named modules and the unnamed module when using -Xmodule Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/tools/javac/modules/XModuleTest.java Changeset: 6c6c7ebe3319 Author: rfield Date: 2016-09-01 12:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6c6c7ebe3319 8133507: JShell: StackTraceElement#getFileName of EvalException does not use custom id generator Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! test/jdk/jshell/IdGeneratorTest.java Changeset: e3da5f8001d2 Author: jlahoda Date: 2016-09-01 21:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e3da5f8001d2 8164952: JShell tests: jdk/jshell/CompletionSuggestionTest.testUncompletedDeclaration(): failure Summary: Avoiding conflict between the CompletionSuggestionTest.testUncompletedDeclaration test and ClassPathTest Reviewed-by: rfield ! test/jdk/jshell/CompletionSuggestionTest.java Changeset: f3c256cbcb58 Author: rfield Date: 2016-09-01 13:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f3c256cbcb58 8165211: JShell: Fix completion analysis problems Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/jdk/jshell/CompletenessTest.java Changeset: 192d58e5d899 Author: sadayapalam Date: 2016-09-02 07:49 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/192d58e5d899 8164073: Javac should unconditionally warn if deprecated javadoc tag is used without @Deprecated annotation Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java ! test/tools/javac/T4994049/DeprecatedYES.out ! test/tools/javac/danglingDep/DepX.out + test/tools/javac/depDocComment/SuppressDepAnnWithSwitchTest.java ! test/tools/javac/depDocComment/SuppressDeprecation.java ! test/tools/javac/depDocComment/SuppressDeprecation.out + test/tools/javac/depDocComment/SuppressDeprecation8.out ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test1A.out ! test/tools/javac/depOverrides/doccomment/Test1B.out ! test/tools/javac/depOverrides/doccomment/Test1B2.out + test/tools/javac/depOverrides/doccomment/Test1B3.out + test/tools/javac/depOverrides/doccomment/Test1I.out ! test/tools/javac/depOverrides/doccomment/Test2.java + test/tools/javac/depOverrides/doccomment/Test2P.out ! test/tools/javac/depOverrides/doccomment/Test2Q.out ! test/tools/javac/depOverrides/doccomment/Test2R.out ! test/tools/javac/depOverrides/doccomment/Test3.out ! test/tools/javac/lint/Deprecation.out Changeset: 595ae38c8f08 Author: lana Date: 2016-09-02 02:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/595ae38c8f08 Merge Changeset: 53ebb47dc802 Author: vromero Date: 2016-09-02 05:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/53ebb47dc802 8160454: JSR269 jigsaw update: javax.lang.model.element.ModuleElement.getDirectives() causes NPE on unnamed modules Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java + test/tools/javac/modules/T8160454/NPEGetDirectivesTest.java Changeset: af5eb8f3ffd2 Author: jlahoda Date: 2016-09-06 12:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/af5eb8f3ffd2 8161376: Introduce -Xlint:exports Summary: Adding -Xlint:exports, currently not doing anything. Functionality will be added separatelly under JDK-8153362. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties Changeset: 39138c7eeb27 Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/39138c7eeb27 Added tag jdk-9+135 for changeset af5eb8f3ffd2 ! .hgtags Changeset: 898ed6a0367f Author: mchung Date: 2016-09-08 17:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/898ed6a0367f Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! test/ProblemList.txt ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/CompletionSuggestionTest.java + test/tools/javac/modules/RequiresStaticTest.java ! test/tools/javac/modules/UpgradeModulePathTest.java ! test/tools/javac/modules/XModuleTest.java ! test/tools/javac/platform/PlatformProviderTest.java ! test/tools/javac/sym/ElementStructureTest.java ! test/tools/javac/synthesize/Main.java ! test/tools/sjavac/Serialization.java From mandy.chung at oracle.com Fri Sep 9 00:45:57 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Sep 2016 00:45:57 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201609090045.u890jvCk001676@aojmv0008.oracle.com> Changeset: 61a07a6d70e4 Author: lana Date: 2016-09-08 21:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/61a07a6d70e4 Added tag jdk-9+135 for changeset cb00d5ef023a ! .hgtags Changeset: ba56297704e6 Author: mchung Date: 2016-09-08 17:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ba56297704e6 Merge ! .hgtags From sundararajan.athijegannathan at oracle.com Fri Sep 9 13:02:11 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 9 Sep 2016 06:02:11 -0700 (PDT) Subject: RFR 8163320: JAVA_VERSION in release file should come from java.base module Message-ID: <640724e0-6d49-81be-3482-74dbc001d4ba@oracle.com> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8163320 jdk repo: http://cr.openjdk.java.net/~sundar/8163320/jdk/ * JAVA_VERSION is derived from module-info of java.base * adding quotes around all 'release' properties top repo: http://cr.openjdk.java.net/~sundar/8163320/top/webrev.01/ Makefile changes to avoid generating OS_NAME, JAVA_VERSION etc. - as jlink takes care of those. Thanks -Sundar From sundararajan.athijegannathan at oracle.com Fri Sep 9 13:58:34 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 9 Sep 2016 19:28:34 +0530 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java Message-ID: Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165772 Thanks, -Sundar From james.laskey at oracle.com Fri Sep 9 14:29:53 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 9 Sep 2016 11:29:53 -0300 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: References: Message-ID: +1 > On Sep 9, 2016, at 10:58 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8165772 > > Thanks, > > -Sundar > From stephen.felts at oracle.com Fri Sep 9 14:30:41 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 9 Sep 2016 07:30:41 -0700 (PDT) Subject: JDK9 encapsulation problem In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> Message-ID: <7a8165f6-66f6-439a-9085-24f7145fd966@default> We have an application that is running into a problem with a utility program.? Below is a standalone reproducer. ? The program does not import the SPI package sun.nio.ch - it isn't aware of it, and SocketChannel.isConnected() is a public method of a public type. In short, it does not break any law of encapsulation, so call setAccessible(true) should be OK. ? import java.lang.reflect.Method; ? ? public class JDK9Nio { ? public static void main(String args[]) throws Exception { ??? call(); ? } ? ? public static void call() throws Exception { ??? Class clzz = Class.forName("java.nio.channels.SocketChannel"); ??? Method open = clzz.getMethod("open"); ??? Object obj = open.invoke(null); ??? Method isConn = obj.getClass().getMethod("isConnected"); ??? isConn.setAccessible(true); // OK with JDK8, fail with JDK9 ??? System.out.println(isConn.invoke(obj)); ? } } ? ? java JDK9Nio Exception in thread "main" java.lang.reflect.InaccessibleObjectException: Unable to make member of class sun.nio.ch.SocketChannelImpl accessible:? module java.base does not export sun.nio.ch to unnamed module @3857f613 ??????? at jdk.internal.reflect.Reflection.throwInaccessibleObjectException(java.base at 9-ea/Reflection.java:414) ??????? at java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base at 9-ea/AccessibleObject.java:174) ??????? at java.lang.reflect.Method.checkCanSetAccessible(java.base at 9-ea/Method.java:192) ??????? at java.lang.reflect.Method.setAccessible(java.base at 9-ea/Method.java:186) ??????? at JDK9Nio.call(JDK9Nio.java:14) ??????? at JDK9Nio.main(JDK9Nio.java:6) ? ? ? It's easy to say that the program should be re-written and the setAccessible is not necessary but this is a utility program over which the application has no control (a jython script). What's ugly is that the internal implementation is showing through to the application. ? Many people especially tool makers have this problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318 https://netbeans.org/bugzilla/show_bug.cgi?id=258952 https://netbeans.org/bugzilla/show_bug.cgi?id=262765 http://mail.openjdk.java.net/pipermail/quality-discuss/2015-November/000468.html https://community.oracle.com/thread/3937249 ? ? From Alan.Bateman at oracle.com Fri Sep 9 14:42:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 15:42:09 +0100 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: References: Message-ID: <6d41b725-7688-6c1a-f2b3-c440b70cd787@oracle.com> On 09/09/2016 14:58, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8165772 > Would it better to skip when the module has launchers in the bin directory? -Alan From sundararajan.athijegannathan at oracle.com Fri Sep 9 14:46:35 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 9 Sep 2016 20:16:35 +0530 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: <6d41b725-7688-6c1a-f2b3-c440b70cd787@oracle.com> References: <6d41b725-7688-6c1a-f2b3-c440b70cd787@oracle.com> Message-ID: Hmm.. how would we know that? A well-known list you mean? Besides, our current tests assume that all "bin" directory commands are derived from standard binary launcher and so satisfy all launcher options like -J- etc. -Sundar On 9/9/2016 8:12 PM, Alan Bateman wrote: > On 09/09/2016 14:58, Sundararajan Athijegannathan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for >> https://bugs.openjdk.java.net/browse/JDK-8165772 >> > Would it better to skip when the module has launchers in the bin > directory? > > -Alan From Alan.Bateman at oracle.com Fri Sep 9 14:50:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 15:50:46 +0100 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: References: <6d41b725-7688-6c1a-f2b3-c440b70cd787@oracle.com> Message-ID: <8ab10f20-3b39-92c8-36b4-c8495e18524c@oracle.com> On 09/09/2016 15:46, Sundararajan Athijegannathan wrote: > Hmm.. how would we know that? A well-known list you mean? Besides, our > current tests assume that all "bin" directory commands are derived from > standard binary launcher and so satisfy all launcher options like > -J- etc. > I think you'll need to look in the module to see if it has resources in the bin directory. Alternatively, the JMOD format will need something to indicate that launchers should not be generated for the module. -Alan From stephen.felts at oracle.com Fri Sep 9 15:31:16 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 9 Sep 2016 08:31:16 -0700 (PDT) Subject: JDK 9 configuration options In-Reply-To: <7a8165f6-66f6-439a-9085-24f7145fd966@default> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> <7a8165f6-66f6-439a-9085-24f7145fd966@default> Message-ID: It?s common in enterprise applications to have multiple frameworks running in the same JVM.? For example, and application server might have Spring or Birt used in the application.? There are even cases where part of one application server might be used as a library running in the same JVM as another application server (e.g., for foreign JMS queues). ? In JDK 8 and earlier, merging two frameworks together into the same JVM meant putting the appropriate jar files in a single classpath.? Some products even add their jar files to the CLASSPATH environment variable transparently.? So although there may be ordering problems, the problem is pretty well understood. ? In the case of JDK 9, there are a lot of new options related to Jigsaw.? The likely scenario is that frameworks will try to hide these options using the new argument file feature.? There are a number of problems related to doing this. ? 1. Argument files support relative pathnames for things like module path, upgrade path, and patch files.? However, they are relative to the working directory.? You can?t use environment variables.? That means that the argument file needs to be programmatically generated (just unzipping an argument file won?t work).?? Supporting path names relative to the containing file is the common practice of many system like ant, gradle, etc. ? 2. With the new argument syntax in JDK 9 build 132, the launcher arguments now match the command line arguments.? That?s a big step in the right direction.? However, duplicates are a fatal error.? So doing export _JAVA_OPTIONS=-XX:VMOptionsFile=/mydir/jdk9args java @/mydir/jdk9args something fails.? If one framework needs java.xml.bind and another framework uses the same module, that should just work.? If one needs bind and another needs jdk.rmic, I shouldn?t have to concatenate the two framework argument files together and manually merge the add-modules arguments together.? It seems conceptually simple to add the required lists together in java or javac.? The same is true for other things like exports, module path, upgrade module path, patch module, etc. Assuming that all legacy usages are fixed, exports, patch module, and upgrade module path go away leaving module path.? Unlike CLASSPATH, there is no equivalent MODULEPATH to get the option off of the command line. ? In general, it?s not clear how to manage JDK 9 options for multiple frameworks in the same JVM.? At this point, our project has banned the use of all JDK 9 options including module path. ? I understand that some of these things were discussed two years ago.? That doesn?t fix the problem that there isn?t a good way to merge options for our customers.? Requiring a customer to cat a bunch of argument files together and then merge them manually isn?t a good solution. ? From mandy.chung at oracle.com Fri Sep 9 15:37:11 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Sep 2016 08:37:11 -0700 Subject: RFR 8163320: JAVA_VERSION in release file should come from java.base module In-Reply-To: <640724e0-6d49-81be-3482-74dbc001d4ba@oracle.com> References: <640724e0-6d49-81be-3482-74dbc001d4ba@oracle.com> Message-ID: <174D8EFE-F40F-44BD-9699-FDE0952DE0BA@oracle.com> Looks good. Is there an existing test to check the content of `release` file? It would be good to have a test to sanity test a few properties and its quoted value. Mandy > On Sep 9, 2016, at 6:02 AM, Sundararajan Athijegannathan wrote: > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8163320 > > jdk repo: > > http://cr.openjdk.java.net/~sundar/8163320/jdk/ > > * JAVA_VERSION is derived from module-info of java.base > > * adding quotes around all 'release' properties > > top repo: > > http://cr.openjdk.java.net/~sundar/8163320/top/webrev.01/ > > Makefile changes to avoid generating OS_NAME, JAVA_VERSION etc. - as > jlink takes care of those. > > Thanks > > -Sundar > From david.lloyd at redhat.com Fri Sep 9 15:44:03 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 9 Sep 2016 10:44:03 -0500 Subject: Using non-parallel custom class loaders for Layer configurations In-Reply-To: <789BC05B-7D50-40F7-9E79-270AA8881B32@oracle.com> References: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> <789BC05B-7D50-40F7-9E79-270AA8881B32@oracle.com> Message-ID: On 09/08/2016 06:48 PM, Mandy Chung wrote: > >> On Sep 8, 2016, at 3:29 PM, David M. Lloyd wrote: >> >> Would it be possible to include a method like this (pretty old patch I had laying around): >> >> diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >> index 1bb1580..3def10e 100644 >> --- a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >> +++ b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >> @@ -469,6 +477,15 @@ public abstract class ClassLoader { >> return lock; >> } >> >> + /** >> + * Determine whether this class loader is parallel-capable. >> + * >> + * @return {@code true} if the class loader is parallel-capable, {@code false} otherwise >> + */ >> + protected final boolean isParallelCapable() { >> + return ParallelLoaders.isRegistered(getClass()); >> + } >> + > > This seems a fine method to add. I think it can be a public method (I don?t see any reason it has to be protected) Great! Since it's such a small method though, would it be possible to just roll this change into some other changeset? I can't really contribute the change in any form other than a patch right now. Thanks. -- - DML From eric at tibco.com Fri Sep 9 15:44:40 2016 From: eric at tibco.com (Eric Johnson) Date: Fri, 9 Sep 2016 08:44:40 -0700 Subject: Java 9 Obfuscators? Message-ID: Anyone aware of byte-code obfuscators already working with Java 9? How does modularization interact with obfuscation? Eric. From peter.levart at gmail.com Fri Sep 9 15:53:51 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 9 Sep 2016 17:53:51 +0200 Subject: JDK9 encapsulation problem In-Reply-To: <7a8165f6-66f6-439a-9085-24f7145fd966@default> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> <7a8165f6-66f6-439a-9085-24f7145fd966@default> Message-ID: <5f40bc2e-3798-3dd9-d78d-4eaf02651cd0@gmail.com> Hi Stephen, On 09/09/2016 04:30 PM, Stephen Felts wrote: > We have an application that is running into a problem with a utility program. Below is a standalone reproducer. > > > > The program does not import the SPI package sun.nio.ch - it isn't aware of > > it, and SocketChannel.isConnected() is a public method of a public type. In > > short, it does not break any law of encapsulation, so call > > setAccessible(true) should be OK. Ok, but... > > > > import java.lang.reflect.Method; > > > > > > public class JDK9Nio { > > public static void main(String args[]) throws Exception { > > call(); > > } > > > > public static void call() throws Exception { > > Class clzz = Class.forName("java.nio.channels.SocketChannel"); > > Method open = clzz.getMethod("open"); > > Object obj = open.invoke(null); > > Method isConn = obj.getClass().getMethod("isConnected"); ...This is a classical reflection anti-pattern. What program should be doing to call the public and exported SocketChannel.isConnected() method is the following: Method isConn = SocketChannel.class.getMethod("isConnected"); obj.getClass().getMethod(...) is rarely what is desired. What you get back is a Method object for method declared in a package-private class. That's why setAccessible() was needed. And now in JDK 9, this class is also in a non-exported package, so setAccessible() does not help any more. But I see your point. It worked before and is not working any more... > > isConn.setAccessible(true); // OK with JDK8, fail with JDK9 > > System.out.println(isConn.invoke(obj)); > > } > > } > > > > > > java JDK9Nio > > Exception in thread "main" java.lang.reflect.InaccessibleObjectException: Unable to make member of class sun.nio.ch.SocketChannelImpl accessible: module java.base does not export sun.nio.ch to unnamed module @3857f613 > > at jdk.internal.reflect.Reflection.throwInaccessibleObjectException(java.base at 9-ea/Reflection.java:414) > > at java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base at 9-ea/AccessibleObject.java:174) > > at java.lang.reflect.Method.checkCanSetAccessible(java.base at 9-ea/Method.java:192) > > at java.lang.reflect.Method.setAccessible(java.base at 9-ea/Method.java:186) > > at JDK9Nio.call(JDK9Nio.java:14) > > at JDK9Nio.main(JDK9Nio.java:6) > > > > > > > > It's easy to say that the program should be re-written and the setAccessible is not necessary but this is a utility program over which the application has no control (a jython script). > > What's ugly is that the internal implementation is showing through to the application. Maybe there could be a solution in supporting such sloppy programming though. If the reflective invocation is performed to a virtual method, then the JVM virtual dispatch chooses the method declared in the most specific class regardless of what the Method object used is telling about the method's declaring class. So if there exists at least one matching method declared in the hierarchy of types comprising the runtime type of the object upon which the method is being invoked, and such method is accessible to the invoker, such invocation could be allowed. The rationale is simple: if the invocation dispatches to the same method for distinct Method objects, it should also succeed or not succeed consistently regardless of which Method object was used to perform the invocation. But such access check would surely be much slower. It's better to just fix the program (if you can :-( ). Regards, Peter > > > > Many people especially tool makers have this problem: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318 > > https://netbeans.org/bugzilla/show_bug.cgi?id=258952 > > https://netbeans.org/bugzilla/show_bug.cgi?id=262765 > > http://mail.openjdk.java.net/pipermail/quality-discuss/2015-November/000468.html > > https://community.oracle.com/thread/3937249 > > > > From Alan.Bateman at oracle.com Fri Sep 9 16:04:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 17:04:35 +0100 Subject: JDK 9 configuration options In-Reply-To: References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> <7a8165f6-66f6-439a-9085-24f7145fd966@default> Message-ID: <8e22a207-a6b4-33f2-8fe2-77deab74da35@oracle.com> On 09/09/2016 16:31, Stephen Felts wrote: > : > > > > 2. With the new argument syntax in JDK 9 build 132, the launcher arguments now match the command line arguments. That?s a big step in the right direction. However, duplicates are a fatal error. So doing > > export _JAVA_OPTIONS=-XX:VMOptionsFile=/mydir/jdk9args > java @/mydir/jdk9args something > > fails. > > If one framework needs java.xml.bind and another framework uses the same module, that should just work. If one needs bind and another needs jdk.rmic, I shouldn?t have to concatenate the two framework argument files together and manually merge the add-modules arguments together. It seems conceptually simple to add the required lists together in java or javac. The same is true for other things like exports, module path, upgrade module path, patch module, etc. > In the case of --add-modules then Mandy and Harold have changes in review on hotspot-runtime-dev and core-libs-dev to change this into a repeating option (it's currently last one wins). There will be follow-on work needed in javac and other tools to get things aligned. There is related patch coming that will propose to update the exiting repeating options (specifically --add-exports and --add-reads) to tolerate dups. Again, the complete solution requires updates to javac, maybe jlink, to get everything consistent. Assuming there aren't any issues when I would expect JEP 261 be to updated to reflect these proposals. -Alan From forax at univ-mlv.fr Fri Sep 9 16:05:30 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 9 Sep 2016 18:05:30 +0200 (CEST) Subject: Java 9 Obfuscators? In-Reply-To: References: Message-ID: <431289395.2300847.1473437130319.JavaMail.zimbra@u-pem.fr> Hi Eric, ASM has a support for obfuscation (ClassRemapper [1]) and the version 6 also support Java 9 (currently the branch ASM_6_FUTURE support the new classfile encoding used by the betas of jdk-9-jigsaw while asm6-alpha [2] support the old classfile encoding currently used by the betas of jdk-9) The ClassRemapper API allows you to rename class name, type, etc. The support for Java 9 adds ways to rename a package name and a module name. This API is not per see an obfuscator, you have to code what should be renamed or not. cheers, R?mi [1] http://websvn.ow2.org/filedetails.php?repname=asm&path=%2Fbranches%2FASM_6_FUTURE%2Fasm%2Fsrc%2Forg%2Fobjectweb%2Fasm%2Fcommons%2FClassRemapper.java [2] available here: http://forge.ow2.org/projects/asm/ ----- Mail original ----- > De: "Eric Johnson" > ?: "jigsaw-dev" > Envoy?: Vendredi 9 Septembre 2016 17:44:40 > Objet: Java 9 Obfuscators? > Anyone aware of byte-code obfuscators already working with Java 9? > > How does modularization interact with obfuscation? > > Eric. From Alan.Bateman at oracle.com Fri Sep 9 16:24:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 17:24:48 +0100 Subject: Java 9 Obfuscators? In-Reply-To: References: Message-ID: <2b213073-ebaa-d04c-4d57-39ebfbf8ac55@oracle.com> On 09/09/2016 16:44, Eric Johnson wrote: > Anyone aware of byte-code obfuscators already working with Java 9? > > How does modularization interact with obfuscation? I haven't seen bytecode obfuscators in many years and don't know if anyone has tried one with 53.0 class files. However, if the tool is just renaming private or package-private methods then it should work as before. I could imagine a "module-aware" obfuscator having more freedom than before in that it could change public types in non-exported packages (it would need to be careful with any service providers in those packages of ourse). If you use one a regular basis then best to try it out and report back. -Alan From Alan.Bateman at oracle.com Fri Sep 9 16:26:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 17:26:53 +0100 Subject: Using non-parallel custom class loaders for Layer configurations In-Reply-To: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> References: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> Message-ID: <6557f1ea-0a9e-da65-fd1e-919730fbe7c2@oracle.com> On 08/09/2016 23:29, David M. Lloyd wrote: > Is it not necessary that any class loader in use by a Layer must be > parallel-capable? Otherwise it seems like deadlocks could occur in > certain situations when there are references that are cyclic with > respect to class loaders mapped by the mapping function. There aren't cycles in readability graph, at least not at construction time. They might arise later due to reflective use of addReads but that shouldn't change the class loader delegation graph. So I'm curious if you are actually running into an issue or not? I can easily come up with a mapping to loaders to force this but it would be unusual mapping. BTW: I'm not opposed to exposing isParallelCapable, just curious if this is something that you are actually running into or not. -Alan From david.lloyd at redhat.com Fri Sep 9 16:29:47 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 9 Sep 2016 11:29:47 -0500 Subject: Using non-parallel custom class loaders for Layer configurations In-Reply-To: <6557f1ea-0a9e-da65-fd1e-919730fbe7c2@oracle.com> References: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> <6557f1ea-0a9e-da65-fd1e-919730fbe7c2@oracle.com> Message-ID: On 09/09/2016 11:26 AM, Alan Bateman wrote: > On 08/09/2016 23:29, David M. Lloyd wrote: > >> Is it not necessary that any class loader in use by a Layer must be >> parallel-capable? Otherwise it seems like deadlocks could occur in >> certain situations when there are references that are cyclic with >> respect to class loaders mapped by the mapping function. > There aren't cycles in readability graph, at least not at construction > time. They might arise later due to reflective use of addReads but that > shouldn't change the class loader delegation graph. So I'm curious if > you are actually running into an issue or not? I can easily come up with > a mapping to loaders to force this but it would be unusual mapping. > > BTW: I'm not opposed to exposing isParallelCapable, just curious if this > is something that you are actually running into or not. No, I've only run into this with our module system which is separate from Jigsaw, but I was examining this code recently and I was surprised to see that Jigsaw did not take this into account. I don't think there needs to be a readability cycle between modules for this to be a potential problem; there only has to be a cycle between class loaders. So if you (for whatever reason) put half of your modules in one class loader and half in another, and those modules refer to one another, I think you might have a problem if those modules refer to one another and the class loaders are not parallel capable. But like I said that's just a hypothesis. -- - DML From stephen.felts at oracle.com Fri Sep 9 17:32:17 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 9 Sep 2016 10:32:17 -0700 (PDT) Subject: JDK9 encapsulation problem In-Reply-To: <5f40bc2e-3798-3dd9-d78d-4eaf02651cd0@gmail.com> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> <7a8165f6-66f6-439a-9085-24f7145fd966@default> <5f40bc2e-3798-3dd9-d78d-4eaf02651cd0@gmail.com> Message-ID: <3fda72d0-c7b3-4230-8f58-0fd0f8eab738@default> This is a general problem with utility programs.? This isn't, unlike the sample, something where I can just re-code it to use the public interface.? The utility program isn't checking to see what is public and what is not.? It looks up the class and invokes on it, creating or opening the object.? Then the object is used for further operations.? The class is public.? We grep'ed the entire code base looking for an import or dynamic reference to the internal API but obviously didn't find it. This is an interpreted language where obj = clzz.open();? obj.method2() is invoked in a general purpose way. ? Class clzz = Class.forName("clzz"); Method m = clzz.getMethod("open"); Object obj = m.invoke(null); Method m2 = obj.getClass().getMethod("method2"); m.setAccessible(true); m2.invoke(obj); ? If this problem isn't fixed in the JDK, then I might have code that works in JDK 9 and is broken when someone decides to re-implement something directly using an internal package in JDK 10. ? ? ? ? -----Original Message----- From: Peter Levart [mailto:peter.levart at gmail.com] Sent: Friday, September 09, 2016 11:54 AM To: Stephen Felts; jigsaw-dev at openjdk.java.net Subject: Re: JDK9 encapsulation problem ? Hi Stephen, ? ? On 09/09/2016 04:30 PM, Stephen Felts wrote: > We have an application that is running into a problem with a utility program.? Below is a standalone reproducer. >? >?? >? > The program does not import the SPI package sun.nio.ch - it isn't > aware of >? > it, and SocketChannel.isConnected() is a public method of a public > type. In >? > short, it does not break any law of encapsulation, so call >? > setAccessible(true) should be OK. ? Ok, but... ? >? >?? >? > import java.lang.reflect.Method; >? >?? >? >?? >? > public class JDK9Nio { >? >??? public static void main(String args[]) throws Exception { >? >????? call(); >? >??? } >? >?? >? >??? public static void call() throws Exception { >? >????? Class clzz = Class.forName("java.nio.channels.SocketChannel"); >? >????? Method open = clzz.getMethod("open"); >? >????? Object obj = open.invoke(null); >? >????? Method isConn = obj.getClass().getMethod("isConnected"); ? ...This is a classical reflection anti-pattern. What program should be doing to call the public and exported SocketChannel.isConnected() method is the following: ? Method isConn = SocketChannel.class.getMethod("isConnected"); ? obj.getClass().getMethod(...) is rarely what is desired. What you get back is a Method object for method declared in a package-private class. That's why setAccessible() was needed. And now in JDK 9, this class is also in a non-exported package, so setAccessible() does not help any more. But I see your point. It worked before and is not working any more... ? >? >????? isConn.setAccessible(true); // OK with JDK8, fail with JDK9 >? >????? System.out.println(isConn.invoke(obj)); >? >??? } >? > } >? >?? >? >?? >? > java JDK9Nio >? > Exception in thread "main" > java.lang.reflect.InaccessibleObjectException: Unable to make member > of class sun.nio.ch.SocketChannelImpl accessible:? module java.base > does not export sun.nio.ch to unnamed module @3857f613 >? >????????? at > jdk.internal.reflect.Reflection.throwInaccessibleObjectException(java. > HYPERLINK "mailto:base at 9-ea/Reflection.java:414"base at 9-ea/Reflection.java:414) >? >????????? at > java.lang.reflect.AccessibleObject.checkCanSetAccessible(HYPERLINK "mailto:java.base at 9-e"java.base at 9-e > a/AccessibleObject.java:174) >? >????????? at > java.lang.reflect.Method.checkCanSetAccessible(HYPERLINK "mailto:java.base at 9-ea/Method.j"java.base at 9-ea/Method.j > ava:192) >? >????????? at > java.lang.reflect.Method.setAccessible(HYPERLINK "mailto:java.base at 9-ea/Method.java:186"java.base at 9-ea/Method.java:186) >? >????????? at JDK9Nio.call(JDK9Nio.java:14) >? >????????? at JDK9Nio.main(JDK9Nio.java:6) >? >?? >? >?? >? >?? >? > It's easy to say that the program should be re-written and the setAccessible is not necessary but this is a utility program over which the application has no control (a jython script). >? > What's ugly is that the internal implementation is showing through to the application. ? Maybe there could be a solution in supporting such sloppy programming though. If the reflective invocation is performed to a virtual method, then the JVM virtual dispatch chooses the method declared in the most specific class regardless of what the Method object used is telling about the method's declaring class. So if there exists at least one matching method declared in the hierarchy of types comprising the runtime type of the object upon which the method is being invoked, and such method is accessible to the invoker, such invocation could be allowed. The rationale is simple: if the invocation dispatches to the same method for distinct Method objects, it should also succeed or not succeed consistently regardless of which Method object was used to perform the invocation. ? But such access check would surely be much slower. It's better to just fix the program (if you can :-( ). ? Regards, Peter ? >? >?? >? > Many people especially tool makers have this problem: >? > https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318 >? > https://netbeans.org/bugzilla/show_bug.cgi?id=258952 >? > https://netbeans.org/bugzilla/show_bug.cgi?id=262765 >? > http://mail.openjdk.java.net/pipermail/quality-discuss/2015-November/0 > 00468.html >? > https://community.oracle.com/thread/3937249 >? >?? >? >?? ? ? From mandy.chung at oracle.com Fri Sep 9 19:05:04 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Sep 2016 12:05:04 -0700 Subject: Using non-parallel custom class loaders for Layer configurations In-Reply-To: References: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> <789BC05B-7D50-40F7-9E79-270AA8881B32@oracle.com> Message-ID: <1A4F37F8-5517-4582-91E0-EB1DDD697E8E@oracle.com> > On Sep 9, 2016, at 8:44 AM, David M. Lloyd wrote: > > On 09/08/2016 06:48 PM, Mandy Chung wrote: >> >>> On Sep 8, 2016, at 3:29 PM, David M. Lloyd wrote: >>> >>> Would it be possible to include a method like this (pretty old patch I had laying around): >>> >>> diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >>> index 1bb1580..3def10e 100644 >>> --- a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >>> +++ b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >>> @@ -469,6 +477,15 @@ public abstract class ClassLoader { >>> return lock; >>> } >>> >>> + /** >>> + * Determine whether this class loader is parallel-capable. >>> + * >>> + * @return {@code true} if the class loader is parallel-capable, {@code false} otherwise >>> + */ >>> + protected final boolean isParallelCapable() { >>> + return ParallelLoaders.isRegistered(getClass()); >>> + } >>> + >> >> This seems a fine method to add. I think it can be a public method (I don?t see any reason it has to be protected) > > Great! Since it's such a small method though, would it be possible to just roll this change into some other changeset? I can't really contribute the change in any form other than a patch right now. I file a RFE and Brent Christian has agreed to work on it and will go through JDK 9 FC approval request. https://bugs.openjdk.java.net/browse/JDK-8165793 Mandy From peter.levart at gmail.com Fri Sep 9 20:00:23 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 9 Sep 2016 22:00:23 +0200 Subject: JDK9 encapsulation problem In-Reply-To: <3fda72d0-c7b3-4230-8f58-0fd0f8eab738@default> References: <1472666185307-5713364.post@n5.nabble.com> <57C72214.9030008@oracle.com> <1758113784.1346322.1472671730083.JavaMail.zimbra@u-pem.fr> <8beb1191-aec8-cbd9-020b-d2c2be47bd78@oracle.com> <6012b38b-84e1-2b75-94f7-bd9c516b67ed@redhat.com> <7a8165f6-66f6-439a-9085-24f7145fd966@default> <5f40bc2e-3798-3dd9-d78d-4eaf02651cd0@gmail.com> <3fda72d0-c7b3-4230-8f58-0fd0f8eab738@default> Message-ID: <0da9b333-01da-3911-6d32-44605e69ceb8@gmail.com> Hi Stephen, I see your problem... On 09/09/2016 07:32 PM, Stephen Felts wrote: > > This is a general problem with utility programs. This isn't, unlike > the sample, something where I can just re-code it to use the public > interface. The utility program isn't checking to see what is public > and what is not. It looks up the class and invokes on it, creating or > opening the object. Then the object is used for further operations. > The class is public. We grep'ed the entire code base looking for an > import or dynamic reference to the internal API but obviously didn't > find it. > > This is an interpreted language where obj = clzz.open(); > obj.method2() is invoked in a general purpose way. > > Class clzz = Class.forName("clzz"); > > Method m = clzz.getMethod("open"); > > Object obj = m.invoke(null); > > Method m2 = obj.getClass().getMethod("method2"); > > m.setAccessible(true); > > m2.invoke(obj); > > If this problem isn't fixed in the JDK, then I might have code that > works in JDK 9 and is broken when someone decides to re-implement > something directly using an internal package in JDK 10. > If you are in a position to change the implementation of the interpreted language, then there might be a general way to reflectively invoke methods on objects of unknown types that will always be the right way to invoke them. When looking up a static method in some class 'clzz' then the above code is ok: clzz.getMethod(name, parameterTypes...), but when looking up an instance method to be called upon an instance of some object, then something like the following could be used: import java.lang.reflect.Method; import java.lang.reflect.Modifier; import java.util.Arrays; public class Test { public static void main(String[] args) throws Exception { Class clzz = Class.forName("java.nio.channels.SocketChannel"); Method open = clzz.getMethod("open"); Object obj = open.invoke(null); Method isConn = getAccessibleMethod(Test.class, obj.getClass(), "isConnected"); // no need to invoke setAccessible System.out.println(isConn.invoke(obj)); } /** * Returns a public method in a public class or interface in a package * exported to the module of the caller class. * * @param caller the caller class that will invoke the method * @param clazz the runtime class of the object upon which the method * will be called * @param name the name of the method * @param parameterTypes the types of method parameters * @return a public method that is accessible to the caller class or * null if no such method exists */ public static Method getAccessibleMethod(Class caller, Class clazz, String name, Class... parameterTypes) throws NoSuchMethodException { Method res; // 1st lookup declared method if the class or interface is public // and its package is exported to the caller module if (Modifier.isPublic(clazz.getModifiers()) && clazz.getModule().isExported(clazz.getPackageName(), caller.getModule()) && (res = findPublicMethod(clazz.getDeclaredMethods(), name, parameterTypes)) != null) { return res; } // 2nd search the superclass recursively if there is one Class superClass = clazz.getSuperclass(); if (superClass != null && (res = getAccessibleMethod(caller, superClass, name, parameterTypes)) != null) { return res; } // finally search the directly implemented interfaces for (Class intf : clazz.getInterfaces()) { if ((res = getAccessibleMethod(caller, intf, name, parameterTypes)) != null) { return res; } } // no luck return null; } private static Method findPublicMethod(Method[] methods, String name, Class... parameterTypes) { Method res = null; for (Method m : methods) { if (Modifier.isPublic(m.getModifiers()) && m.getName().equals(name) && Arrays.equals(m.getParameterTypes(), parameterTypes) && (res == null || res.getReturnType().isAssignableFrom(m.getReturnType()))) { res = m; } } return res; } } This is similar logic as is used in Class::getMethod() but skips methods that are not accessible. Regards, Peter > -----Original Message----- > From: Peter Levart [mailto:peter.levart at gmail.com] > Sent: Friday, September 09, 2016 11:54 AM > To: Stephen Felts; jigsaw-dev at openjdk.java.net > Subject: Re: JDK9 encapsulation problem > > Hi Stephen, > > On 09/09/2016 04:30 PM, Stephen Felts wrote: > > > We have an application that is running into a problem with a utility > program. Below is a standalone reproducer. > > > > > > > > > > > > The program does not import the SPI package sun.nio.ch - it isn't > > > aware of > > > > > > it, and SocketChannel.isConnected() is a public method of a public > > > type. In > > > > > > short, it does not break any law of encapsulation, so call > > > > > > setAccessible(true) should be OK. > > Ok, but... > > > > > > > > > > > > import java.lang.reflect.Method; > > > > > > > > > > > > > > > > > > public class JDK9Nio { > > > > > > public static void main(String args[]) throws Exception { > > > > > > call(); > > > > > > } > > > > > > > > > > > > public static void call() throws Exception { > > > > > > Class clzz = Class.forName("java.nio.channels.SocketChannel"); > > > > > > Method open = clzz.getMethod("open"); > > > > > > Object obj = open.invoke(null); > > > > > > Method isConn = obj.getClass().getMethod("isConnected"); > > ...This is a classical reflection anti-pattern. What program should be > doing to call the public and exported SocketChannel.isConnected() > method is the following: > > Method isConn = SocketChannel.class.getMethod("isConnected"); > > obj.getClass().getMethod(...) is rarely what is desired. What you get > back is a Method object for method declared in a package-private class. > > That's why setAccessible() was needed. And now in JDK 9, this class is > also in a non-exported package, so setAccessible() does not help any > more. But I see your point. It worked before and is not working any > more... > > > > > > isConn.setAccessible(true); // OK with JDK8, fail with JDK9 > > > > > > System.out.println(isConn.invoke(obj)); > > > > > > } > > > > > > } > > > > > > > > > > > > > > > > > > java JDK9Nio > > > > > > Exception in thread "main" > > > java.lang.reflect.InaccessibleObjectException: Unable to make member > > > of class sun.nio.ch.SocketChannelImpl accessible: module java.base > > > does not export sun.nio.ch to unnamed module @3857f613 > > > > > > at > > > jdk.internal.reflect.Reflection.throwInaccessibleObjectException(java. > > > base at 9-ea/Reflection.java:414 ) > > > > > > at > > > > java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base at 9-e > > > > a/AccessibleObject.java:174) > > > > > > at > > > > java.lang.reflect.Method.checkCanSetAccessible(java.base at 9-ea/Method.j > > > > ava:192) > > > > > > at > > > > java.lang.reflect.Method.setAccessible(java.base at 9-ea/Method.java:186 > ) > > > > > > at JDK9Nio.call(JDK9Nio.java:14) > > > > > > at JDK9Nio.main(JDK9Nio.java:6) > > > > > > > > > > > > > > > > > > > > > > > > It's easy to say that the program should be re-written and the > setAccessible is not necessary but this is a utility program over > which the application has no control (a jython script). > > > > > > What's ugly is that the internal implementation is showing through > to the application. > > Maybe there could be a solution in supporting such sloppy programming > though. If the reflective invocation is performed to a virtual method, > then the JVM virtual dispatch chooses the method declared in the most > specific class regardless of what the Method object used is telling > about the method's declaring class. So if there exists at least one > matching method declared in the hierarchy of types comprising the > runtime type of the object upon which the method is being invoked, and > such method is accessible to the invoker, such invocation could be > allowed. The rationale is simple: if the invocation dispatches to the > same method for distinct Method objects, it should also succeed or not > succeed consistently regardless of which Method object was used to > perform the invocation. > > But such access check would surely be much slower. It's better to just > fix the program (if you can :-( ). > > Regards, Peter > > > > > > > > > > > > Many people especially tool makers have this problem: > > > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318 > > > > > > https://netbeans.org/bugzilla/show_bug.cgi?id=258952 > > > > > > https://netbeans.org/bugzilla/show_bug.cgi?id=262765 > > > > > > http://mail.openjdk.java.net/pipermail/quality-discuss/2015-November/0 > > > 00468.html > > > > > > https://community.oracle.com/thread/3937249 > > > > > > > > > > > > > From david.lloyd at redhat.com Fri Sep 9 21:26:11 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 9 Sep 2016 16:26:11 -0500 Subject: Using non-parallel custom class loaders for Layer configurations In-Reply-To: <1A4F37F8-5517-4582-91E0-EB1DDD697E8E@oracle.com> References: <37755b1d-252c-1ac9-ec8a-12ed150fa345@redhat.com> <789BC05B-7D50-40F7-9E79-270AA8881B32@oracle.com> <1A4F37F8-5517-4582-91E0-EB1DDD697E8E@oracle.com> Message-ID: <65db943d-46aa-8407-a307-0f71e227d08d@redhat.com> On 09/09/2016 02:05 PM, Mandy Chung wrote: > >> On Sep 9, 2016, at 8:44 AM, David M. Lloyd wrote: >> >> On 09/08/2016 06:48 PM, Mandy Chung wrote: >>> >>>> On Sep 8, 2016, at 3:29 PM, David M. Lloyd wrote: >>>> >>>> Would it be possible to include a method like this (pretty old patch I had laying around): >>>> >>>> diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >>>> index 1bb1580..3def10e 100644 >>>> --- a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >>>> +++ b/jdk/src/java.base/share/classes/java/lang/ClassLoader.java >>>> @@ -469,6 +477,15 @@ public abstract class ClassLoader { >>>> return lock; >>>> } >>>> >>>> + /** >>>> + * Determine whether this class loader is parallel-capable. >>>> + * >>>> + * @return {@code true} if the class loader is parallel-capable, {@code false} otherwise >>>> + */ >>>> + protected final boolean isParallelCapable() { >>>> + return ParallelLoaders.isRegistered(getClass()); >>>> + } >>>> + >>> >>> This seems a fine method to add. I think it can be a public method (I don?t see any reason it has to be protected) >> >> Great! Since it's such a small method though, would it be possible to just roll this change into some other changeset? I can't really contribute the change in any form other than a patch right now. > > I file a RFE and Brent Christian has agreed to work on it and will go through JDK 9 FC approval request. > https://bugs.openjdk.java.net/browse/JDK-8165793 Thanks! -- - DML From claes.redestad at oracle.com Sat Sep 10 15:12:33 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 10 Sep 2016 17:12:33 +0200 Subject: [MRJAR] Entry order matters? In-Reply-To: References: <223e2860-386f-fa40-7621-a01352130a68@oracle.com> <823816d2-3b34-5a2a-76d8-84f6123d276c@oracle.com> Message-ID: <57D422E1.8050906@oracle.com> This appears to be caused by a bug I inadvertently introduced in a startup optimization a while back; patch and extended tests are up for review on core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043476.html Thanks! /Claes On 2016-09-08 22:15, Robert Scholte wrote: > Confirmed there's an issue; jar should have been recognized as a > multirelease jar. > > https://bugs.openjdk.java.net/browse/JDK-8165723 > > > thanks, > Robert > > On Mon, 05 Sep 2016 09:10:56 +0200, Alan Bateman > wrote: > >> >> >> On 04/09/2016 21:56, Robert Scholte wrote: >>> : >>> >>>> Also if you "unzip -d " then does everything look okay? >>>> >>> >>> hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_failure.jar | grep >>> class >>> hboutemy testing: base/Base.class OK >>> hboutemy testing: META-INF/versions/9/mr/A.class OK >>> hboutemy testing: META-INF/versions/8/mr/A.class OK >>> hboutemy testing: mr/A.class OK >>> hboutemy $ unzip -t multirelease-0.8-SNAPSHOT_success.jar | grep >>> class >>> hboutemy testing: base/Base.class OK >>> hboutemy testing: META-INF/versions/8/mr/A.class OK >>> hboutemy testing: mr/A.class OK >>> hboutemy testing: META-INF/versions/9/mr/A.class OK >>> >>> Looks good to me. >> I think I need to see multirelease-0.8-SNAPSHOT_failure.jar to >> understand this as I suspect there is more going on that is obvious >> here. I'll see if I can duplicate it. >> >> -Alan From mark.reinhold at oracle.com Sun Sep 11 21:17:26 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 11 Sep 2016 14:17:26 -0700 Subject: Proposal for JPMS issue #ReflectiveAccessByInstrumentationAgents In-Reply-To: <57989BF7.4010808@redhat.com> References: <20160628144748.798133053eggemoggin.niobe.net> <577B7EC3.2050405@redhat.com> <57989BF7.4010808@redhat.com> Message-ID: <20160911141726.222597249eggemoggin.niobe.net> 2016/7/27 4:33:11 -0700, Andrew Dinn : > Regarding the proposed solution of adding method redefineModule to class > Instrumentation: > > I have a Proof Of Concept implementation which shows that that this > solution works for my agent and does not impose unworkable restrictions > on its operation or use. > > ... Excellent -- thanks very much for the detailed evaluation! - Mark From adinn at redhat.com Mon Sep 12 09:03:32 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 12 Sep 2016 10:03:32 +0100 Subject: Proposal for JPMS issue #ReflectiveAccessByInstrumentationAgents In-Reply-To: <20160911141726.222597249eggemoggin.niobe.net> References: <20160628144748.798133053eggemoggin.niobe.net> <577B7EC3.2050405@redhat.com> <57989BF7.4010808@redhat.com> <20160911141726.222597249eggemoggin.niobe.net> Message-ID: <0b7e6d49-b74a-dd2d-fa56-5a075c61bd63@redhat.com> On 11/09/16 22:17, mark.reinhold at oracle.com wrote: > 2016/7/27 4:33:11 -0700, Andrew Dinn : >> Regarding the proposed solution of adding method redefineModule to class >> Instrumentation: >> >> I have a Proof Of Concept implementation which shows that that this >> solution works for my agent and does not impose unworkable restrictions >> on its operation or use. >> >> ... > > Excellent -- thanks very much for the detailed evaluation! No problem and thanks in return to all in the Jigsaw team who helped me arrive at this resolution of the issue. In the absence of follow-up by other agent implementors it's hard to be sure this POC will work for their needs. However, it does seem to me to be a generally applicable solution. Assuming no other agent implementor does follow up to the contrary then I hope my solution serves to allow the issue to be agreed as resolved. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From sundararajan.athijegannathan at oracle.com Mon Sep 12 12:32:26 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Sep 2016 18:02:26 +0530 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8165772 This VersionCheck.java test failed after main class was added to nashorn modules. VersionCheck expects all jdk/bin tools to be derived from the standard launcher. But, jlink generates shell scripts and batch files for modules with main class. I'm reverting back nashorn module main class addition makefile change and also removing VersionCheck from ProblemList.txt: Webrevs: Top: http://cr.openjdk.java.net/~sundar/8165772/top/webrev.02/ Jdk: http://cr.openjdk.java.net/~sundar/8165772/jdk/webrev.02/ I'm withdrawing my earlier jlink fix attempt: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009339.html Thanks, -Sundar From Alan.Bateman at oracle.com Mon Sep 12 12:37:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Sep 2016 13:37:33 +0100 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: References: Message-ID: <626952e4-3810-251d-8de1-a0fcadb7759d@oracle.com> On 12/09/2016 13:32, Sundararajan Athijegannathan wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8165772 > > This VersionCheck.java test failed after main class was added to nashorn > modules. VersionCheck expects all jdk/bin tools to be derived from the > standard launcher. But, jlink generates shell scripts and batch files > for modules with main class. I'm reverting back nashorn module main > class addition makefile change and also removing VersionCheck from > ProblemList.txt: > > Webrevs: > > Top: http://cr.openjdk.java.net/~sundar/8165772/top/webrev.02/ > > Jdk: http://cr.openjdk.java.net/~sundar/8165772/jdk/webrev.02/ > > I'm withdrawing my earlier jlink fix attempt: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009339.html > Looks okay (and I agree that dropping this is the right thing to do as jlink generating launcher scripts is just isn't aligned with modules that include pre-built launchers). -Alan From james.laskey at oracle.com Mon Sep 12 12:44:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 12 Sep 2016 09:44:12 -0300 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: References: Message-ID: <83DDDF18-D3D5-438B-A196-705EEDA65380@oracle.com> +1 > On Sep 12, 2016, at 9:32 AM, Sundararajan Athijegannathan wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165772 > > This VersionCheck.java test failed after main class was added to nashorn > modules. VersionCheck expects all jdk/bin tools to be derived from the > standard launcher. But, jlink generates shell scripts and batch files > for modules with main class. I'm reverting back nashorn module main > class addition makefile change and also removing VersionCheck from > ProblemList.txt: > > Webrevs: > > Top: http://cr.openjdk.java.net/~sundar/8165772/top/webrev.02/ > > Jdk: http://cr.openjdk.java.net/~sundar/8165772/jdk/webrev.02/ > > I'm withdrawing my earlier jlink fix attempt: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009339.html > > Thanks, > > -Sundar > From mark.reinhold at oracle.com Mon Sep 12 15:20:15 2016 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 12 Sep 2016 08:20:15 -0700 (PDT) Subject: More proposals for open JPMS issues Message-ID: <20160912152015.CC678CD09E@eggemoggin.niobe.net> FYI, I've just posted new or revised proposals for some of the open issues in the JPMS specification: #ReflectiveAccessToNonExportedTypes & #AwkwardStrongEncapsulation http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000390.html #AddExportsInManifest http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000391.html #ResourceEncapsulation & #ClassFilesAsResources http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000392.html #VersionsInModuleNames http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000393.html #ClassLoaderNames http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000394.html #ServiceLoaderEnhancements http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000395.html Links to the proposals are also available in the issue summary [1]. The first proposal, for #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation, is likely to be of the broadest interest since it makes significant changes to the syntax and semantics of module declarations. The latter issue is a new issue, reported by Martin Buchholz and Aleksey Shipilev, and is summarized thus: #AwkwardStrongEncapsulation --- A non-public element of an exported package can still be accessed via the `AccessibleObject::setAccessible` method of the core reflection API. The only way to strongly encapsulate such an element is to move it to a non-exported package. This makes it awkward, at best, to encapsulate the internals of a package that defines a public API. The present design suffers this limitation due to an earlier compromise made to accommodate reflective access by frameworks, but experience has now shown that to be a problematic approach. It would be unfortunate indeed to bake this limitation into the module system for all time: It would make it much more difficult for developers to strongly encapsulate the internals of their own modules, yet enabling such encapsulation is one of the primary goals of this project. Thus this new proposal, which introduces the concepts of weak modules and private exports and removes the previously-proposed notion of dynamic exports. This has taken some time to work out but, in the end, appears to achieve a better balance of usability, ease of migration, and expressive power. Comments and discussion are welcome here on jigsaw-dev but, as usual, the best way to ensure that the EG sees any specific comment is to send it to the EG's "suggestion box" list, jpms-spec-comments [2]. If you comment on one of these proposals, via any channel, please include its hashtag in the subject line of your message to simplify tracking. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ [2] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments From scolebourne at joda.org Mon Sep 12 17:52:18 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 12 Sep 2016 18:52:18 +0100 Subject: Proposal: #VersionsInModuleNames In-Reply-To: <20160912151101.BA3D0CD08E@eggemoggin.niobe.net> References: <20160912151101.BA3D0CD08E@eggemoggin.niobe.net> Message-ID: On 12 September 2016 at 16:11, Mark Reinhold wrote: > - Revise the automatic-module naming algorithm implemented by `javac` > at compile time and the `ModuleFinder::of` method [2] at run time. > It will now strip any trailing digits and period characters that > remain after removing the version component, if any, from the name > of the original JAR file. Thus `foo-bar-1.2.3.jar` becomes the > automatic module named `foo.bar` with the version string `1.2.3`, > and `foo-bar42.jar` becomes the automatic module named `foo.bar` > with no version string. I will note that this would cause problems for Apache Commons Lang. The original release of commons uses the package org.apache.commons.lang and has a jar file of commons-lang-2.6.jar [1] The later release of commons uses the package org.apache.commons.lang3 and has a jar file of commons-lang3-3.4.jar [2] Dropping the number immediately after the name will break this, and it is not unusual for applications to have both lang and lang3 in the classpath. Stephen [1] http://repo1.maven.org/maven2/commons-lang/commons-lang/2.6/ [2] http://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.4/ From scolebourne at joda.org Mon Sep 12 21:59:12 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 12 Sep 2016 22:59:12 +0100 Subject: Closing out some open issues In-Reply-To: <57d5cbc5.c6b91c0a.c2828.7027SMTPIN_ADDED_BROKEN@mx.google.com> References: <57d5cbc5.c6b91c0a.c2828.7027SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On 11 September 2016 at 22:24, wrote: > Proposals for the following issues have been available for evaluation > and experimentation for quite a while now. Most responses have been > positive and there have been no strong objections, so I've updated > the issue list [1] to mark them as closed. > > #BootstrapClassLoaderSearchInJVMTI > #ClassFileAccPublic > #CompileTimeDependences (`requires static`) > #CustomizableAutomaticModuleNameMapping > #ModuleAnnotations > #ModuleDeprecation > #ReflectiveAccessByInstrumentationAgents > > Not everyone was thrilled with the choice of `static` as the modifier > on `requires` directives that indicates a compile-time dependence, but > no obviously-better choice has emerged. Given that "exports dynamic" has gone, there is even less reason to use "static" (as there is no "dynamic" equivalent). The simplest alternative is "requires optional", which fits with the existing terminology used by maven for many years and more clearly indicates that users cannot rely on the dependency. Stephen From scolebourne at joda.org Mon Sep 12 22:08:41 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 12 Sep 2016 23:08:41 +0100 Subject: Proposal: #ServiceLoaderEnhancements In-Reply-To: <20160912151301.C2B83CD096@eggemoggin.niobe.net> References: <20160912151301.C2B83CD096@eggemoggin.niobe.net> Message-ID: My preference of these three options is option 2. However, I would prefer to see the method name be defined by the module definition as previously suggested [1]: module { provides java.sql.Driver with com.mysql.jdbc.Driver::instance; } This would allow ::staticMethod or ::staticConstant, and avoid hard-coding "provider" as a special method name. (For my motivating use case, the Chronology classes of ThreeTen-Extra [2] it would be distracting to have a method named provider(). While a separate class in a non-exported package would be possible to hold the provider() method, as a solution that seems like overkill relative to the syntax above.) Stephen [1] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-July/000535.html [2] https://github.com/ThreeTen/threeten-extra/tree/master/src/main/java/org/threeten/extra/chrono On 12 September 2016 at 16:13, Mark Reinhold wrote: > Issue summary > ------------- > > #ServiceLoaderEnhancements --- The module system encourages the use of > services for loose coupling, but the `ServiceLoader` class is not very > flexible. Consider enhancing it so that (1) neither a provider class > nor its no-args constructor need be declared `public`, (2) a provider > can be a singleton, or perhaps a collection of singletons, and (3) the > classes of the available providers can be inspected and selected prior > to instantiation. [13] > > Proposal > -------- > > (1) No change: Continue to require service-provider classes, and their > no-args constructors, to be public. > > Providers on the class path, and their no-args constructors, must > always be public. Allowing a class-path provider or its no-args > constructor to be non-public introduces a security risk, since an > adversary could place a `META-INF/services` entry elsewhere on the > class path in order to force that otherwise-inaccessible > constructor to be invoked. > > For providers in named modules, allowing non-public provider > classes and non-public no-args constructors isn't really necessary > and is, in some ways, counterproductive. In a named module a > provider class, and its constructor, can be encapsulated by placing > the provider in an unexported package. Having to declare the > provider class and its no-args constructor `public` is a useful > declaration of intent, since they will be accessed by the service > loader itself, and hence useful documentation. > > (2) Revise the `ServiceLoader` class so that if a candidate provider > class in a named module has a no-args public static method named > `provider` then that method is invoked and its result is taken as > the provider object. An exception is thrown if the method does > not have an appropriate return type. A static `provider` method > can either return a singleton or act as a factory method. If the > candidate provider class does not have such a method then its > public no-args constructor, if any, is invoked, per (1) above. > > (An alternative is to use an annotation, say `@Provider`, to > identify provider-containing fields or provider-returning methods. > The cost of loading the annotation-reading code into the JVM is, > however, nontrivial, and since services are used widely within the > JDK itself we'd prefer not to impose that overhead on all > applications.) > > (3) Decouple the loading of provider classes from the instantiation of > such classes: Introduce a new `ServiceLoader.Provider` interface > that pairs a provider class with a method to instantiate that > provider, and add a `stream()` method that returns a stream of > objects implementing that interface. A client can then filter > providers by inspecting the elements of the stream, examining each > provider class and perhaps the annotations thereon, and then > instantiating the class if appropriate. (Draft Javadoc source > attached below.) > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ServiceLoaderEnhancements > > -- > > /** > * Represents a service provider located by {@code ServiceLoader}. > * > *

When using a loader's {@link ServiceLoader#stream() stream()} method > * then the elements are of type {@code Provider}. This allows processing > * to select or filter on the provider class without instantiating the > * provider.

> * > * @param The service type > * @since 9 > */ > public static interface Provider extends Supplier { > > /** > * Returns the provider class. There is no guarantee that this type is > * accessible and so attempting to instantiate it, by means of its > * {@link Class#newInstance() newInstance()} method for example, will > * fail when it is not accessible. The {@link #get() get()} method > * should instead be used to obtain the provider. > * > * @return The provider class > */ > Class type(); > > /** > * Returns an instance of the provider. > * > * @return An instance of the provider. > * > * @throws ServiceConfigurationError > * If the service provider cannot be instantiated. The error > * cause will carry an appropriate cause. > */ > @Override S get(); > > } > > /** > * Returns a stream that lazily loads the available providers of this > * loader's service. The stream elements are of type {@link Provider > * Provider}, the {@code Provider}'s {@link Provider#get() get} method > * must be invoked to get or instantiate the provider. > * > *

When processing the stream then providers that were previously > * loaded by stream operations are processed first, in load order. It then > * lazily loads any remaining providers. If a provider class cannot be > * loaded, can't be assigned to the service type, or some other error is > * thrown when locating the provider then it is wrapped with a {@code > * ServiceConfigurationError} and thrown by whatever method caused the > * provider to be loaded.

> * > *

If this loader's provider caches are cleared by invoking the {@link > * #reload() reload} method then existing streams for this service > * loader should be discarded.

> * > *

The following examples demonstrate usage. The first example > * creates a stream of providers, the second example is the same except > * that it sorts the providers by provider class name (and so locate all > * providers). > *

{@code
>      *    Stream providers = ServiceLoader.load(CodecSet.class)
>      *            .stream()
>      *            .map(Provider::get);
>      *
>      *    Stream providers = ServiceLoader.load(CodecSet.class)
>      *            .stream()
>      *            .sorted(Comparator.comparing(p -> p.type().getName()))
>      *            .map(Provider::get);
>      * }
> * > * @return A stream that lazily loads providers for this loader's service > * > * @since 9 > */ > public Stream> stream() { ... } From scolebourne at joda.org Mon Sep 12 22:11:46 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 12 Sep 2016 23:11:46 +0100 Subject: Proposal: #AddExportsInManifest In-Reply-To: <20160912150901.B13EACD084@eggemoggin.niobe.net> References: <20160912150901.B13EACD084@eggemoggin.niobe.net> Message-ID: This seems reasonable. Stephen On 12 September 2016 at 16:09, Mark Reinhold wrote: > Issue summary > ------------- > > #AddExportsInManifest -- Using a command-line option such as > `--add-exports` to make JDK-internal APIs available to existing code is > difficult, if not impossible, for applications that are delivered as > executable JAR files. To ease migration, consider allowing such a JAR > file to include the equivalent of such options in its `MANIFEST.MF` > file. [1] > > Proposal > -------- > > Define two new JAR-file manifest attributes [2], `Add-Exports` and > `Add-Exports-Private`. Each attribute can occur at most once, in the > main section of a `MANIFEST.MF` file. The parameter of each attribute is > a space-separated list of slash-separated module-name/package-name pairs. > At run time the presence of a pair `m/p` in the value of each attribute > is interpreted as follows: > > - If `m/p` is listed in the value of the `Add-Exports` attribute then > package `p` of module `m` is exported to all unnamed modules, as if > by invoking the `Module::addExports` method. This makes all of > package `p`'s public elements immediately accessible to code in > unnamed modules. > > - If `m/p` is listed in the value of the `Add-Exports-Private` > attribute then package `p` of module `m` is exported to all unnamed > modules and its non-public elements are made available for deep > reflection, as if by invoking the `Module::addExportsPrivate` method > [3]. This makes all of package `p`'s public elements immediately > accessible to code in the unnamed module, and all of its non-public > elements accessible to code in unnamed modules via the > `setAccessible` method of the core reflection API. > > In contrast to language-level module declarations some sloppiness is > allowed in the values of these attributes, as is traditional in JAR-file > manifests. A particular module-name/package-name pair can be listed more > than once in either of these attributes. It can also be listed in both > attributes, in which case the package will be exported privately. A > module or package specified in such a pair need not actually exist in > the run-time module graph. > > These attributes are interpreted only in the main executable JAR file > of an application, i.e., in the JAR file specified to the `-jar` > command-line option of typical Java run-time launchers. They are > ignored in all other JAR files. > > As an example, the Spring Boot framework [4] uses `setAccessible` to > access a protected `defineClass` method of `java.lang.ClassLoader` and > a private constructor of `java.lang.invoke.MethodHandles.Lookup`. An > application that uses Spring Boot can be made to work by adding the > line > > Add-Exports-Private: java.base/java.lang java.base/java.lang.invoke > > to the `MANIFEST.MF` file of its executable JAR file. > > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest > [2] http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html#JAR_Manifest > [3] See the nearby proposal for #ReflectiveAccessToNonExportedTypes > [4] http://projects.spring.io/spring-boot/ From scolebourne at joda.org Mon Sep 12 22:58:41 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 12 Sep 2016 23:58:41 +0100 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> Message-ID: Quite a radical proposal. Overall, I think it is better, although I do have semantic and syntax concerns. I'm happy that there is a way to achieve real strong encapsulation. This seems like a good thing and will be a benefit in the long run. For the weak modules, the proposal does not provide a way to have packages exposed for runtime use, but not hidden at compile time. Given the benefits of hiding internal classes from IDEs, this seems rather unfortunate. Here is my counter proposal, hopefully a relatively small conceptual change: The proposal module: weak module foo.bar { // No exports requires hibernate.core; requires hibernate.entitymanager; } could be written with an alternative syntax of (same semantics): module foo.bar { exports private *; requires hibernate.core; requires hibernate.entitymanager; } Taking this one step further, we could separate what is exported (public things) from what is exposed (at runtime): module foo.bar { exports *; exposes *; requires hibernate.core; requires hibernate.entitymanager; } (again, this is the same semantics as the previous two, just different syntax) This would then provide a straightforward way to control exports tightly but still expose everything for reflection: module foo.bar { exports foo.bar.core; exposes *; requires hibernate.core; requires hibernate.entitymanager; } - "exports" defines whether the public elements can be accessed - "exposes" defines whether the package can be accessed for reflection - there may be a one * exports clause or zero to many package name ones, but not both types - there may be a one * exposes clause or zero to many package name ones, but not both types - a package may be listed in both exports and exposes, they are orthogonal - the "to" clause would apply to exports and exposes, but only with package names The above does not deviate radically from today's proposal, yet offers a clearer syntax more power and simpler migration from weak to strong encapsulation. FWIW, I'm doing a presentation on modules on Wednesday, and I think the above would be easier to explain than the "weak" keyword. Stephen On 12 September 2016 at 16:08, Mark Reinhold wrote: > Issue summary > ------------- > > #ReflectiveAccessToNonExportedTypes --- Some kinds of framework > libraries require reflective access to members of the non-exported > types of other modules; examples include dependency injection (Guice), > persistence (JPA), debugging tools, code-automation tools, and > serialization (XStream). In some cases the particular library to be > used is not known until run time (e.g., Hibernate and EclipseLink both > implement JPA). This capability is also sometimes used to work around > bugs in unchangeable code. Access to non-exported packages can, at > present, only be done via command-line flags, which is extremely > awkward. Provide an easier way for reflective code to access such > non-exported types. [1] > > #AwkwardStrongEncapsulation --- A non-public element of an exported > package can still be accessed via the `AccessibleObject::setAccessible` > method of the core reflection API. The only way to strongly > encapsulate such an element is to move it to a non-exported package. > This makes it awkward, at best, to encapsulate the internals of a > package that defines a public API. [2] > > Proposal > -------- > > (Warning: This is somewhat long, and in the end it affects both `exports` > and `requires` directives.) > > Extend the language of module declarations with the concept of _weak > modules_. Weak modules make it easy to modularize components whose > internals will be accessed by reflection-based frameworks. Every > package in a weak module has the following properties: > > (A) It is exported at both compile time and run time, as if by an > `exports` directive, and > > (B) Its non-public elements are available for _deep_ reflection, i.e., > at run time they can be made accessible to code outside the module > via the `AccessibleObject::setAccessible` method of the core > reflection API. > > In other words, every type defined in a weak module, whether public or > not, is subject to exactly the same access checks as in Java SE 8 and > earlier releases. > > A weak module is declared by placing the modifier `weak` before the > `module` keyword. The declaration of a weak module cannot contain any > explicit `exports` directives. If the `weak` modifier does not appear > before the `module` keyword then the declared module is _strong_, and > it can contain explicit `exports` directives. > > Suppose we have a module `foo.bar` which has an internal package > `com.foo.bar.model` that contains entity classes to be manipulated by > Hibernate, via core reflection. Then the module declaration > > weak module foo.bar { > // No exports > requires hibernate.core; > requires hibernate.entitymanager; > } > > exports the public types in `com.foo.bar.model`, and those of any other > packages, in all phases. It additionally makes all non-public elements > of all packages available for deep reflection, enabling Hibernate to > access such elements in the `com.foo.bar.model` package via the > `setAccessible` method. > > Weak modules simplify the process of migrating to modules. The steps > to convert an existing component into a module were, previously: > > (1) Make any changes necessary to get it working as an automatic > module (e.g., eliminate duplicate packages), and then > > (2) Write an explicit module declaration, which entails identifying > both the component's dependences (`requires`) and the packages > whose public types are to be made available to other modules > (`exports`). > > With weak modules we can now divide the second step into two steps: > > (2a) Write an explicit module declaration for a weak module, which > entails identifying just the component's dependences (`requires`). > > (2b) Convert the weak module into a strong module, which entails > identifying the packages of the component whose public types > are to be made available to other modules (`exports`). > > In other words, weak modules make it possible to focus first upon the > reliable configuration of a module (`requires`), and then later think > about its strong encapsulation (`exports`). > > Weak modules are "weak" in what they export, but they remain subject > to all of the constraints required to achieve reliable configuration. > They do not read the unnamed module (i.e., the class path), they do not > allow cycles in the module graph, and they do not allow split packages. > Weak modules read named modules only as indicated by their `requires` > directives, and they consume and provide services only as indicated by > their `uses` and `provides` directives. > > * * * > > In a strong module, an ordinary `exports` directive exports a package at > both compile time and run time (property (A) above) but does not make its > non-public types available for deep reflection (B). In order to enable a > package in a strong module to be exported in the same way as in a weak > module we introduce the per-export modifier `private` to denote this > second property. > > If the above weak `foo.bar` module, e.g., contains some other packages > besides `com.foo.bar.model`, and we wish to encapsulate those packages, > we can convert it into a strong module with the declaration > > module foo.bar { > exports private com.foo.bar.model; > requires hibernate.core; > requires hibernate.entitymanager; > } > > Now Hibernate can still access any public or non-public entity classes in > the `com.foo.bar.model` package, but all the other packages are strongly > encapsulated. > > The `private` modifier should generally not be used to export a package > containing an API, since normally an API's internal implementation > details should be strongly encapsulated. It may, however, be useful for > legacy APIs whose internals are known to be accessed by existing code. > > Every package in a weak module, an automatic module, or an unnamed module > is exported as if by an `exports private` directive. > > To ensure the integrity of the platform we expect few, if any, packages > in the JDK itself to be exported with the `private` modifier. > > * * * > > The new `private` modifier can also be used with qualified exports, > though they interact with unqualified exports in a non-obvious way. > > - If you write `exports p` then you can also write `exports private > p to m`, so that code in module `m` can access the non-public types > of `p` via deep reflection but code outside of `m` can only access > the public types of `p`. > > - If you write `exports p to m1` then you can also write `exports > private p to m2`, so that code in `m2` can access the non-public > types of `p` via deep reflection, code in `m1` can access the > public types of `p`, but no code in any other module can access > any of the types of `p`. > > - If you write `exports private p` then you cannot also have a > qualified export of `p`, since code in all other modules already > has access to the non-public types of `p` via deep reflection. > > Put informally, you can give your friends additional access, but you > can't discriminate against them by giving them less access than everyone > else. > > As before, duplicate `exports` directives are not permitted, in order to > ensure easy readability. At most one `exports` directive is relevant to > any given package/module pair, and it's easy to determine which one. > > * * * > > The introduction of `private` as a modifier of `exports` directives calls > the existing syntax of `requires public` even more strongly into question > than before. A module declaration of the form > > module foo.bar { > exports private com.foo.bar.baz; > requires public java.sql; > } > > is likely to be very confusing to an uninformed reader. The `private` > modifier in the `exports` directive means that the private elements of > the `com.foo.bar.baz` package are exported for deep reflection at run > time. The `public` modifier in the `requires` directive, however, does > not mean that the public elements of the `java.sql` module are needed by > this module; that is true of any plain `requires` directive. It means > that, additionally, any client of this module is granted implied > readability to the `java.sql` module, thereby gaining access to all of > its exported types. > > To reduce this confusion we rename the `public` modifier in `requires` > directives to `transitive`. Thus the above example becomes > > module foo.bar { > exports private com.foo.bar.baz; > requires transitive java.sql; > } > > This is potentially confusing in a different way, since in mathematics > the term "transitive" is usually applied to an entire relation rather > than to three specific elements of a set. Its use here does not, in > particular, mean that the resolver does not interpret plain `requires` > directives when computing the transitive closure of a set of root > modules. "Transitive" as used here is in the more abstract sense, > expressing the notion of conveying a property -- in this case, the > readability of the required module -- from one thing to another. > > > Notes > ----- > > - This is significantly different from the first proposal [3]. It adds > the notion of weak modules, to ease migration, and also the notion of > exporting a package without enabling deep reflection, to strengthen > encapsulation. > > - This proposal removes the notion of dynamic exports, which in the > presence of private exports would introduce considerable complexity > into the interactions between qualified and unqualified exports. > This means that it is no longer possible to export a package only at > run time, so it is no longer possible for the author of a module to > express the intent that the types of a non-API package are meant to > be available to frameworks for deep reflection at run time but > inaccessible at compile time. The dynamic-export feature could, if > needed, be added in a future release. > > - A strong module with no exports makes no types accessible to code in > other modules while a weak module makes all of its types accessible, > both directly and via deep reflection. The declarations of such > modules are, however, visually similar since most of their text lies > between the curly braces: > > module m1 { > requires ...; > uses ...; > provides ...; > } > > weak module m2 { > requires ...; > uses ...; > provides ...; > } > > We suspect that this visual similarity will not cause much confusion > in practice since strong modules that export no packages will be very > rare. > > - If a container is to ensure that a package in an application module > is available for deep reflection only by a trusted framework then it > can arrange for that by rewriting that module's descriptor, as > suggested previously [4], to insert the appropriate qualified private > export. If there is a possibility that two modules will need to > export a package of the same name to the same framework module, as > suggested by Jason Greene [5], then the container should instead > inject a small class into each module whose static initializer > invokes the `Module::addExports` method in order to export the > package to the framework module. There is no need any longer for > the resolution algorithm to take this scenario into account [6]. > > - This proposal primarily addresses "friendly" uses of reflection, such > as dependency injection and persistence, in which the author of a > module knows in advance that one or more packages must be exported at > run time for deep reflective access by frameworks. Intrusive access > to arbitrary packages of arbitrary modules by, e.g., serialization > frameworks or debugging tools, will still require the use of sharp > knives such as the `--add-exports` command-line option, the legacy > unsupported `sun.misc.Unsafe` API and related APIs, or JVM TI. > > - Using the `--add-exports` option or its equivalent remains awkward, > and sometimes it's the only way out. To ease migration it's worth > considering some way for an application packaged as a JAR file to > include such options in its `MANIFEST.MF` file, as suggested by Simon > Nash [7]. This is tracked as #AddExportsInManifest [8]. > > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes > [2] http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation > [3] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-June/000307.html > [4] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008637.html > [5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008641.html > [6] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008727.html > [7] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005745.html > [8] http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest From sander.mak at luminis.eu Tue Sep 13 06:33:02 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Tue, 13 Sep 2016 06:33:02 +0000 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> Message-ID: <7BA3B0B5-18CE-4217-8EC4-0A6D14CC88AE@luminis.eu> > On 13 Sep 2016, at 00:58, Stephen Colebourne wrote: > > > For the weak modules, the proposal does not provide a way to have > packages exposed for runtime use, but not hidden at compile time. > Given the benefits of hiding internal classes from IDEs, this seems > rather unfortunate. Major +1. With private exports, we need to rely on will-power and out-of-band knowledge again to prevent people from shooting themselves in the foot. Given the prevalence of applications using dependency injection frameworks (hence using `exports private), this is a non-trivial concession. > Here is my counter proposal, hopefully a > relatively small conceptual change: Not sure whether introducing a new top-level keyword (exposes) is better than adding a modifier keyword to exports. As was the case with `exports dynamic`, but a better name might be `exports runtime` since that's how we are referring to its effects in this whole discussion. For the rest, I agree with the gist of the counter proposal. Sander From paul.bakker at luminis.eu Tue Sep 13 07:29:43 2016 From: paul.bakker at luminis.eu (Paul Bakker) Date: Tue, 13 Sep 2016 07:29:43 +0000 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: <7BA3B0B5-18CE-4217-8EC4-0A6D14CC88AE@luminis.eu> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <7BA3B0B5-18CE-4217-8EC4-0A6D14CC88AE@luminis.eu> Message-ID: Another +1 for the return of dynamic exports. Frameworks using reflection are such a common case that if dynamic exports are not available, users will either create weak modules for all their code, or they have to export packages that they would rather not export. While "dynamic export" is still not true encapsulation, it is a nice tradeoff between compatibility with existing frameworks and encapsulation. The exact keyword is less important to me. "dynamic" made sense to me, so would "runtime". Both "weak" modules and the alternative proposed by Stephen would be ok. I somewhat like "weak" because it communicates that it is probably not an end solution, but a migration step instead. Paul On Tue, Sep 13, 2016 at 8:33 AM Sander Mak wrote: > > > On 13 Sep 2016, at 00:58, Stephen Colebourne > wrote: > > > > > > For the weak modules, the proposal does not provide a way to have > > packages exposed for runtime use, but not hidden at compile time. > > Given the benefits of hiding internal classes from IDEs, this seems > > rather unfortunate. > > Major +1. With private exports, we need to rely on will-power and > out-of-band knowledge again to prevent people from shooting themselves in > the foot. Given the prevalence of applications using dependency injection > frameworks (hence using `exports private), this is a non-trivial concession. > > > Here is my counter proposal, hopefully a > > relatively small conceptual change: > > Not sure whether introducing a new top-level keyword (exposes) is better > than adding a modifier keyword to exports. As was the case with `exports > dynamic`, but a better name might be `exports runtime` since that's how we > are referring to its effects in this whole discussion. For the rest, I > agree with the gist of the counter proposal. > > > Sander From sundararajan.athijegannathan at oracle.com Tue Sep 13 09:41:39 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 13 Sep 2016 15:11:39 +0530 Subject: RFR 8163320: JAVA_VERSION in release file should come from java.base module In-Reply-To: <174D8EFE-F40F-44BD-9699-FDE0952DE0BA@oracle.com> References: <640724e0-6d49-81be-3482-74dbc001d4ba@oracle.com> <174D8EFE-F40F-44BD-9699-FDE0952DE0BA@oracle.com> Message-ID: <8fcd1be5-c101-06bc-0f33-ccbd55d192f8@oracle.com> Modified existing test to check quotes around properties added by jlink: Updated webrevs: jdk: http://cr.openjdk.java.net/~sundar/8163320/jdk/webrev.02/ Top: http://cr.openjdk.java.net/~sundar/8163320/top/webrev.02/ Thanks -Sundar On 9/9/2016 9:07 PM, Mandy Chung wrote: > Looks good. > > Is there an existing test to check the content of `release` file? It would be good to have a test to sanity test a few properties and its quoted value. > > Mandy > >> On Sep 9, 2016, at 6:02 AM, Sundararajan Athijegannathan wrote: >> >> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8163320 >> >> jdk repo: >> >> http://cr.openjdk.java.net/~sundar/8163320/jdk/ >> >> * JAVA_VERSION is derived from module-info of java.base >> >> * adding quotes around all 'release' properties >> >> top repo: >> >> http://cr.openjdk.java.net/~sundar/8163320/top/webrev.01/ >> >> Makefile changes to avoid generating OS_NAME, JAVA_VERSION etc. - as >> jlink takes care of those. >> >> Thanks >> >> -Sundar >> From adinn at redhat.com Tue Sep 13 14:28:34 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 13 Sep 2016 15:28:34 +0100 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports Message-ID: <34486f5e-53cc-33dc-c0fa-395940ede36b@redhat.com> I understand the motivation for this change from the point of view of normal application operation. It looks to me to be in many ways an improvement on the previous proposal (dynamic exports). However, I don't really know whether it is adequate to the needs of middleware. So, I will leave it up to my colleagues at Red Hat to comment on that. I am replying merely because I am concerned to ensure that this proposal does not invalidate the solution proposed for #ReflectiveAccessByInstrumentationAgents. The latter solution provided agents with a new method on class Instrumentation void redefineModule(Module module, Set extraReads, Map> extraExports, Set> extraUses, Map, Set>> extraProvides) allowing the exports relationship to be extended. So, with that method in place let us assume module M contains package P, the agent trusts module M' and M does not currently export P to M' then an agent can use it method to add an export M exports P to M' The immediate question is 1) Will the agent be able add an export relationship M exports private P to M' The bonus question is essentially the same as the first but in a slightly different circumstance. Let us instead assume that module M contains package P, the agent trusts module M' and M currently exports P to M' but does not export private P to M' (n.b. this will really only be of relevance where M exports P to all modules but does not export private P to all modules) 2) Will the agent be able to upgrade the export relationship from M exports P to M' to M exports private P to M' If the API method is indeed to be updated so as to enable a yes answer to these two questions then the existing solution will still stand. If not then the original problem still needs resolving. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jan.lahoda at oracle.com Tue Sep 13 14:28:36 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 13 Sep 2016 16:28:36 +0200 Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <576406A3.10008@oracle.com> References: <575EDB5C.5060601@oracle.com> <575FF892.90608@oracle.com> <576406A3.10008@oracle.com> Message-ID: <57D80D14.3070206@oracle.com> Hello, I've updated the patch to the current situation. The top-level repository patch is here: http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/ Langtools repository patch is here: http://cr.openjdk.java.net/~jlahoda/8153362/langtools.04-phase2/ Does this look OK? Thanks, Jan On 17.6.2016 16:18, Jan Lahoda wrote: > Hi, > > I've updated the patches, reflecting the feedback so far. > > The langtools change is now split into two parts, one is only adding the > new lint key (but no checks are actually performed): > http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase1/ > > And the second part is adding the checks: > http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase2/ > > We could push the first part first, and the second one together with > other changes later, so that the repositories don't have to be updated > in a lockstep. > > In addition to the langtools changes, only the top-level repository > needs to be changed now, to disable the checks in some modules: > http://cr.openjdk.java.net/~jlahoda/8153362/top-level.01/ > > Any feedback is welcome! > > Thanks, > Jan > > On 14.6.2016 14:29, Jan Lahoda wrote: >> Hi Alan, >> >> On 14.6.2016 12:57, Alan Bateman wrote: >>> On 13/06/2016 17:12, Jan Lahoda wrote: >>> >>>> Hello, >>>> >>>> There is: >>>> https://bugs.openjdk.java.net/browse/JDK-8153362 >>>> >>>> which is about a new warning that should be produced by javac when >>>> exported API refers to types not exported/accessible to the API >>>> clients. >>>> >>>> I've put my current javac change here: >>>> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/ >>> Did you have a short list of names for the lint option before deciding >>> on "unexportedinapi"? If time has already been put into this and this is >> >> I had a few (e.g. "publishingunexported"), but none of them particularly >> nice. >> >>> the best of a bad bunch then ignore my mail. I bring it up because it >>> feels more like a "potentiallynotaccessible" or "notaccessible" or >>> "leaksnotaccessible". For the cases where we have ended up with >> >> I like "leaksnotaccessible". Unless there would be better ideas or >> objections, I'd go with that. Thanks for the ideas! >> >>> protected fields in public classes but the field type is package-private >>> then the field is never accessible. For the JSObject.getWindow case then >>> consumers will need to require java.desktop to use this method. >>> >>> Related is the description: >>> >>> javac.opt.Xlint.desc.unexportedinapi=\ >>> Warn about use of types not visible to clients in exported API >>> >>> Shouldn't get say something about the type potentially not accessible >>> rather than visible? >> >> Yes, it should. I'll fix that. Thanks for catching that. >> >> Jan >> >>> >>> -Alan >>> >>> PS: You asked about the JVMCI classes in the hotspot repo. While this >>> might look strange then it is intentional. The "framework" uses the >>> reflective APIs to export the otherwise internal packages to the JVMCI >>> implementation when it is located and loaded. From mandy.chung at oracle.com Tue Sep 13 14:38:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Sep 2016 07:38:09 -0700 Subject: RFR 8163320: JAVA_VERSION in release file should come from java.base module In-Reply-To: <8fcd1be5-c101-06bc-0f33-ccbd55d192f8@oracle.com> References: <640724e0-6d49-81be-3482-74dbc001d4ba@oracle.com> <174D8EFE-F40F-44BD-9699-FDE0952DE0BA@oracle.com> <8fcd1be5-c101-06bc-0f33-ccbd55d192f8@oracle.com> Message-ID: Looks good. Mandy > On Sep 13, 2016, at 2:41 AM, Sundararajan Athijegannathan wrote: > > Modified existing test to check quotes around properties added by jlink: > > Updated webrevs: > > jdk: > > http://cr.openjdk.java.net/~sundar/8163320/jdk/webrev.02/ > > Top: > > http://cr.openjdk.java.net/~sundar/8163320/top/webrev.02/ > > Thanks > > -Sundar > > > On 9/9/2016 9:07 PM, Mandy Chung wrote: >> Looks good. >> >> Is there an existing test to check the content of `release` file? It would be good to have a test to sanity test a few properties and its quoted value. >> >> Mandy >> >>> On Sep 9, 2016, at 6:02 AM, Sundararajan Athijegannathan wrote: >>> >>> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8163320 >>> >>> jdk repo: >>> >>> http://cr.openjdk.java.net/~sundar/8163320/jdk/ >>> >>> * JAVA_VERSION is derived from module-info of java.base >>> >>> * adding quotes around all 'release' properties >>> >>> top repo: >>> >>> http://cr.openjdk.java.net/~sundar/8163320/top/webrev.01/ >>> >>> Makefile changes to avoid generating OS_NAME, JAVA_VERSION etc. - as >>> jlink takes care of those. >>> >>> Thanks >>> >>> -Sundar >>> > From Alan.Bateman at oracle.com Tue Sep 13 14:40:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Sep 2016 15:40:17 +0100 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: <34486f5e-53cc-33dc-c0fa-395940ede36b@redhat.com> References: <34486f5e-53cc-33dc-c0fa-395940ede36b@redhat.com> Message-ID: On 13/09/2016 15:28, Andrew Dinn wrote: > : > > The immediate question is > > 1) Will the agent be able add an export relationship > > M exports private P to M' Yes. > > The bonus question is essentially the same as the first but in a > slightly different circumstance. Let us instead assume that module M > contains package P, the agent trusts module M' and M currently exports P > to M' but does not export private P to M' (n.b. this will really only be > of relevance where M exports P to all modules but does not export > private P to all modules) > > 2) Will the agent be able to upgrade the export relationship from > > M exports P to M' > Yes. As per the original proposal, the agent can expand the set of packages that are exported (or exported-private), it just can't reduce. We have a number of patches coming that will align the implementation with the current proposals and expect to have EA builds shortly too. -Alan From adinn at redhat.com Tue Sep 13 14:42:44 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 13 Sep 2016 15:42:44 +0100 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: References: <34486f5e-53cc-33dc-c0fa-395940ede36b@redhat.com> Message-ID: On 13/09/16 15:40, Alan Bateman wrote: > On 13/09/2016 15:28, Andrew Dinn wrote: > We have a number of patches coming that will align the implementation > with the current proposals and expect to have EA builds shortly too. Excellent! Thanks for the very quick response. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From scolebourne at joda.org Tue Sep 13 14:53:04 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 13 Sep 2016 15:53:04 +0100 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: <7BA3B0B5-18CE-4217-8EC4-0A6D14CC88AE@luminis.eu> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <7BA3B0B5-18CE-4217-8EC4-0A6D14CC88AE@luminis.eu> Message-ID: On 13 September 2016 at 07:33, Sander Mak wrote: >> Here is my counter proposal, hopefully a >> relatively small conceptual change: > > Not sure whether introducing a new top-level keyword (exposes) is better than adding a modifier keyword to exports. As was the case with `exports dynamic`, but a better name might be `exports runtime` since that's how we are referring to its effects in this whole discussion. For the rest, I agree with the gist of the counter proposal. I chose "exposes" for two reasons. 1) It seems entirely orthogonal to "exports". Exports is all about public API, and that API should only be callable by modules that require the exporting module. Whereas exposing something is all about the nasty yucky internals. I don't see much overlap between the two concepts at this point. 2) "expose" is a word with deliberately negative connotations, for the same reasons that the original proposal suggested "weak". I'd also argue that "exports+exposes" is a cleaner way to express the concepts than "exports", "exports dynamic" and "exports runtime". On the "weak module" concept, I find that it is a binary top-level choice, yet it needs quite a lot of understanding to appreciate why it should be there. Whereas, exports+exposes can be learnt and adjusted more easily step by step. Stephen From ali.ebrahimi1781 at gmail.com Tue Sep 13 15:06:38 2016 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 13 Sep 2016 19:36:38 +0430 Subject: Closing out some open issues In-Reply-To: References: <57d5cbc5.c6b91c0a.c2828.7027SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: +1 for "requires optional" On Tue, Sep 13, 2016 at 2:29 AM, Stephen Colebourne wrote: > On 11 September 2016 at 22:24, wrote: > > Proposals for the following issues have been available for evaluation > > and experimentation for quite a while now. Most responses have been > > positive and there have been no strong objections, so I've updated > > the issue list [1] to mark them as closed. > > > > #BootstrapClassLoaderSearchInJVMTI > > #ClassFileAccPublic > > #CompileTimeDependences (`requires static`) > > #CustomizableAutomaticModuleNameMapping > > #ModuleAnnotations > > #ModuleDeprecation > > #ReflectiveAccessByInstrumentationAgents > > > > Not everyone was thrilled with the choice of `static` as the modifier > > on `requires` directives that indicates a compile-time dependence, but > > no obviously-better choice has emerged. > > Given that "exports dynamic" has gone, there is even less reason to > use "static" (as there is no "dynamic" equivalent). The simplest > alternative is "requires optional", which fits with the existing > terminology used by maven for many years and more clearly indicates > that users cannot rely on the dependency. > > Stephen > -- Best Regards, Ali Ebrahimi From pbenedict at apache.org Tue Sep 13 17:23:09 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 13 Sep 2016 12:23:09 -0500 Subject: Closing out some open issues In-Reply-To: References: <57d5cbc5.c6b91c0a.c2828.7027SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Anyone who cares about grammar would know "requires optional" is awkward (and horrible) English. It's an oxymoron. It's non-nonsensical. Since this is all about dependencies, why not be straightforward like this: dependency requires foo.bar1; dependency optional foo.bar2; NB: I did once submit a proposal to add "module", "package", and "class" as qualifiers to make things explicit. What happened to that? I don't remember it being accepted or rejected. In any case, it would make more sense in this scenario: requires module foo.bar1; optional module foo.bar2; Or just use "requires" and "optional" plainly: requires foo.bar1; optional foo.bar2; Cheers, Paul On Tue, Sep 13, 2016 at 10:06 AM, Ali Ebrahimi wrote: > +1 for "requires optional" > > On Tue, Sep 13, 2016 at 2:29 AM, Stephen Colebourne > wrote: > > > On 11 September 2016 at 22:24, wrote: > > > Proposals for the following issues have been available for evaluation > > > and experimentation for quite a while now. Most responses have been > > > positive and there have been no strong objections, so I've updated > > > the issue list [1] to mark them as closed. > > > > > > #BootstrapClassLoaderSearchInJVMTI > > > #ClassFileAccPublic > > > #CompileTimeDependences (`requires static`) > > > #CustomizableAutomaticModuleNameMapping > > > #ModuleAnnotations > > > #ModuleDeprecation > > > #ReflectiveAccessByInstrumentationAgents > > > > > > Not everyone was thrilled with the choice of `static` as the modifier > > > on `requires` directives that indicates a compile-time dependence, but > > > no obviously-better choice has emerged. > > > > Given that "exports dynamic" has gone, there is even less reason to > > use "static" (as there is no "dynamic" equivalent). The simplest > > alternative is "requires optional", which fits with the existing > > terminology used by maven for many years and more clearly indicates > > that users cannot rely on the dependency. > > > > Stephen > > > > > > -- > > Best Regards, > Ali Ebrahimi > -- Cheers, Paul From mark.reinhold at oracle.com Tue Sep 13 20:04:38 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 13 Sep 2016 13:04:38 -0700 Subject: Proposal: #ServiceLoaderEnhancements In-Reply-To: References: <20160912151301.C2B83CD096@eggemoggin.niobe.net> Message-ID: <20160913130438.36772282eggemoggin.niobe.net> 2016/9/12 15:08:41 -0700, Stephen Colebourne : > My preference of these three options is option 2. Sorry if I wasn't clear, but this isn't meant to be a "choose one" proposal. It's a set of check boxes, not radio buttons. The proposal is to implement suggestions (2) and (3) of your original comment, as captured and labeled in the issue text, but not (1). > However, I would > prefer to see the method name be defined by the module definition as > previously suggested [1]: > > module { > provides java.sql.Driver with com.mysql.jdbc.Driver::instance; > } > > This would allow ::staticMethod or ::staticConstant, and avoid > hard-coding "provider" as a special method name. > > (For my motivating use case, the Chronology classes of ThreeTen-Extra > [2] it would be distracting to have a method named provider(). While a > separate class in a non-exported package would be possible to hold the > provider() method, as a solution that seems like overkill relative to > the syntax above.) The semantics of the `::` syntax as it already exists is tightly bound up with type inference. Also, it can only be used to refer to methods, not fields, so it'd have to be extended to support `::staticConstant`. Working out the details is not impossible, but it's certainly far from trivial. It's not clear to me that, even with more time, it should be at the top of our priority list. - Mark From scolebourne at joda.org Tue Sep 13 21:55:26 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 13 Sep 2016 22:55:26 +0100 Subject: Proposal: #ServiceLoaderEnhancements In-Reply-To: <57d85bdd.575a1c0a.4ecc7.8d96SMTPIN_ADDED_BROKEN@mx.google.com> References: <20160912151301.C2B83CD096@eggemoggin.niobe.net> <57d85bdd.575a1c0a.4ecc7.8d96SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On 13 September 2016 at 21:04, wrote: > 2016/9/12 15:08:41 -0700, Stephen Colebourne : >> My preference of these three options is option 2. > > Sorry if I wasn't clear, but this isn't meant to be a "choose one" > proposal. It's a set of check boxes, not radio buttons. The proposal > is to implement suggestions (2) and (3) of your original comment, as > captured and labeled in the issue text, but not (1). OK, I see. I think thats fine. >> However, I would >> prefer to see the method name be defined by the module definition as >> previously suggested [1]: >> >> module { >> provides java.sql.Driver with com.mysql.jdbc.Driver::instance; >> } >> >> This would allow ::staticMethod or ::staticConstant, and avoid >> hard-coding "provider" as a special method name. >> >> (For my motivating use case, the Chronology classes of ThreeTen-Extra >> [2] it would be distracting to have a method named provider(). While a >> separate class in a non-exported package would be possible to hold the >> provider() method, as a solution that seems like overkill relative to >> the syntax above.) > > The semantics of the `::` syntax as it already exists is tightly bound > up with type inference. Also, it can only be used to refer to methods, > not fields, so it'd have to be extended to support `::staticConstant`. > > Working out the details is not impossible, but it's certainly far from > trivial. It's not clear to me that, even with more time, it should be > at the top of our priority list. I would be OK with just ::staticMethod. It avoids blessing a particular method name and allows multiple methods on the same class, but provider() is significantly better than we have today. Stephen From alan.bateman at oracle.com Thu Sep 15 04:04:56 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:04:56 +0000 Subject: hg: jigsaw/jake: 11 new changesets Message-ID: <201609150404.u8F44uZY012283@aojmv0008.oracle.com> Changeset: c1ba8b744bfc Author: jjg Date: 2016-08-22 19:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c1ba8b744bfc support "requires transitive" ! make/common/Modules.gmk Changeset: 8a0242548ce0 Author: mchung Date: 2016-08-24 16:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8a0242548ce0 Support exports dynamic/private in module-info.java.extra ! make/GensrcModuleInfo.gmk Changeset: 78126af4fa3b Author: alanb Date: 2016-08-26 12:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/78126af4fa3b Use jtreg nightly ! common/conf/jib-profiles.js Changeset: ec05582af3fb Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ec05582af3fb Merge ! common/autoconf/generated-configure.sh ! make/common/Modules.gmk Changeset: 2a1d773606ce Author: mchung Date: 2016-09-01 22:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2a1d773606ce Merge ! common/autoconf/generated-configure.sh Changeset: 853cab545239 Author: mchung Date: 2016-09-08 18:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/853cab545239 Merge ! common/autoconf/generated-configure.sh Changeset: ca7159f30d0e Author: alanb Date: 2016-09-10 18:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ca7159f30d0e Temporary fix for 8165605: Thai resources in jdk.localedata cause split package issue with java.base Contributed-by: naoto.sato at oracle.com ! make/CompileJavaModules.gmk Changeset: a42dd937ac8a Author: alanb Date: 2016-09-14 15:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a42dd937ac8a Temporary fix to custom failure handler using jtreg internal APIs ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.java Changeset: d68a0c44dd07 Author: mchung Date: 2016-09-14 11:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d68a0c44dd07 Minor cleanup for removal of exports dynamic ! make/GensrcModuleInfo.gmk Changeset: 0702b6d2b3f2 Author: jjg Date: 2016-09-14 16:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0702b6d2b3f2 update failurehandler to avoid using jtreg internal API ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.java + test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/OS.java Changeset: 809f5c09b104 Author: mchung Date: 2016-09-14 19:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/809f5c09b104 Add license, copyright, tprm to java.base packaged module ! make/CreateJmods.gmk From alan.bateman at oracle.com Thu Sep 15 04:04:56 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:04:56 +0000 Subject: hg: jigsaw/jake/corba: 6 new changesets Message-ID: <201609150404.u8F44uon012298@aojmv0008.oracle.com> Changeset: a2f62fa3b982 Author: alanb Date: 2016-08-23 08:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a2f62fa3b982 requires public -> requires transitive ! src/java.corba/share/classes/module-info.java Changeset: 859f2255d6da Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/859f2255d6da Merge ! src/java.corba/share/classes/module-info.java Changeset: 9b9abae50564 Author: alanb Date: 2016-08-28 07:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9b9abae50564 Remove use of setAccessible to get Unsafe and latestUserDefinedLoader ! src/java.corba/share/classes/sun/corba/Bridge.java ! src/java.corba/share/classes/sun/corba/SharedSecrets.java Changeset: 987de713d24f Author: mchung Date: 2016-09-01 22:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/987de713d24f Merge Changeset: bccaaccfc58a Author: alanb Date: 2016-09-05 08:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/bccaaccfc58a Drop dynamic from java.corba module ! src/java.corba/share/classes/module-info.java Changeset: e5f8d3bb9704 Author: mchung Date: 2016-09-08 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/e5f8d3bb9704 Merge From alan.bateman at oracle.com Thu Sep 15 04:04:55 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:04:55 +0000 Subject: hg: jigsaw/jake/jaxp: 7 new changesets Message-ID: <201609150404.u8F44taA012234@aojmv0008.oracle.com> Changeset: 0dbc98673f3e Author: alanb Date: 2016-08-23 08:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0dbc98673f3e requires public -> requires transitive ! src/jdk.xml.dom/share/classes/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/test/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider1/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/module-info.java Changeset: 0d381db222f3 Author: alanb Date: 2016-08-27 19:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0d381db222f3 Update test using setAccessible ! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java Changeset: 805513e4086e Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/805513e4086e Merge Changeset: 0bc225615478 Author: alanb Date: 2016-08-28 07:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0bc225615478 Restore module-info.java to eliminate white space diffs ! test/javax/xml/jaxp/module/ServiceProviderTest/src/test/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider1/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/module-info.java Changeset: 580226ecaa16 Author: mchung Date: 2016-09-01 22:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/580226ecaa16 Merge ! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java Changeset: 486b9b18ddb7 Author: mchung Date: 2016-09-08 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/486b9b18ddb7 Merge ! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java Changeset: 794febf977d4 Author: alanb Date: 2016-09-09 11:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/794febf977d4 Second phase of weak modules support ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java From alan.bateman at oracle.com Thu Sep 15 04:04:57 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:04:57 +0000 Subject: hg: jigsaw/jake/jaxws: 6 new changesets Message-ID: <201609150404.u8F44vTh012363@aojmv0008.oracle.com> Changeset: 377abfb437c2 Author: alanb Date: 2016-08-23 08:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/377abfb437c2 requires public -> requires transitive ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java Changeset: 48ed655e5d1e Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/48ed655e5d1e Merge ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java Changeset: 86edc7b0ab09 Author: alanb Date: 2016-08-30 14:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/86edc7b0ab09 Tempoarily disable code injection in JAXB and JAX-WS ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/java.xml.ws/share/classes/module-info.java Changeset: 45a8dc12e5da Author: alanb Date: 2016-08-31 07:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/45a8dc12e5da Reduce JAXB/JAX-WS test failures ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/module-info.java Changeset: a370b082b2a4 Author: mchung Date: 2016-09-01 22:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/a370b082b2a4 Merge Changeset: f821c21cf83b Author: mchung Date: 2016-09-08 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/f821c21cf83b Merge From alan.bateman at oracle.com Thu Sep 15 04:05:00 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:05:00 +0000 Subject: hg: jigsaw/jake/nashorn: 7 new changesets Message-ID: <201609150405.u8F450o0012465@aojmv0008.oracle.com> Changeset: fb06ad3d6c0d Author: alanb Date: 2016-08-23 08:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fb06ad3d6c0d requires public -> requires transitive ! src/jdk.scripting.nashorn/share/classes/module-info.java Changeset: 99a76883fbe4 Author: alanb Date: 2016-08-27 19:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/99a76883fbe4 Update Nashorn to use addExportsPrivate and Unsafe usage ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/scripts/ModuleGraphManipulator.java Changeset: 64bd010cb51c Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/64bd010cb51c Merge Changeset: 14aa7c71e892 Author: mchung Date: 2016-09-01 22:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/14aa7c71e892 Merge Changeset: c078bbe4307a Author: mchung Date: 2016-09-08 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c078bbe4307a Merge Changeset: 9e6a8f40c924 Author: alanb Date: 2016-09-09 11:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9e6a8f40c924 Second phase of weak modules support ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java Changeset: fa069cbd41c9 Author: alanb Date: 2016-09-12 04:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fa069cbd41c9 Remove ModuleDescriptor::conceals, replace Builder::conceals with contains Update weak module build to disallow exports ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java From alan.bateman at oracle.com Thu Sep 15 04:05:02 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:05:02 +0000 Subject: hg: jigsaw/jake/langtools: 37 new changesets Message-ID: <201609150405.u8F453bo012516@aojmv0008.oracle.com> Changeset: 8bd01d119749 Author: jlahoda Date: 2016-08-17 19:37 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8bd01d119749 Service implementations no longer need to be public, or have a public constructor. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/exported/Service.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/impl/ServiceImplementation.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/module-info.java ! test/tools/javac/modules/ProvidesTest.java Changeset: bb5eb2a299dc Author: alanb Date: 2016-08-18 12:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bb5eb2a299dc Merge Changeset: 90a30f352895 Author: alanb Date: 2016-08-20 08:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/90a30f352895 Merge Changeset: 983bd135b79d Author: alanb Date: 2016-08-20 20:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/983bd135b79d Initial runtime support for `exports private` ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! test/tools/jdeps/lib/ModuleMetaData.java Changeset: d39d31cff220 Author: jjg Date: 2016-08-22 19:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d39d31cff220 support "requires transitive" ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jshell/share/classes/module-info.java ! test/tools/javac/classfiles/attributes/Module/ModuleTest.java ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/ModuleInfoTest.java - test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/RequiresStaticTest.java + test/tools/javac/modules/RequiresTransitiveTest.java ! test/tools/jdeps/lib/ModuleMetaData.java ! test/tools/jdeps/modules/CheckModuleTest.java ! test/tools/jdeps/modules/ModuleTest.java ! test/tools/jdeps/modules/src/m2/module-info.java ! test/tools/jdeps/modules/src/m3/module-info.java ! test/tools/jdeps/modules/src/m4/module-info.java ! test/tools/jdeps/modules/src/m5/module-info.java ! test/tools/lib/toolbox/ModuleBuilder.java Changeset: 77cd200ee6ed Author: alanb Date: 2016-08-23 08:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/77cd200ee6ed Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/MessageRetriever.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java - test/jdk/javadoc/tool/generics/genericClass/Main.java - test/jdk/javadoc/tool/generics/genericClass/expected.out - test/jdk/javadoc/tool/generics/genericClass/pkg1/A.java - test/jdk/javadoc/tool/generics/genericInnerAndOuter/Main.java - test/jdk/javadoc/tool/generics/genericInnerAndOuter/expected.out - test/jdk/javadoc/tool/generics/genericInnerAndOuter/pkg1/O.java - test/jdk/javadoc/tool/generics/genericInnerAndOuter/pkg1/X.java - test/jdk/javadoc/tool/generics/genericInterface/Main.java - test/jdk/javadoc/tool/generics/genericInterface/expected.out - test/jdk/javadoc/tool/generics/genericInterface/pkg1/A.java - test/jdk/javadoc/tool/generics/genericMethod/Main.java - test/jdk/javadoc/tool/generics/genericMethod/expected.out - test/jdk/javadoc/tool/generics/genericMethod/pkg1/A.java - test/jdk/javadoc/tool/generics/genericSuper/Main.java - test/jdk/javadoc/tool/generics/genericSuper/expected.out - test/jdk/javadoc/tool/generics/genericSuper/pkg1/A.java - test/jdk/javadoc/tool/generics/supertypes/Main.java - test/jdk/javadoc/tool/generics/supertypes/expected.out - test/jdk/javadoc/tool/generics/supertypes/pkg1/A.java - test/jdk/javadoc/tool/generics/supertypes/pkg1/B.java - test/jdk/javadoc/tool/generics/throwsGeneric/Main.java - test/jdk/javadoc/tool/generics/throwsGeneric/expected.out - test/jdk/javadoc/tool/generics/throwsGeneric/pkg1/A.java - test/jdk/javadoc/tool/generics/tparamCycle/Main.java - test/jdk/javadoc/tool/generics/tparamCycle/pkg1/LikeEnum.java - test/jdk/javadoc/tool/generics/tparamTagOnMethod/Main.java - test/jdk/javadoc/tool/generics/tparamTagOnMethod/expected.out - test/jdk/javadoc/tool/generics/tparamTagOnMethod/pkg1/A.java - test/jdk/javadoc/tool/generics/tparamTagOnType/Main.java - test/jdk/javadoc/tool/generics/tparamTagOnType/expected.out - test/jdk/javadoc/tool/generics/tparamTagOnType/pkg1/A.java - test/jdk/javadoc/tool/generics/wildcards/Main.java - test/jdk/javadoc/tool/generics/wildcards/expected.out - test/jdk/javadoc/tool/generics/wildcards/pkg1/A.java - test/jdk/javadoc/tool/imports/I.java - test/jdk/javadoc/tool/imports/MissingImport.java - test/jdk/javadoc/tool/lib/Tester.java - test/tools/javac/MethodParameters/Tester.java ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/RequiresTransitiveTest.java - test/tools/javac/options/modes/Tester.java - test/tools/javadoc/lib/Tester.java - test/tools/javap/output/Tester.java ! test/tools/jdeps/modules/ModuleTest.java Changeset: d8c7bf66b0e6 Author: mchung Date: 2016-08-23 14:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d8c7bf66b0e6 requirs public -> requires transitive ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Graph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java Changeset: 73454cdf4732 Author: mchung Date: 2016-08-23 14:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/73454cdf4732 requirs public -> requires transitive ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java Changeset: 187bcc7881f7 Author: jjg Date: 2016-08-23 14:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/187bcc7881f7 more 'requires public' to 'requires transitive' ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/jdk.compiler/share/classes/com/sun/source/tree/RequiresTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! test/tools/javac/modules/ModuleInfoTest.java Changeset: a484bca26c24 Author: jjg Date: 2016-08-23 14:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a484bca26c24 Merge Changeset: 7dc08febda0a Author: jjg Date: 2016-08-23 17:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7dc08febda0a initial passthrough support for 'exports private' ! src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java Changeset: 82914aba2ab3 Author: jjg Date: 2016-08-23 18:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/82914aba2ab3 update test infra for updated directives ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java ! test/tools/lib/toolbox/ModuleBuilder.java Changeset: 3c440892cf45 Author: jjg Date: 2016-08-23 19:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3c440892cf45 8163484: javax.lang.model.element.ModuleElement doesn't provide info about "requires static" and "exports dynamic" ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java Changeset: 5a5b5ef095c4 Author: jjg Date: 2016-08-24 13:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5a5b5ef095c4 more updates for module statement modifiers ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java Changeset: 1898244b4732 Author: jlahoda Date: 2016-08-24 23:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1898244b4732 Module names of automatic modules should be version-free names ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/ModulePathTest.java Changeset: d1d80e52e44c Author: jjg Date: 2016-08-24 15:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d1d80e52e44c pass-through impl of "exports dynamic [private] default" ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javac/diags/examples/DefaultExportsMustBeDynamic/module-info.java + test/tools/javac/diags/examples/ExpectedIdentifierOrDefault/module-info.java ! test/tools/javac/modules/ModuleInfoTest.java Changeset: d218e1f84264 Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d218e1f84264 Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/module-info.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/exported/Service.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/impl/ServiceImplementation.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/module-info.java - test/tools/javac/modules/RequiresPublicTest.java ! test/tools/lib/toolbox/ModuleBuilder.java Changeset: 6844662f4290 Author: mchung Date: 2016-08-27 17:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6844662f4290 Merge Changeset: c68bd6a4e207 Author: mchung Date: 2016-08-27 19:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c68bd6a4e207 requires public -> requires transitive ! test/jdk/javadoc/tool/modules/Modules.java Changeset: c7f21d1d8965 Author: jjg Date: 2016-08-30 20:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c7f21d1d8965 initial support for weak modules; improved conflict checking for exports; some cleanup ! src/jdk.compiler/share/classes/com/sun/source/tree/ModuleTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java + test/tools/javac/diags/examples/ConflictingDefaultExports/module-info.java + test/tools/javac/diags/examples/ConflictingExports/exported/Class.java + test/tools/javac/diags/examples/ConflictingExports/module-info.java + test/tools/javac/diags/examples/ConflictingExportsToModule/exported/Class.java + test/tools/javac/diags/examples/ConflictingExportsToModule/module-info.java - test/tools/javac/diags/examples/DuplicateExports/exported/Class.java - test/tools/javac/diags/examples/DuplicateExports/module-info.java + test/tools/javac/diags/examples/ExpectedModule.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/parser/JavacParserTest.java Changeset: 3097254e5c8a Author: mchung Date: 2016-08-31 18:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3097254e5c8a Rename for automatic modules ! test/tools/jdeps/modules/GenModuleInfo.java ! test/tools/jdeps/modules/ModuleTest.java - test/tools/jdeps/modules/src/m1/module-info.java - test/tools/jdeps/modules/src/m1/p1/Goo.java - test/tools/jdeps/modules/src/m1/p1/Lib.java - test/tools/jdeps/modules/src/m1/p1/S.java - test/tools/jdeps/modules/src/m1/p1/internal/Impl.java - test/tools/jdeps/modules/src/m2/module-info.java - test/tools/jdeps/modules/src/m2/p2/Bar.java - test/tools/jdeps/modules/src/m2/p2/internal/T2.java - test/tools/jdeps/modules/src/m3/module-info.java - test/tools/jdeps/modules/src/m3/p3/Foo.java - test/tools/jdeps/modules/src/m3/p3/Main.java + test/tools/jdeps/modules/src/mI/module-info.java + test/tools/jdeps/modules/src/mI/p1/Goo.java + test/tools/jdeps/modules/src/mI/p1/Lib.java + test/tools/jdeps/modules/src/mI/p1/S.java + test/tools/jdeps/modules/src/mI/p1/internal/Impl.java + test/tools/jdeps/modules/src/mII/module-info.java + test/tools/jdeps/modules/src/mII/p2/Bar.java + test/tools/jdeps/modules/src/mII/p2/internal/T2.java + test/tools/jdeps/modules/src/mIII/module-info.java + test/tools/jdeps/modules/src/mIII/p3/Foo.java + test/tools/jdeps/modules/src/mIII/p3/Main.java Changeset: 188528a09f2b Author: mchung Date: 2016-09-01 22:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/188528a09f2b Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.jshell/share/classes/module-info.java ! test/jdk/javadoc/tool/modules/Modules.java - test/tools/javac/diags/examples/DuplicateExports/exported/Class.java - test/tools/javac/diags/examples/DuplicateExports/module-info.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/exported/Service.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/impl/ServiceImplementation.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/module-info.java ! test/tools/javac/modules/GraphsTest.java - test/tools/javac/modules/RequiresPublicTest.java - test/tools/jdeps/modules/src/m1/module-info.java - test/tools/jdeps/modules/src/m1/p1/Goo.java - test/tools/jdeps/modules/src/m1/p1/Lib.java - test/tools/jdeps/modules/src/m1/p1/S.java - test/tools/jdeps/modules/src/m1/p1/internal/Impl.java - test/tools/jdeps/modules/src/m2/module-info.java - test/tools/jdeps/modules/src/m2/p2/Bar.java - test/tools/jdeps/modules/src/m2/p2/internal/T2.java - test/tools/jdeps/modules/src/m3/module-info.java - test/tools/jdeps/modules/src/m3/p3/Foo.java - test/tools/jdeps/modules/src/m3/p3/Main.java Changeset: 22f7608d1b4f Author: alanb Date: 2016-09-02 13:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/22f7608d1b4f Add :private to tests direcly using setAccessible ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/ComputeFQNsTest.java ! test/jdk/jshell/HistoryTest.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/modules/PatchModulesTest.java ! test/tools/javac/options/release/ReleaseOptionClashes.java ! test/tools/javac/processing/model/TestSymtabItems.java ! test/tools/javac/scope/DupUnsharedTest.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/types/ScopeListenerTest.java Changeset: 2f4d37fefc9e Author: jjg Date: 2016-09-02 14:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2f4d37fefc9e ACC_PRIVATE_REFLECTION to ACC_REFLECTION ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java Changeset: 4db263f9343d Author: alanb Date: 2016-09-05 08:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4db263f9343d Add modules_flags ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java Changeset: 4af8cb38c00f Author: jlahoda Date: 2016-09-06 11:50 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4af8cb38c00f Adjusting weak modules according to the current proposal; dropping exports dynamic, exports default. ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! test/tools/javac/classfiles/attributes/Module/ModuleTest.java ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java - test/tools/javac/diags/examples/ConflictingDefaultExports/module-info.java - test/tools/javac/diags/examples/DefaultExportsMustBeDynamic/module-info.java - test/tools/javac/diags/examples/ExpectedIdentifierOrDefault/module-info.java + test/tools/javac/diags/examples/NoExportsInWeak/module-info.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/modules/PackageConflictTest.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java + test/tools/javac/modules/WeakModulesTest.java Changeset: df338e714f64 Author: jlahoda Date: 2016-09-06 15:11 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/df338e714f64 For consistency with runtime, disallow private and non-private qualified export of the same package to different modules. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/tools/javac/modules/ModuleInfoTest.java Changeset: d26b4bb63771 Author: jlahoda Date: 2016-09-07 15:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d26b4bb63771 exports private should accept packages which contain only resources. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java Changeset: 58e13c1ee886 Author: alanb Date: 2016-09-07 17:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/58e13c1ee886 Rename ConcealedPackages to Packages ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Packages_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/lib/annotations/annotations/classfile/ClassfileInspector.java ! test/tools/javac/MethodParameters/AttributeVisitor.java Changeset: a1502e7ec4f9 Author: jlahoda Date: 2016-09-08 08:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a1502e7ec4f9 Avoiding trouble when too eagerly completing packages in Symtab.lookupPackage for unnamed module ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java Changeset: 03ab1221ab9e Author: mchung Date: 2016-09-08 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/03ab1221ab9e Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! test/jdk/jshell/CompletionSuggestionTest.java - test/tools/javac/diags/examples/DuplicateExports/exported/Class.java - test/tools/javac/diags/examples/DuplicateExports/module-info.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/exported/Service.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/impl/ServiceImplementation.java - test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/module-info.java - test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/RequiresStaticTest.java ! test/tools/javac/options/release/ReleaseOptionClashes.java - test/tools/jdeps/modules/src/m1/module-info.java - test/tools/jdeps/modules/src/m1/p1/Goo.java - test/tools/jdeps/modules/src/m1/p1/Lib.java - test/tools/jdeps/modules/src/m1/p1/S.java - test/tools/jdeps/modules/src/m1/p1/internal/Impl.java - test/tools/jdeps/modules/src/m2/module-info.java - test/tools/jdeps/modules/src/m2/p2/Bar.java - test/tools/jdeps/modules/src/m2/p2/internal/T2.java - test/tools/jdeps/modules/src/m3/module-info.java - test/tools/jdeps/modules/src/m3/p3/Foo.java - test/tools/jdeps/modules/src/m3/p3/Main.java ! test/tools/lib/toolbox/ModuleBuilder.java Changeset: 17508720b146 Author: alanb Date: 2016-09-09 11:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/17508720b146 Second phase of weak modules support ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java Changeset: 9cdc06f40dee Author: jlahoda Date: 2016-09-09 12:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9cdc06f40dee 'Duplicate' private and non-private qualified exports should be allowed ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/jdk/jshell/JDIListeningExecutionControlTest.java ! test/tools/javac/modules/ModuleInfoTest.java Changeset: 5be378ebc530 Author: mchung Date: 2016-09-10 15:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5be378ebc530 Rename test automatic modules not to use digits ! test/tools/jdeps/modules/CheckModuleTest.java ! test/tools/jdeps/modules/InverseDeps.java ! test/tools/jdeps/modules/TransitiveDeps.java ! test/tools/jdeps/modules/src/m4/module-info.java - test/tools/jdeps/modules/src/m6/module-info.java - test/tools/jdeps/modules/src/m6/p6/indirect/UnsafeRef.java - test/tools/jdeps/modules/src/m6/p6/safe/Lib.java - test/tools/jdeps/modules/src/m7/module-info.java - test/tools/jdeps/modules/src/m7/p7/Main.java + test/tools/jdeps/modules/src/mVI/module-info.java + test/tools/jdeps/modules/src/mVI/p6/indirect/UnsafeRef.java + test/tools/jdeps/modules/src/mVI/p6/safe/Lib.java + test/tools/jdeps/modules/src/mVII/module-info.java + test/tools/jdeps/modules/src/mVII/p7/Main.java Changeset: 78d769801dfa Author: alanb Date: 2016-09-12 04:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/78d769801dfa Remove ModuleDescriptor::conceals, replace Builder::conceals with contains Update weak module build to disallow exports ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java Changeset: b403a0007b81 Author: alanb Date: 2016-09-12 11:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b403a0007b81 javac/platform/PlatformProviderTest.java failing ! test/tools/javac/platform/PlatformProviderTest.java Changeset: 92b50b698e6e Author: jlahoda Date: 2016-09-13 18:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/92b50b698e6e Service implementations must be public per current design. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/exported/Service.java + test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/impl/ServiceImplementation.java + test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/module-info.java ! test/tools/javac/modules/ProvidesTest.java From alan.bateman at oracle.com Thu Sep 15 04:05:09 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:05:09 +0000 Subject: hg: jigsaw/jake/hotspot: 15 new changesets Message-ID: <201609150405.u8F459Jt012610@aojmv0008.oracle.com> Changeset: 1496450e781d Author: mchung Date: 2016-07-27 09:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1496450e781d Add ClassLoader name ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: 24a6a9275b22 Author: alanb Date: 2016-07-29 10:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/24a6a9275b22 Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: 3294dc3f35cc Author: mchung Date: 2016-08-14 19:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3294dc3f35cc Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: e1f87efd708a Author: alanb Date: 2016-08-20 08:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e1f87efd708a Merge Changeset: 349178d1436c Author: alanb Date: 2016-08-20 20:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/349178d1436c Initial runtime support for `exports private` ! src/share/vm/runtime/arguments.cpp Changeset: 63b9953d91d7 Author: alanb Date: 2016-08-25 18:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/63b9953d91d7 Update usages of builder API to use new form of exports ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/ModuleStress/ModuleSameCLMain.java Changeset: b0ec64509585 Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b0ec64509585 Merge Changeset: 908b37389b60 Author: mchung Date: 2016-09-01 22:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/908b37389b60 Merge Changeset: 2464a42ecc18 Author: jlahoda Date: 2016-09-06 11:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2464a42ecc18 Removing exports dynamic ! src/jdk.hotspot.agent/share/classes/module-info.java Changeset: c19881ed4dd5 Author: mchung Date: 2016-09-08 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c19881ed4dd5 Merge ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java Changeset: d79352d5e29a Author: alanb Date: 2016-09-09 11:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d79352d5e29a Second phase of weak modules support ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/ModuleStress/ModuleNonBuiltinCLMain.java ! test/runtime/modules/ModuleStress/ModuleSameCLMain.java Changeset: 1b3760ecfc24 Author: alanb Date: 2016-09-12 04:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1b3760ecfc24 Remove ModuleDescriptor::conceals, replace Builder::conceals with contains Update weak module build to disallow exports ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/ModuleHelper.java Changeset: b917f4db4bf6 Author: mchung Date: 2016-09-12 15:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b917f4db4bf6 Update stack traces with slash-based syntax ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: 22696cfa121b Author: alanb Date: 2016-09-14 04:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/22696cfa121b Add placeholder for JVMTI AddModuleExportsPrivate ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 8b9a67a9fdb6 Author: mchung Date: 2016-09-14 14:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8b9a67a9fdb6 Deserialized StackTraceElement::toString should print the compacted representation ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp From alan.bateman at oracle.com Thu Sep 15 04:05:19 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Sep 2016 04:05:19 +0000 Subject: hg: jigsaw/jake/jdk: 99 new changesets Message-ID: <201609150405.u8F45NrB012805@aojmv0008.oracle.com> Changeset: 2784b4c97ce0 Author: mchung Date: 2016-07-27 09:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2784b4c97ce0 Add ClassLoader name ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/security/SecureClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! test/java/lang/StackTraceElement/PublicConstructor.java + test/java/lang/StackTraceElement/WithClassLoaderName.java + test/java/lang/StackTraceElement/lib/app/com/app/Main.java + test/java/lang/StackTraceElement/lib/app/com/app/Utils.java + test/java/lang/StackTraceElement/lib/app/module-info.java + test/java/lang/StackTraceElement/src/p/ThrowException.java ! test/java/lang/StackWalker/VerifyStackTrace.java ! test/java/net/URLClassLoader/NullURLTest.java Changeset: b44a62675ee5 Author: alanb Date: 2016-07-27 09:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b44a62675ee5 Updates to resource encapsulation ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java + src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! test/java/lang/Class/getResource/Main.java ! test/java/lang/Class/getResource/src/m1/p1/Main.java + test/java/lang/Class/getResource/src/m1/p1/impl/Type.java ! test/java/lang/Class/getResource/src/m2/module-info.java ! test/java/lang/Class/getResource/src/m2/p2/Main.java + test/java/lang/Class/getResource/src/m2/p2/impl/Type.java ! test/java/lang/Class/getResource/src/m3/p3/Main.java ! test/java/lang/ClassLoader/getResource/modules/Main.java ! test/java/lang/ClassLoader/getResource/modules/ResourcesTest.java + test/java/lang/ClassLoader/getResource/modules/src/m1/p1/impl/Type.java + test/java/lang/ClassLoader/getResource/modules/src/m2/p2/impl/Type.java - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java Changeset: 78709f4f63ba Author: alanb Date: 2016-07-27 10:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/78709f4f63ba java/lang/StackWalker/VerifyStackTrace.java failing ! test/java/lang/StackWalker/VerifyStackTrace.java Changeset: 62efb8367c5e Author: alanb Date: 2016-07-27 11:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/62efb8367c5e Updates to ServiceLoader ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! test/java/lang/reflect/Layer/BasicLayerTest.java Changeset: 898754923685 Author: alanb Date: 2016-07-27 18:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/898754923685 Merge Changeset: 1579f6ae839b Author: alanb Date: 2016-07-29 09:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1579f6ae839b GeneratedConnectors.java failing with SL changes ! test/com/sun/jdi/connect/spi/GeneratedConnectors.java Changeset: 3b624434d847 Author: alanb Date: 2016-07-29 10:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3b624434d847 Merge ! src/java.base/share/classes/java/lang/Class.java - test/java/net/URLPermission/policy.1 - test/java/net/URLPermission/policy.2 - test/java/net/URLPermission/policy.3 - test/java/util/jar/JarFile/mrjar/MultiReleaseJarIterators.java Changeset: 5d7d6066aee8 Author: alanb Date: 2016-07-29 14:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5d7d6066aee8 ThreadInfoCompositeData.java failing due to class loader name in stack trace ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java Changeset: dfe30bb78ca5 Author: alanb Date: 2016-07-30 16:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dfe30bb78ca5 Further update to Class::getResource to specify existing behavior ! src/java.base/share/classes/java/lang/Class.java ! test/java/lang/Class/getResource/Main.java Changeset: 5e8a6b6028c7 Author: alanb Date: 2016-07-30 17:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5e8a6b6028c7 BuiltinClassLoader should not fail if module location not absolute ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java Changeset: 9a13d3fd36ea Author: alanb Date: 2016-07-30 20:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a13d3fd36ea GeneratedConnectors failing with SimpleLaunchingConnector not found ! test/com/sun/jdi/connect/spi/GeneratedConnectors.java Changeset: 94d1316aa91e Author: mchung Date: 2016-08-14 19:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/94d1316aa91e Merge ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/System.java - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java ! test/java/lang/StackWalker/VerifyStackTrace.java Changeset: d79358e98507 Author: alanb Date: 2016-08-20 08:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d79358e98507 Merge ! src/java.base/share/classes/java/lang/System.java - src/java.base/share/conf/security/cacerts ! test/java/lang/ClassLoader/getResource/modules/ResourcesTest.java - test/sun/security/mscapi/AccessKeyStore.sh Changeset: 1b7bdb415afd Author: alanb Date: 2016-08-20 20:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b7bdb415afd Initial runtime support for `exports private` ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/libjli/java.c ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/jdk/internal/misc/Unsafe/CopyCommon.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java ! test/tools/jmod/hashes/HashesTest.java Changeset: a936ca00be2c Author: alanb Date: 2016-08-20 20:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a936ca00be2c Merge Changeset: ef8b12cebe67 Author: alanb Date: 2016-08-21 20:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ef8b12cebe67 Expand test coverage for exports dynamic ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java Changeset: fc21a2b9730f Author: alanb Date: 2016-08-22 08:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fc21a2b9730f Update javadoc for ClassLoader getResourceXXX methods to make encapsulation clearer ! src/java.base/share/classes/java/lang/ClassLoader.java Changeset: a539bd17327d Author: alanb Date: 2016-08-22 12:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a539bd17327d Update redefineModule to support exports private ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! test/java/lang/instrument/RedefineModuleAgent.java ! test/java/lang/instrument/RedefineModuleTest.java Changeset: 2b7946a3db06 Author: alanb Date: 2016-08-22 15:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2b7946a3db06 Improve javadoc for Builder.exports ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java Changeset: 89d57216946b Author: alanb Date: 2016-08-22 19:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89d57216946b Expand AccessTest to cover all public/non-public/exported/non-exported combinations ! test/java/lang/reflect/Module/access/AccessTest.java ! test/java/lang/reflect/Module/access/src/target/module-info.java - test/java/lang/reflect/Module/access/src/target/p/Exported.java - test/java/lang/reflect/Module/access/src/target/p/Helper.java + test/java/lang/reflect/Module/access/src/target/p1/Helper.java + test/java/lang/reflect/Module/access/src/target/p1/Public.java + test/java/lang/reflect/Module/access/src/target/p2/NonPublic.java - test/java/lang/reflect/Module/access/src/target/q/Internal.java + test/java/lang/reflect/Module/access/src/target/q1/Public.java + test/java/lang/reflect/Module/access/src/target/q2/NonPublic.java ! test/java/lang/reflect/Module/access/src/test/test/Main.java Changeset: 433c5cbc4e9b Author: alanb Date: 2016-08-23 08:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/433c5cbc4e9b requires public -> requires transitive ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.compact1/share/classes/module-info.java ! src/java.compact2/share/classes/module-info.java ! src/java.compact3/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.accessibility/share/classes/module-info.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.management/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Proxy/src/m3/module-info.java ! test/java/lang/reflect/Proxy/src/test/module-info.java ! test/tools/jmod/hashes/src/org.bar/module-info.java ! test/tools/jmod/hashes/src/org.foo/module-info.java ! test/tools/launcher/modules/upgrademodulepath/src/java.transaction/module-info.java Changeset: 703f9ee2dbee Author: alanb Date: 2016-08-23 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/703f9ee2dbee Update jlr.Module javadoc to use exports private consistently ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: feaa7aab5a0f Author: alanb Date: 2016-08-24 12:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/feaa7aab5a0f Exports equals/hashCode ignoring modifiers ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java ! test/java/lang/module/ModuleDescriptorTest.java Changeset: 05b1c428a46a Author: alanb Date: 2016-08-24 17:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/05b1c428a46a Module names of automatic modules should be version-free names ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! test/java/lang/module/AutomaticModulesTest.java Changeset: d501b2588261 Author: mchung Date: 2016-08-24 16:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d501b2588261 Support exports dynamic/private in module-info.java.extra ! make/src/classes/build/tools/module/GenModuleInfoSource.java ! src/jdk.unsupported/share/classes/module-info.java Changeset: 9ee7c1bef46d Author: mchung Date: 2016-08-24 16:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ee7c1bef46d Minor cleanup GenModuleInfoSource tool ! make/src/classes/build/tools/module/GenModuleInfoSource.java Changeset: ee2d9ac5e51f Author: alanb Date: 2016-08-25 09:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee2d9ac5e51f Temporarily ignore exports default ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: 7a414cba0dbf Author: alanb Date: 2016-08-25 16:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7a414cba0dbf Initial support for exports dynamic default ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java Changeset: 93e8da13581c Author: alanb Date: 2016-08-25 20:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93e8da13581c Ignore bad files in META-INF/services ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! test/java/lang/module/AutomaticModulesTest.java Changeset: 67b4da87bf88 Author: alanb Date: 2016-08-26 15:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67b4da87bf88 Update tests to use @modules :private ! test/java/lang/Character/UnicodeBlock/OptimalMapSize.java ! test/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java ! test/java/lang/ClassLoader/LibraryPathProperty.java ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/Runtime/Version/VersionProps.java ! test/java/lang/StackWalker/CountLocalSlots.java ! test/java/lang/StackWalker/LocalsAndOperands.java ! test/java/lang/StackWalker/LocalsCrash.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerAPIsTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/java/lang/System/LoggerFinder/internal/backend/LoggerFinderBackendTest.java ! test/java/lang/invoke/LambdaFormTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/VMAnonymousClass.java ! test/java/lang/ref/FinalizerHistogramTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java Changeset: 252846962281 Author: alanb Date: 2016-08-27 17:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/252846962281 Update tests using setAccessible to use :private ! test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java ! test/com/sun/crypto/provider/Cipher/PBE/CheckPBEKeySize.java ! test/com/sun/crypto/provider/Cipher/PBE/NegativeLength.java ! test/com/sun/jmx/mbeanserver/introspector/SimpleIntrospectorTest.java ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java ! test/java/io/ObjectInputStream/PeekInputStreamTest.java ! test/java/lang/String/CompactString/VMOptionsTest.java ! test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java ! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java ! test/java/net/InterfaceAddress/Equals.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/file/etc/Exceptions.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/server/RMIClassLoader/useCodebaseOnlyDefault/UseCodebaseOnlyDefault.java ! test/java/rmi/server/getRemoteClass/GetRemoteClass.java ! test/java/time/TEST.properties ! test/java/util/ArrayList/ArrayManagement.java ! test/java/util/Calendar/StampOverflow.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/SyncSubMutexes.java ! test/java/util/ResourceBundle/ReferencesTest.java ! test/java/util/concurrent/ArrayBlockingQueue/IteratorConsistency.java ! test/javax/management/ObjectName/CompressedStorageTest.java ! test/javax/management/loading/MLetInternalsTest.java ! test/javax/management/openmbean/TabularDataOrderTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorInternalMapTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorNullSubjectConnTest.java ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/javax/net/ssl/TLS/TEST.properties ! test/javax/net/ssl/TLSv1/TEST.properties ! test/javax/net/ssl/TLSv11/TEST.properties ! test/jdk/internal/jline/console/StripAnsiTest.java ! test/sun/net/www/http/HttpClient/IsAvailable.java ! test/sun/security/krb5/auto/Renew.java ! test/sun/security/krb5/auto/TEST.properties ! test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java ! test/sun/security/provider/SecureRandom/CommonSeeder.java Changeset: 9ca171f1058a Author: alanb Date: 2016-08-27 19:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ca171f1058a More tests using setAccessible that need :private ! test/java/util/EnumSet/OneUniverse.java ! test/java/util/Hashtable/DeserializedLength.java ! test/java/util/IdentityHashMap/Capacity.java ! test/java/util/Locale/bug6312358.java ! test/java/util/concurrent/BlockingQueue/LastElement.java ! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java ! test/java/util/concurrent/ConcurrentLinkedQueue/RemoveLeak.java ! test/java/util/concurrent/Phaser/PhaseOverflow.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCoreThreads.java ! test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java ! test/java/util/concurrent/tck/JSR166TestCase.java ! test/java/util/logging/FileHandlerLongLimit.java ! test/java/util/logging/HandlersConfigTest.java ! test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java ! test/javax/net/ssl/DTLS/TEST.properties ! test/javax/net/ssl/DTLSv10/TEST.properties ! test/sun/security/jgss/spnego/NotPreferredMech.java ! test/sun/security/krb5/ccache/TimeInCCache.java ! test/sun/security/provider/SecureRandom/DRBGS11n.java ! test/sun/security/ssl/ExtensionType/OptimalListSize.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/util/DerInputBuffer/DerInputBufferEqualsHashCode.java ! test/sun/util/calendar/zi/TestZoneInfo310.java Changeset: 599ec76b2296 Author: mchung Date: 2016-08-27 15:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/599ec76b2296 Merge - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java ! src/java.compact1/share/classes/module-info.java ! src/java.compact2/share/classes/module-info.java ! src/java.compact3/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java ! test/java/lang/StackWalker/VerifyStackTrace.java - test/java/lang/reflect/Module/access/src/target/p/Exported.java - test/java/lang/reflect/Module/access/src/target/p/Helper.java - test/java/lang/reflect/Module/access/src/target/q/Internal.java ! test/sun/security/tools/keytool/StartDateTest.java Changeset: 4100bc46f3e3 Author: alanb Date: 2016-08-28 07:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4100bc46f3e3 Update further tests using setAccessible ! test/sun/security/krb5/RFC396xTest.java ! test/sun/security/krb5/config/DefUdpLimit.java ! test/sun/security/krb5/config/DnsFallback.java ! test/sun/security/krb5/config/SCDynamicConfigTest.java Changeset: 124c635a9342 Author: alanb Date: 2016-08-28 08:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/124c635a9342 Further tests using setAccessible ! test/com/sun/jndi/dns/Parser.java ! test/com/sun/jndi/ldap/SimpleClientIdHashCode.java ! test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java ! test/javax/xml/jaxp/PrecisionDecimalDV/XPrecisionDecimalToString.java Changeset: 62c92d7b1115 Author: alanb Date: 2016-08-28 09:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/62c92d7b1115 One more test using setAccessible ! test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java Changeset: 18574b8a39c8 Author: alanb Date: 2016-08-28 17:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/18574b8a39c8 Improve InaccessibleObjectException exception message ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java Changeset: 7310413953cb Author: alanb Date: 2016-08-29 08:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7310413953cb Remove use of setAccessible from jar/jmod tests ! test/tools/jar/modularJar/Basic.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java ! test/tools/jmod/hashes/HashesTest.java Changeset: 45b6f9b09de4 Author: alanb Date: 2016-08-29 12:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/45b6f9b09de4 AddExportsTest failing ! test/tools/launcher/modules/addexports/src/m1/jdk/test1/Main.java Changeset: de027c2b05dd Author: alanb Date: 2016-08-30 08:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de027c2b05dd Update Layer spec for modules containing java. packages ! src/java.base/share/classes/java/lang/reflect/Layer.java ! test/java/lang/reflect/Layer/BasicLayerTest.java Changeset: 4c1660324f4b Author: alanb Date: 2016-08-30 11:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4c1660324f4b Further tweaking of InaccessibleObjectException message ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java Changeset: 27aae3e6eb52 Author: alanb Date: 2016-08-30 13:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/27aae3e6eb52 Add test coverage for Add-Exports and Add-Exports-Private in JAR manifest + test/tools/launcher/modules/addexports/manifest/AddExportsInManifest.java + test/tools/launcher/modules/addexports/manifest/Test1.java + test/tools/launcher/modules/addexports/manifest/Test2.java Changeset: ecc353909c60 Author: alanb Date: 2016-08-30 14:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ecc353909c60 Temporarily exclude CORBA/IIOP tests ! test/ProblemList.txt Changeset: 9a631d8e2fb2 Author: alanb Date: 2016-08-31 08:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a631d8e2fb2 Temporarily exclude two further CORBA tests ! test/ProblemList.txt Changeset: d4cf934154c1 Author: alanb Date: 2016-08-31 14:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d4cf934154c1 ModuleDescriptor.read should not check module names ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! test/java/lang/module/ModuleDescriptorTest.java Changeset: 3cfe45d1774b Author: mchung Date: 2016-08-31 16:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3cfe45d1774b Test accesses private member ! test/java/beans/Introspector/6380849/TestBeanInfo.java Changeset: baef2e5eb697 Author: mchung Date: 2016-08-31 16:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/baef2e5eb697 Make VMOption @MXBean compliant ! src/java.management/share/classes/sun/management/MappedMXBeanType.java ! src/jdk.management/share/classes/com/sun/management/VMOption.java ! test/com/sun/management/VMOptionOpenDataTest.java Changeset: affdc2529314 Author: mchung Date: 2016-08-31 17:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/affdc2529314 Add @modules to access private members ! test/java/beans/XMLEncoder/java_awt_CardLayout.java ! test/java/beans/XMLEncoder/java_awt_GridBagLayout.java Changeset: b2c96b8c698f Author: alanb Date: 2016-09-01 21:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2c96b8c698f Replace versionedEntries to ensure that MR JARs are handled correctly ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java + test/java/lang/module/MultiReleaseJarTest.java Changeset: 8721ac5994bd Author: mchung Date: 2016-09-01 22:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8721ac5994bd Merge ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java ! test/ProblemList.txt - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java ! test/java/lang/StackWalker/VerifyStackTrace.java - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java - test/java/lang/reflect/Module/access/src/target/p/Exported.java - test/java/lang/reflect/Module/access/src/target/p/Helper.java - test/java/lang/reflect/Module/access/src/target/q/Internal.java ! test/jdk/modules/etc/VerifyModuleDelegation.java Changeset: 93abc36d54ab Author: alanb Date: 2016-09-02 12:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93abc36d54ab ACC_PRIVATE -> ACC_REFLECTION ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java Changeset: 00da46d37cbc Author: alanb Date: 2016-09-02 12:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/00da46d37cbc Update javadoc for Exports.Modifier.PRIVATE ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java Changeset: eae5a3ba13f6 Author: alanb Date: 2016-09-02 13:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eae5a3ba13f6 Switch setAccessible to be strict by default ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! test/ProblemList.txt Changeset: 9751388b7d45 Author: alanb Date: 2016-09-02 14:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9751388b7d45 Residual tests using setAccessible ! test/ProblemList.txt ! test/java/lang/ProcessBuilder/Basic.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/java/util/concurrent/atomic/VMSupportsCS8.java Changeset: 9552d785ee94 Author: alanb Date: 2016-09-05 09:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9552d785ee94 Drop dynamic, drop default exports, add support for ACC_WEAK ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java Changeset: 64138f5e2f8a Author: alanb Date: 2016-09-05 10:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64138f5e2f8a Drop support for dynamic from GenModuleInfoSource ! make/src/classes/build/tools/module/GenModuleInfoSource.java Changeset: da426e881e0a Author: alanb Date: 2016-09-05 11:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/da426e881e0a Improve Module::addExportsPrivate javadoc ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: 7642ae36ad62 Author: alanb Date: 2016-09-05 14:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7642ae36ad62 Add additional test for annotations on modules + test/java/lang/reflect/Module/annotation/Basic.java + test/java/lang/reflect/Module/annotation/src/m/module-info.java + test/java/lang/reflect/Module/annotation/src/m/p/annotation/Bar.java + test/java/lang/reflect/Module/annotation/src/m/p/annotation/Baz.java + test/java/lang/reflect/Module/annotation/src/m/p/annotation/Foo.java Changeset: 348721d21fa8 Author: alanb Date: 2016-09-05 15:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/348721d21fa8 Remove two unused statics ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java Changeset: 98d584f5e429 Author: alanb Date: 2016-09-06 11:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/98d584f5e429 Add-Exports/Add-Exports-Private value should use space as separator ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/modules/addexports/manifest/AddExportsInManifest.java Changeset: ab7f12d892bf Author: ssadetsky Date: 2016-09-02 10:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab7f12d892bf 8164937: Remove code from SortingFocusTraversalPolicy that hacks into non-public Arrays.legacyMergeSort Reviewed-by: alexsch, serb ! src/java.desktop/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! test/java/awt/Focus/SortingFPT/JDK8048887.java Changeset: 906c46c2bcab Author: alanb Date: 2016-09-06 15:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/906c46c2bcab Improve tests for ServiceLoader + test/java/util/ServiceLoader/modules/Basic.java - test/java/util/ServiceLoader/modules/MiscTests.java - test/java/util/ServiceLoader/modules/ServicesTest.java + test/java/util/ServiceLoader/modules/modules/bananascript/module-info.java + test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScript.java + test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/src/bananascript/module-info.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/src/test/module-info.java - test/java/util/ServiceLoader/modules/src/test/test/Main.java Changeset: e091dbf0d727 Author: mchung Date: 2016-09-06 16:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e091dbf0d727 Exclude tests due to JDK-8165263 ! test/ProblemList.txt Changeset: 36de69833f08 Author: alanb Date: 2016-09-07 07:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/36de69833f08 Fix typos in javadoc ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: f942f775d739 Author: alanb Date: 2016-09-07 07:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f942f775d739 Allow Add-Exports/Add-Exports-Private attributes in JAR file to contain dups ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/modules/addexports/manifest/AddExportsInManifest.java Changeset: 070c4366892a Author: alanb Date: 2016-09-07 14:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/070c4366892a Non-class resources should be in package that is exported-private ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! test/java/lang/Class/getResource/Main.java ! test/java/lang/Class/getResource/ResourcesTest.java ! test/java/lang/Class/getResource/src/m1/module-info.java + test/java/lang/Class/getResource/src/m1/p1/resources/Type.java ! test/java/lang/Class/getResource/src/m2/module-info.java + test/java/lang/Class/getResource/src/m2/p2/resources/Type.java - test/java/lang/Class/getResource/src/m3/module-info.java - test/java/lang/Class/getResource/src/m3/p3/Main.java ! test/java/lang/ClassLoader/getResource/modules/Main.java ! test/java/lang/ClassLoader/getResource/modules/src/m1/module-info.java ! test/java/lang/ClassLoader/getResource/modules/src/m1/p1/Main.java + test/java/lang/ClassLoader/getResource/modules/src/m1/p1/resources/Type.java ! test/java/lang/ClassLoader/getResource/modules/src/m2/module-info.java ! test/java/lang/ClassLoader/getResource/modules/src/m2/p2/Main.java + test/java/lang/ClassLoader/getResource/modules/src/m2/p2/resources/Type.java Changeset: 64c9580204ce Author: alanb Date: 2016-09-07 17:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64c9580204ce Rename ConcealedPackages to Packages ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/reflect/Module/AnnotationsTest.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java Changeset: f6e5f562f94c Author: mchung Date: 2016-09-07 19:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f6e5f562f94c jlink plugin to create Packages attribute, if not present ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java Changeset: f7acfdffe16f Author: yan Date: 2016-09-08 18:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f7acfdffe16f 8165502: Update client regression tests using setAccessible() before the next Jigsaw integration ! test/java/awt/EventDispatchThread/EDTShutdownTest/EDTShutdownTest.java ! test/java/awt/Focus/RequestOnCompWithNullParent/RequestOnCompWithNullParent1.java ! test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html ! test/java/awt/Modal/LWModalTest/LWModalTest.java ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/java/awt/TrayIcon/ActionCommand/ActionCommand.java ! test/java/awt/TrayIcon/ActionEventMask/ActionEventMask.java ! test/java/awt/TrayIcon/ActionEventTest/ActionEventTest.java ! test/java/awt/TrayIcon/ModalityTest/ModalityTest.java ! test/java/awt/TrayIcon/MouseEventMask/MouseEventMaskTest.java ! test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/FunctionalityCheck.java ! test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java ! test/java/awt/TrayIcon/TrayIconEvents/TrayIconEventsTest.java ! test/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java ! test/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java ! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java ! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java ! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java ! test/java/awt/font/FontNames/GetLCIDFromLocale.java ! test/java/awt/image/MultiResolutionImageTest.java ! test/java/awt/patchlib/java.desktop/java/awt/Helper.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java ! test/javax/swing/JFileChooser/6688203/bug6688203.java ! test/javax/swing/JLabel/7004134/bug7004134.java ! test/javax/swing/JPopupMenu/6495920/bug6495920.java ! test/javax/swing/JPopupMenu/6800513/bug6800513.java ! test/javax/swing/JSlider/6794836/bug6794836.java ! test/javax/swing/JSlider/6848475/bug6848475.java ! test/javax/swing/JTabbedPane/7010561/bug7010561.java ! test/javax/swing/JTree/6263446/bug6263446.java ! test/javax/swing/RepaintManager/7013453/bug7013453.java ! test/javax/swing/Security/6938813/bug6938813.java ! test/javax/swing/border/Test7149090.java ! test/javax/swing/plaf/synth/7143614/bug7143614.java ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: 6d6b2eb8cfa9 Author: mchung Date: 2016-09-08 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6d6b2eb8cfa9 Merge - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java ! src/java.base/share/native/libjli/java.c ! src/java.management/share/classes/module-info.java ! test/ProblemList.txt ! test/java/lang/Class/GetModuleTest.java - test/java/lang/Class/getResource/src/m3/module-info.java - test/java/lang/Class/getResource/src/m3/p3/Main.java - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/StackWalker/CountLocalSlots.java ! test/java/lang/StackWalker/LocalsAndOperands.java ! test/java/lang/StackWalker/LocalsCrash.java - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java - test/java/lang/reflect/Module/access/src/target/p/Exported.java - test/java/lang/reflect/Module/access/src/target/p/Helper.java - test/java/lang/reflect/Module/access/src/target/q/Internal.java - test/java/util/ServiceLoader/modules/MiscTests.java - test/java/util/ServiceLoader/modules/ServicesTest.java - test/java/util/ServiceLoader/modules/src/bananascript/module-info.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/src/test/module-info.java - test/java/util/ServiceLoader/modules/src/test/test/Main.java ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/sun/util/calendar/zi/TestZoneInfo310.java Changeset: 7ca32e1dafc8 Author: mchung Date: 2016-09-08 19:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ca32e1dafc8 Merge ! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 6b35dbe9ae9a Author: alanb Date: 2016-09-09 11:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6b35dbe9ae9a Second phase of weak modules support ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleReferenceTest.java ! test/java/lang/module/MultiReleaseJarTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Layer/LayerAndLoadersTest.java ! test/java/security/modules/ModularTest.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/tools/jlink/JLinkNegativeTest.java Changeset: ddb7cac428de Author: alanb Date: 2016-09-09 11:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ddb7cac428de Minor refactoring of exports initialization ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: a21f66f830fc Author: alanb Date: 2016-09-09 13:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a21f66f830fc Reorder java --list-modules to emit unqualified exports first ! src/java.base/share/classes/sun/launcher/LauncherHelper.java Changeset: f6de8f0cc1ac Author: mchung Date: 2016-09-10 08:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f6de8f0cc1ac Support linking of weak modules ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m3/module-info.java + test/tools/jlink/plugins/SystemModuleDescriptors/src/m3/p3/Main.java + test/tools/jlink/plugins/SystemModuleDescriptors/src/m4/module-info.java + test/tools/jlink/plugins/SystemModuleDescriptors/src/m4/p4/Foo.java Changeset: 30319ba0e5da Author: alanb Date: 2016-09-10 18:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30319ba0e5da Temporary fix for 8165605: Thai resources in jdk.localedata cause split package issue with java.base Contributed-by: naoto.sato at oracle.com ! make/gendata/GendataBreakIterator.gmk - src/java.base/share/classes/sun/text/resources/BreakIteratorRulesProvider.java ! src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java ! src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java + src/jdk.localedata/share/classes/sun/text/resources/ext/thai_dict - src/jdk.localedata/share/classes/sun/text/resources/thai_dict ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: 467584a3effd Author: alanb Date: 2016-09-10 18:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/467584a3effd Update JAR file and exploded module scanning to use package names of resources ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ModuleFinderTest.java Changeset: fc0fc1cffd2a Author: mchung Date: 2016-09-10 18:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fc0fc1cffd2a Update jar/jmod/jlink to add resources to Packages attribute. Also drop use of ModuleDescriptor::conceals ! src/java.base/share/classes/module-info.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java - test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/MyResources_ja_JP.properties + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_ja_JP.properties ! test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesProvider.java ! test/tools/jar/modularJar/Basic.java + test/tools/jar/modularJar/src/foo/jdk/test/foo/resources/foo.properties ! test/tools/jmod/JmodTest.java + test/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties Changeset: 5253fa0f3dda Author: alanb Date: 2016-09-11 07:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5253fa0f3dda java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh failing on Solaris ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh Changeset: 2ec9d358de7d Author: mchung Date: 2016-09-11 17:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2ec9d358de7d Remove assert no longer applicable ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java Changeset: 2c928653b204 Author: alanb Date: 2016-09-12 04:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2c928653b204 Remove ModuleDescriptor::conceals, replace Builder::conceals with contains Update weak module build to disallow exports - src/java.base/share/classes/java/lang/module/Dependence.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleReferenceTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Layer/LayerAndLoadersTest.java + test/java/lang/reflect/Layer/src/m5/module-info.java + test/java/lang/reflect/Layer/src/m5/p/Main.java + test/java/lang/reflect/Layer/src/m6/module-info.java + test/java/lang/reflect/Layer/src/m6/q/Hello.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java ! test/tools/jar/modularJar/src/foo/jdk/test/foo/Foo.java ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/p1/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m3/p3/Main.java ! test/tools/jmod/JmodTest.java Changeset: 5178c925d556 Author: alanb Date: 2016-09-12 11:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5178c925d556 javax/management/remote/mandatory/connection/ObjectInputStreamWithLoaderNullCheckTest.java failing ! test/javax/management/remote/mandatory/connection/ObjectInputStreamWithLoaderNullCheckTest.java Changeset: 4d549789c208 Author: alanb Date: 2016-09-12 12:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4d549789c208 jmod tool failing on Windows ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java Changeset: 334c1cb9fb14 Author: alanb Date: 2016-09-12 14:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/334c1cb9fb14 Minor javadoc updates ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: 993aaf8c180c Author: mchung Date: 2016-09-12 14:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/993aaf8c180c Update stack traces with slash-based syntax ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! test/java/lang/StackTraceElement/PublicConstructor.java ! test/java/lang/StackTraceElement/WithClassLoaderName.java - test/java/lang/StackTraceElement/lib/app/com/app/Main.java - test/java/lang/StackTraceElement/lib/app/com/app/Utils.java - test/java/lang/StackTraceElement/lib/app/module-info.java + test/java/lang/StackTraceElement/lib/m1/com/app/Main.java + test/java/lang/StackTraceElement/lib/m1/com/app/Utils.java + test/java/lang/StackTraceElement/lib/m1/module-info.java ! test/java/lang/StackWalker/VerifyStackTrace.java Changeset: 4dd6d61dd210 Author: alanb Date: 2016-09-13 03:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4dd6d61dd210 Update ServiceLoader to invoke public static provider method ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! test/java/util/ServiceLoader/modules/Basic.java ! test/java/util/ServiceLoader/modules/modules/bananascript/module-info.java ! test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScriptEngineFactory.java ! test/java/util/ServiceLoader/modules/src/pearscript/org/pear/PearScriptEngineFactory.java Changeset: 1cacbae9a02f Author: alanb Date: 2016-09-13 13:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1cacbae9a02f Minor SL clean-up ! src/java.base/share/classes/java/util/ServiceLoader.java Changeset: 8927fa556ac9 Author: alanb Date: 2016-09-13 16:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8927fa556ac9 Minor SL clean-up ! src/java.base/share/classes/java/util/ServiceLoader.java Changeset: 917b22d131a4 Author: mchung Date: 2016-09-13 17:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/917b22d131a4 Add jlink --add-module ALL-MODULE-PATH support ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java + test/tools/jlink/basic/AllModulePath.java ! test/tools/jlink/basic/BasicTest.java + test/tools/jlink/basic/src/m1/module-info.java + test/tools/jlink/basic/src/m1/p/ListModules.java Changeset: 88d07517aa10 Author: alanb Date: 2016-09-14 04:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88d07517aa10 Add placeholder for JVMTI AddModuleExportsPrivate ! src/java.base/share/native/include/jvmti.h Changeset: ac20e4896aef Author: alanb Date: 2016-09-14 13:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ac20e4896aef SL javadoc clarification ! src/java.base/share/classes/java/util/ServiceLoader.java Changeset: cddd102650fd Author: mr Date: 2016-09-14 09:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cddd102650fd Make `java --list-modules` write to stdout ! src/java.base/share/native/libjli/java.c Changeset: 942f68f97f84 Author: mchung Date: 2016-09-14 11:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/942f68f97f84 Minor cleanup for removal of exports dynamic ! make/src/classes/build/tools/module/GenModuleInfoSource.java Changeset: 19e145f19058 Author: alanb Date: 2016-09-14 13:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19e145f19058 jdk.jdi requires jdk.jdwp.agent ! src/jdk.jdi/share/classes/module-info.java Changeset: a11d4b5da188 Author: mchung Date: 2016-09-14 14:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a11d4b5da188 Deserialized StackTraceElement::toString should print the compacted representation ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/Throwable.java ! src/java.base/share/classes/jdk/internal/module/Modules.java Changeset: 2f079af25e82 Author: mchung Date: 2016-09-14 15:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2f079af25e82 Add javadoc for jdk.jdwp.agent ! src/jdk.jdwp.agent/share/classes/module-info.java Changeset: 851645a61277 Author: alanb Date: 2016-09-14 17:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/851645a61277 Add comments to areas undergoing change ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java Changeset: 08a361c50b48 Author: mchung Date: 2016-09-14 19:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/08a361c50b48 jmod --other-files to add files that get added in the image at link time ! make/copy/Copy-java.base.gmk ! make/copy/CopyCommon.gmk ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ArchiveEntryResourcePoolEntry.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/DirArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModularJarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ResourcePoolEntry.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/JLinkTest.java ! test/tools/jlink/plugins/FileCopierPluginTest.java Changeset: f2be0ae2a4d4 Author: mchung Date: 2016-09-14 19:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f2be0ae2a4d4 Merge From sundararajan.athijegannathan at oracle.com Thu Sep 15 14:31:54 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 15 Sep 2016 20:01:54 +0530 Subject: RFR 8160063: Provide a means to disable a plugin via the command line Message-ID: <57DAB0DA.1030109@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 * Adding --disable- option for any plugin that is auto-enabled. * Removed ad-hoc "none" option of generate-jli-classes plugin. * Simple test to make sure --disable-generate-jli-classes option is accepted. * Manual verified that when generate-jli-classes plugin is deactivated, JLI classes are not generated. Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Thu Sep 15 14:33:52 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 15 Sep 2016 20:03:52 +0530 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <57DAB0DA.1030109@oracle.com> References: <57DAB0DA.1030109@oracle.com> Message-ID: <57DAB150.7090900@oracle.com> Also piggybacking clean-up in unusued code in JLinkTask.java (Section enum) -Sundar On 15/09/16, 8:01 PM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is > auto-enabled. > * Removed ad-hoc "none" option of generate-jli-classes plugin. > * Simple test to make sure --disable-generate-jli-classes option is > accepted. > * Manual verified that when generate-jli-classes plugin is > deactivated, JLI classes are not generated. > > Thanks, > -Sundar > From claes.redestad at oracle.com Thu Sep 15 14:34:11 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Sep 2016 16:34:11 +0200 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <57DAB0DA.1030109@oracle.com> References: <57DAB0DA.1030109@oracle.com> Message-ID: <31b24994-4173-124a-8674-b80fb8fe7d08@oracle.com> +1 I agree it's good with a standard way to disable plugins like this on a high level. This also solves an issue I was just about to file a bug for where the GenerateJLIClassesPlugin generates a few basic forms even when "disabled" with =none /Claes On 2016-09-15 16:31, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is > auto-enabled. > * Removed ad-hoc "none" option of generate-jli-classes plugin. > * Simple test to make sure --disable-generate-jli-classes option is > accepted. > * Manual verified that when generate-jli-classes plugin is > deactivated, JLI classes are not generated. > > Thanks, > -Sundar > From james.laskey at oracle.com Thu Sep 15 14:36:44 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 15 Sep 2016 11:36:44 -0300 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <57DAB0DA.1030109@oracle.com> References: <57DAB0DA.1030109@oracle.com> Message-ID: <9559FA84-5DA2-486E-AD92-AE00E78C6ACC@oracle.com> +1 > On Sep 15, 2016, at 11:31 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is auto-enabled. > * Removed ad-hoc "none" option of generate-jli-classes plugin. > * Simple test to make sure --disable-generate-jli-classes option is accepted. > * Manual verified that when generate-jli-classes plugin is deactivated, JLI classes are not generated. > > Thanks, > -Sundar > From peter.levart at gmail.com Thu Sep 15 14:54:19 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 Sep 2016 16:54:19 +0200 Subject: #ServiceLoaderEnhancements Message-ID: Hi, Reading number (2) of the proposal... the static provider() method (declared by "provider class") and returning a "provider object" sounds confusing when coupled with number (3) which proposes a ServiceLoader.Provider interface. Should Provider interface be renamed to ProviderFactory? Or should rather ServiceLoader documentation be revised to stop talking about service providers and talk about service types(s) and service implementation(s) or service implmenetation classes instead? It's OK for a module to "provide" a service of some "service type" with some "service implementation class", but it is strange to call the implementation class a provider class and an instance of it a provider object. I think there's one level of indirection that is too much in the speak currently. If you agree with above, then I propose the static method to simply be called "getInstance()" and (to make it parallel with constructor) don't require it to be a public method in a public class if the service is provided by a module. One thing that is not clear is whether the yyy in "provides xxx with yyy" directive of module declaration must be a concrete class and a subtype of service type when the service is obtained via a static method. For example, is the following a valid configuration: Service type A, implementation class B (a subtype of A), static method declared in C (unrelated to A) with return type B (or A or anything between A and B?). I think the constraints could be more easily understood if the method was called getInstance() and required to have the same return type as the declaring class. The service implementation class could then be anything (perhaps a subtype of the methods's return type/declaring class). The interface in (3) can then be called ServiceLoader.Provider. What do you think? From mandy.chung at oracle.com Thu Sep 15 15:03:12 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Sep 2016 08:03:12 -0700 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <57DAB0DA.1030109@oracle.com> References: <57DAB0DA.1030109@oracle.com> Message-ID: > On Sep 15, 2016, at 7:31 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is auto-enabled. A consistent mechanism to disable a plugin is good. The Section class is not used anywhere. Should the entire class be removed? Or move it to JmodArchive to replace the final String constants. Can you include "--disable-? and its help message in jlink ?-list-plugins help output? It can be placed toward the bottom before: For options requiring a , the value will be a comma separated list of elements each using one the following forms: glob: regex: @ where filename is the name of a file containing patterns to be used, one pattern per line Can you also fix the two long lines above as missing \n in main.extended.help.footer Otherwise, looks fine. Mandy From Alan.Bateman at oracle.com Thu Sep 15 15:26:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Sep 2016 08:26:30 -0700 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <57DAB0DA.1030109@oracle.com> References: <57DAB0DA.1030109@oracle.com> Message-ID: <5604826e-6b8e-7e11-2709-c7b8f077c093@oracle.com> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is > auto-enabled. > Should this be --disable-plugin rather than synthesizing an option? Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified. -Alan From Alan.Bateman at oracle.com Thu Sep 15 15:51:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Sep 2016 08:51:35 -0700 Subject: #ServiceLoaderEnhancements In-Reply-To: References: Message-ID: On 15/09/2016 07:54, Peter Levart wrote: > One thing that is not clear is whether the yyy in "provides xxx with > yyy" directive of module declaration must be a concrete class and a > subtype of service type when the service is obtained via a static > method. For example, is the following a valid configuration: Service > type A, implementation class B (a subtype of A), static method > declared in C (unrelated to A) with return type B (or A or anything > between A and B?). If yyy defines the static factory method then it does not need to be a sub-type of xxx, the return type from the public provider() method just needs to be xxx or a sub-type of. So the example is okay, no need for C to extend/implement A. I should note that the implementation isn't aligned with this yet but there are updates to both javac and SL coming that will align it with the current proposal. -Alan From mandy.chung at oracle.com Thu Sep 15 16:06:25 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Sep 2016 09:06:25 -0700 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <5604826e-6b8e-7e11-2709-c7b8f077c093@oracle.com> References: <57DAB0DA.1030109@oracle.com> <5604826e-6b8e-7e11-2709-c7b8f077c093@oracle.com> Message-ID: <76B3E45D-BB79-4488-A623-D45FCB450D3C@oracle.com> > On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: > > On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 >> >> * Adding --disable- option for any plugin that is auto-enabled. >> > Should this be --disable-plugin rather than synthesizing an option? > jlink --disable-plugin generate-jli-classes does read better. The option is more obvious. The other way to look at this option is an option provided by each plugin like --generate-jli-classes=none. Given that the plugin name is arbitrary, "--disable-plugin ? would be more obvious and I have no issue to go with that. > Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified. Good question. --disable-generate-jli-classes removes the plugin from the map and so it won?t run. When an unknown plugin is specified, I suggest it should be fatal and I think that?s the current behavior. If both the option to disable and to enable are specified (in any order), fatal would be helpful such that the user is prompted to ask one thing not the other. Mandy From paul.sandoz at oracle.com Thu Sep 15 16:27:47 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Sep 2016 09:27:47 -0700 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <76B3E45D-BB79-4488-A623-D45FCB450D3C@oracle.com> References: <57DAB0DA.1030109@oracle.com> <5604826e-6b8e-7e11-2709-c7b8f077c093@oracle.com> <76B3E45D-BB79-4488-A623-D45FCB450D3C@oracle.com> Message-ID: <66FB9529-7FF8-40E7-9B26-D4DA1A6A5533@oracle.com> > On 15 Sep 2016, at 09:06, Mandy Chung wrote: > > >> On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: >> >> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 >>> >>> * Adding --disable- option for any plugin that is auto-enabled. >>> >> Should this be --disable-plugin rather than synthesizing an option? >> > > jlink --disable-plugin generate-jli-classes does read better. The option is more obvious. > > The other way to look at this option is an option provided by each plugin like --generate-jli-classes=none. > > Given that the plugin name is arbitrary, "--disable-plugin ? would be more obvious and I have no issue to go with that. > Yes, that is better. I am guessing the "-disable-? approach was proposed to be consistent with the plugin configuration options, so perhaps that should also be reconsidered? Paul. > >> Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified. > > Good question. --disable-generate-jli-classes removes the plugin from the map and so it won?t run. When an unknown plugin is specified, I suggest it should be fatal and I think that?s the current behavior. > > If both the option to disable and to enable are specified (in any order), fatal would be helpful such that the user is prompted to ask one thing not the other. > > Mandy > From sundararajan.athijegannathan at oracle.com Thu Sep 15 16:36:00 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 15 Sep 2016 22:06:00 +0530 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: <66FB9529-7FF8-40E7-9B26-D4DA1A6A5533@oracle.com> References: <57DAB0DA.1030109@oracle.com> <5604826e-6b8e-7e11-2709-c7b8f077c093@oracle.com> <76B3E45D-BB79-4488-A623-D45FCB450D3C@oracle.com> <66FB9529-7FF8-40E7-9B26-D4DA1A6A5533@oracle.com> Message-ID: With "--disable ", user can pass any plugin name - even the plugins that are *not* auto-enabled. We may have to check and report. But, --disable- options are added only for auto-enabled plugins. --disable- will automatically fail as "unsupported option". -Sundar On 9/15/2016 9:57 PM, Paul Sandoz wrote: >> On 15 Sep 2016, at 09:06, Mandy Chung wrote: >> >> >>> On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: >>> >>> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: >>> >>>> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 >>>> >>>> * Adding --disable- option for any plugin that is auto-enabled. >>>> >>> Should this be --disable-plugin rather than synthesizing an option? >>> >> jlink --disable-plugin generate-jli-classes does read better. The option is more obvious. >> >> The other way to look at this option is an option provided by each plugin like --generate-jli-classes=none. >> >> Given that the plugin name is arbitrary, "--disable-plugin ? would be more obvious and I have no issue to go with that. >> > Yes, that is better. I am guessing the "-disable-? approach was proposed to be consistent with the plugin configuration options, so perhaps that should also be reconsidered? > > Paul. > >>> Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified. >> Good question. --disable-generate-jli-classes removes the plugin from the map and so it won?t run. When an unknown plugin is specified, I suggest it should be fatal and I think that?s the current behavior. >> >> If both the option to disable and to enable are specified (in any order), fatal would be helpful such that the user is prompted to ask one thing not the other. >> >> Mandy >> From mandy.chung at oracle.com Thu Sep 15 16:50:10 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Sep 2016 09:50:10 -0700 Subject: RFR 8160063: Provide a means to disable a plugin via the command line In-Reply-To: References: <57DAB0DA.1030109@oracle.com> <5604826e-6b8e-7e11-2709-c7b8f077c093@oracle.com> <76B3E45D-BB79-4488-A623-D45FCB450D3C@oracle.com> <66FB9529-7FF8-40E7-9B26-D4DA1A6A5533@oracle.com> Message-ID: <4ED3733F-EE92-4F04-A6B7-1DE98B5890F5@oracle.com> -?disable-plugin can allow any plugin if present, regardless whether it?s auto-enabled or not. If the plugin is disabled, -?disable-plugin will just be nop. Looking at Plugin.State::DISABLED:
  • DISABLED: The plugin is not exposed in help and will be not called.
  • It?s unclear this is needed. I guess this was defined to allow a plugin to handle the disable option like --generate-jli-classes=none. I don?t see when a plugin is added to jlink with DISABLED state. We should revisit Plugin.State enum. Mandy > On Sep 15, 2016, at 9:36 AM, Sundararajan Athijegannathan wrote: > > With "--disable ", user can pass any plugin name - even the > plugins that are *not* auto-enabled. We may have to check and report. > But, --disable- options are added only for auto-enabled > plugins. > > --disable- will automatically fail as > "unsupported option". > > -Sundar > > > On 9/15/2016 9:57 PM, Paul Sandoz wrote: >>> On 15 Sep 2016, at 09:06, Mandy Chung wrote: >>> >>> >>>> On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: >>>> >>>> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: >>>> >>>>> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 >>>>> >>>>> * Adding --disable- option for any plugin that is auto-enabled. >>>>> >>>> Should this be --disable-plugin rather than synthesizing an option? >>>> >>> jlink --disable-plugin generate-jli-classes does read better. The option is more obvious. >>> >>> The other way to look at this option is an option provided by each plugin like --generate-jli-classes=none. >>> >>> Given that the plugin name is arbitrary, "--disable-plugin ? would be more obvious and I have no issue to go with that. >>> >> Yes, that is better. I am guessing the "-disable-? approach was proposed to be consistent with the plugin configuration options, so perhaps that should also be reconsidered? >> >> Paul. >> >>>> Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified. >>> Good question. --disable-generate-jli-classes removes the plugin from the map and so it won?t run. When an unknown plugin is specified, I suggest it should be fatal and I think that?s the current behavior. >>> >>> If both the option to disable and to enable are specified (in any order), fatal would be helpful such that the user is prompted to ask one thing not the other. >>> >>> Mandy >>> > From Alan.Bateman at oracle.com Thu Sep 15 17:07:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Sep 2016 10:07:34 -0700 Subject: JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500) Message-ID: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> The EA download [1] has been refreshed with new builds that are mostly aligned with the current proposals for JPMS issues [2]. Not everything is there yet of course (and some areas need a few more iterations) but there is enough to test and try things out. For #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation then the initial support for `weak module` and `exports private` is in place. These are probably the highest priority changes to try out. The changes to setAccessible in #AwkwardStrongEncapsulation is going to be disruptive and will no doubt expose hacks in many areas. We've run into several of these already. The command line option to allow existing code to break into non-public types/members is --add-exports-private. The format of the value passed to this option is the same--add-exports. With #AddExportsInManifest then there are equivalents in the application JAR main manifest to try out too. As part of the #ClassLoaderNames then the format of the stack trace elements has changed. For #ServiceLoaderEnhancements then the implementation is mostly aligned, except for the static factory method which needs an update to javac and SL to align with the proposal (should be there soon, just not in this build). Several people have brought up #ResourceEncapsulation and #ClassFilesAsResources here so it would be good to try this out. As always, the most valuable feedback is from those trying out the builds so please let us know what you have tried and what works or doesn't work. -Alan [1] https://jdk9.java.net/jigsaw/ [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009365.html From lois.foltan at oracle.com Thu Sep 15 17:19:52 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Thu, 15 Sep 2016 17:19:52 +0000 Subject: hg: jigsaw/jake/jdk: 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader Message-ID: <201609151719.u8FHJqC2001930@aojmv0008.oracle.com> Changeset: b25ebe289b7c Author: lfoltan Date: 2016-09-15 11:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b25ebe289b7c 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader Summary: Fix test to adhere to this prohibited package check Reviewed-by: hseigel, mchung ! test/java/lang/reflect/Module/WithSecurityManager.java From lois.foltan at oracle.com Thu Sep 15 17:20:03 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Thu, 15 Sep 2016 17:20:03 +0000 Subject: hg: jigsaw/jake/hotspot: 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader Message-ID: <201609151720.u8FHK37V002001@aojmv0008.oracle.com> Changeset: de2b914558cd Author: lfoltan Date: 2016-09-15 11:25 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/de2b914558cd 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader Summary: Added new prohibited package check to JVM_DefineModule and JVM_AddModulePackage Reviewed-by: hseigel, mchung ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/oops/instanceKlass.cpp ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMDefineModule.java From peter.levart at gmail.com Thu Sep 15 19:34:44 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 Sep 2016 21:34:44 +0200 Subject: #ServiceLoaderEnhancements In-Reply-To: References: Message-ID: <8932a523-fee4-9099-4a9a-a138e1de5892@gmail.com> On 09/15/2016 05:51 PM, Alan Bateman wrote: > On 15/09/2016 07:54, Peter Levart wrote: > >> One thing that is not clear is whether the yyy in "provides xxx with >> yyy" directive of module declaration must be a concrete class and a >> subtype of service type when the service is obtained via a static >> method. For example, is the following a valid configuration: Service >> type A, implementation class B (a subtype of A), static method >> declared in C (unrelated to A) with return type B (or A or anything >> between A and B?). > If yyy defines the static factory method then it does not need to be a > sub-type of xxx, the return type from the public provider() method > just needs to be xxx or a sub-type of. So the example is okay, no need > for C to extend/implement A. > > I should note that the implementation isn't aligned with this yet but > there are updates to both javac and SL coming that will align it with > the current proposal. > > -Alan ...so yyy can be any class or interface. It's provider() method can even instantiate and return an instance of some class that is not part of the module that provides the service. Hm... Regards, Peter From alex.buckley at oracle.com Thu Sep 15 19:39:35 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 15 Sep 2016 12:39:35 -0700 Subject: #ServiceLoaderEnhancements In-Reply-To: <8932a523-fee4-9099-4a9a-a138e1de5892@gmail.com> References: <8932a523-fee4-9099-4a9a-a138e1de5892@gmail.com> Message-ID: <57DAF8F7.7070504@oracle.com> Best to wait for the spec. On 9/15/2016 12:34 PM, Peter Levart wrote: > On 09/15/2016 05:51 PM, Alan Bateman wrote: >> On 15/09/2016 07:54, Peter Levart wrote: >> >>> One thing that is not clear is whether the yyy in "provides xxx with >>> yyy" directive of module declaration must be a concrete class and a >>> subtype of service type when the service is obtained via a static >>> method. For example, is the following a valid configuration: Service >>> type A, implementation class B (a subtype of A), static method >>> declared in C (unrelated to A) with return type B (or A or anything >>> between A and B?). >> If yyy defines the static factory method then it does not need to be a >> sub-type of xxx, the return type from the public provider() method >> just needs to be xxx or a sub-type of. So the example is okay, no need >> for C to extend/implement A. >> >> I should note that the implementation isn't aligned with this yet but >> there are updates to both javac and SL coming that will align it with >> the current proposal. >> >> -Alan > > ...so yyy can be any class or interface. It's provider() method can even > instantiate and return an instance of some class that is not part of the > module that provides the service. Hm... > > Regards, Peter > From mandy.chung at oracle.com Thu Sep 15 20:14:59 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 20:14:59 +0000 Subject: hg: jigsaw/jake/jdk: Fixup test @modules to access private field Message-ID: <201609152014.u8FKExla016732@aojmv0008.oracle.com> Changeset: 570f2e8d2b6c Author: mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/570f2e8d2b6c Fixup test @modules to access private field ! test/sun/security/krb5/tools/KtabZero.java From mandy.chung at oracle.com Thu Sep 15 21:16:31 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:16:31 +0000 Subject: hg: jigsaw/jake: 7 new changesets Message-ID: <201609152116.u8FLGVRq003263@aojmv0008.oracle.com> Changeset: 24efaaddd376 Author: sundar Date: 2016-09-08 14:35 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/24efaaddd376 8165595: Main class should be set for nashorn modules Reviewed-by: jlaskey, erikj ! make/CreateJmods.gmk Changeset: 6e62bbd02e6b Author: lana Date: 2016-09-08 22:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6e62bbd02e6b Merge Changeset: 3a0e05d75dec Author: sundar Date: 2016-09-12 18:25 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3a0e05d75dec 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java Reviewed-by: alanb, jlaskey ! make/CreateJmods.gmk Changeset: 3ec350f5f32a Author: naoto Date: 2016-09-12 09:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3ec350f5f32a 8165605: Thai resources in jdk.localedata cause split package issue with java.base Reviewed-by: mchung, erikj ! make/CompileJavaModules.gmk Changeset: 1da725c7601e Author: mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1da725c7601e Merge ! make/CompileJavaModules.gmk ! make/CreateJmods.gmk Changeset: 73b0b2cf7c44 Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/73b0b2cf7c44 Added tag jdk-9+136 for changeset 3ec350f5f32a ! .hgtags Changeset: 7b25afe560e2 Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7b25afe560e2 Merge From mandy.chung at oracle.com Thu Sep 15 21:16:37 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:16:37 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201609152116.u8FLGb1D003320@aojmv0008.oracle.com> Changeset: 258cf18fa7fc Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/258cf18fa7fc Added tag jdk-9+136 for changeset aa053a3faf26 ! .hgtags Changeset: cbdc0699e357 Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/cbdc0699e357 Merge From mandy.chung at oracle.com Thu Sep 15 21:16:46 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:16:46 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201609152116.u8FLGkv0003414@aojmv0008.oracle.com> Changeset: 6bddcf692e1d Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6bddcf692e1d Added tag jdk-9+136 for changeset a20da289f646 ! .hgtags Changeset: 89d191b6c6ee Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89d191b6c6ee Merge ! .hgtags From mandy.chung at oracle.com Thu Sep 15 21:16:58 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:16:58 +0000 Subject: hg: jigsaw/jake/jaxp: 6 new changesets Message-ID: <201609152116.u8FLGw6U003493@aojmv0008.oracle.com> Changeset: bba703e3281b Author: joehw Date: 2016-09-07 11:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bba703e3281b 8165116: redirect function is not allowed even with enableExtensionFunctions Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TransletOutput.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java Changeset: 540334ae53fe Author: fyuan Date: 2016-09-08 12:33 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/540334ae53fe 8165617: Cleanup whitespace in jaxp/test Summary: Removed the extra LF from the java files Reviewed-by: joehw ! src/java.xml/share/classes/javax/xml/datatype/XMLGregorianCalendar.java ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java ! test/javax/xml/jaxp/functional/javax/xml/datatype/ptests/DurationTest.java ! test/javax/xml/jaxp/functional/javax/xml/datatype/ptests/FactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/datatype/ptests/XMLGregorianCalendarTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DBFNamespaceTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DocumentBuilderFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DocumentBuilderImpl01.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/FactoryConfErrorTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXFactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserFactTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest02.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest03.java ! test/javax/xml/jaxp/functional/javax/xml/stream/ptests/XMLEventFactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/stream/ptests/XMLInputFactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/Bug6384418Test.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/DOMResultTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/ErrorListenerTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/SAXSourceTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/SAXTFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/StreamResultTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TfClearParamTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerExcpTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest02.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest03.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/URIResolverTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/othervm/TFCErrorTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/SchemaFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/TypeInfoProviderTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/ValidatorHandlerTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/ValidatorTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathExpressionTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathFunctionResolverTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/AttrTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/CommentTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/DocumentTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/DocumentTypeTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/DomImplementationTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/ElementTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/EntityChildTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NamedNodeMapTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeListTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NotationTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/PITest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/TextTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/TypeInfoTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/AttrImplTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/AttributesNSTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/AttributesTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/ContentHandlerTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/DefaultHandlerTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/EHFatalTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/NSSupportTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/NSTableTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/ParserAdapterTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/ResolverTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/SAXParserNSTableTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLFilterCBTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLFilterTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderAdapterTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderFactoryTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java ! test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderTest.java ! test/javax/xml/jaxp/functional/test/astro/AstroTest.java ! test/javax/xml/jaxp/functional/test/astro/DocumentLSTest.java ! test/javax/xml/jaxp/functional/test/astro/NamespaceContextTest.java ! test/javax/xml/jaxp/functional/test/astro/SAX201Test.java ! test/javax/xml/jaxp/functional/test/astro/SchemaValidationTest.java ! test/javax/xml/jaxp/functional/test/astro/XPathAPITest.java ! test/javax/xml/jaxp/functional/test/auctionportal/AuctionController.java ! test/javax/xml/jaxp/functional/test/auctionportal/AuctionItemRepository.java ! test/javax/xml/jaxp/functional/test/auctionportal/UserController.java ! test/javax/xml/jaxp/functional/test/gaptest/Bug4511326.java ! test/javax/xml/jaxp/functional/test/gaptest/Bug4512806.java ! test/javax/xml/jaxp/functional/test/gaptest/Bug4515047.java ! test/javax/xml/jaxp/functional/test/gaptest/Bug4515660.java ! test/javax/xml/jaxp/functional/test/gaptest/Bug4693341.java ! test/javax/xml/jaxp/functional/test/gaptest/Bug4848653.java ! test/javax/xml/jaxp/functional/test/gaptest/Bug4858685.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/test/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider1/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/module-info.java ! test/javax/xml/jaxp/unittest/common/Bug6350682.java ! test/javax/xml/jaxp/unittest/common/Bug6723276Test.java ! test/javax/xml/jaxp/unittest/common/Bug6941169Test.java ! test/javax/xml/jaxp/unittest/common/Bug7143711Test.java ! test/javax/xml/jaxp/unittest/common/Sources.java ! test/javax/xml/jaxp/unittest/common/TestSAXDriver.java ! test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java ! test/javax/xml/jaxp/unittest/common/ValidationWarningsTest.java ! test/javax/xml/jaxp/unittest/datatype/Bug6320118.java ! test/javax/xml/jaxp/unittest/datatype/Bug6937951Test.java ! test/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java ! test/javax/xml/jaxp/unittest/datatype/Bug7042647Test.java ! test/javax/xml/jaxp/unittest/datatype/DatatypeFactoryTest.java ! test/javax/xml/jaxp/unittest/datatype/DurationTest.java ! test/javax/xml/jaxp/unittest/datatype/FactoryFindTest.java ! test/javax/xml/jaxp/unittest/datatype/JDK8068839Test.java ! test/javax/xml/jaxp/unittest/datatype/XMLGregorianCalendarTest.java ! test/javax/xml/jaxp/unittest/dom/Bug4915524.java ! test/javax/xml/jaxp/unittest/dom/Bug4915748.java ! test/javax/xml/jaxp/unittest/dom/Bug4966082.java ! test/javax/xml/jaxp/unittest/dom/Bug4966138.java ! test/javax/xml/jaxp/unittest/dom/Bug4966142.java ! test/javax/xml/jaxp/unittest/dom/Bug4966143.java ! test/javax/xml/jaxp/unittest/dom/Bug6339023.java ! test/javax/xml/jaxp/unittest/dom/Bug6355326.java ! test/javax/xml/jaxp/unittest/dom/Bug6367542.java ! test/javax/xml/jaxp/unittest/dom/Bug6520131.java ! test/javax/xml/jaxp/unittest/dom/Bug6521260.java ! test/javax/xml/jaxp/unittest/dom/Bug6582545Test.java ! test/javax/xml/jaxp/unittest/dom/Bug6879614Test.java ! test/javax/xml/jaxp/unittest/dom/CR6333993Test.java ! test/javax/xml/jaxp/unittest/dom/CR6517707Test.java ! test/javax/xml/jaxp/unittest/dom/CR6517717Test.java ! test/javax/xml/jaxp/unittest/dom/CR6909336Test.java ! test/javax/xml/jaxp/unittest/dom/DOMConfigurationTest.java ! test/javax/xml/jaxp/unittest/dom/DOMXPathTest.java ! test/javax/xml/jaxp/unittest/dom/ElementTraversal.java ! test/javax/xml/jaxp/unittest/dom/JdkXmlDomTest.java ! test/javax/xml/jaxp/unittest/dom/TCKEncodingTest.java ! test/javax/xml/jaxp/unittest/dom/ls/Bug4973153.java ! test/javax/xml/jaxp/unittest/dom/ls/Bug6290947.java ! test/javax/xml/jaxp/unittest/dom/ls/Bug6354955.java ! test/javax/xml/jaxp/unittest/dom/ls/Bug6376823.java ! test/javax/xml/jaxp/unittest/dom/ls/Bug6710741Test.java ! test/javax/xml/jaxp/unittest/dom/ls/LSParserTCKTest.java ! test/javax/xml/jaxp/unittest/dom/ls/LSParserTest.java ! test/javax/xml/jaxp/unittest/dom/ls/LSSerializerTest.java ! test/javax/xml/jaxp/unittest/parsers/Bug4674384_MAX_OCCURS_Test.java ! test/javax/xml/jaxp/unittest/parsers/Bug4934208.java ! test/javax/xml/jaxp/unittest/parsers/Bug4967002.java ! test/javax/xml/jaxp/unittest/parsers/Bug4985486.java ! test/javax/xml/jaxp/unittest/parsers/Bug4991020.java ! test/javax/xml/jaxp/unittest/parsers/Bug4991946.java ! test/javax/xml/jaxp/unittest/parsers/Bug5010072.java ! test/javax/xml/jaxp/unittest/parsers/Bug5025825.java ! test/javax/xml/jaxp/unittest/parsers/Bug6309988.java ! test/javax/xml/jaxp/unittest/parsers/Bug6341770.java ! test/javax/xml/jaxp/unittest/parsers/Bug6361283.java ! test/javax/xml/jaxp/unittest/parsers/Bug6506304Test.java ! test/javax/xml/jaxp/unittest/parsers/Bug6518733.java ! test/javax/xml/jaxp/unittest/parsers/Bug6564400.java ! test/javax/xml/jaxp/unittest/parsers/Bug6573786.java ! test/javax/xml/jaxp/unittest/parsers/Bug6573786ErrorHandler.java ! test/javax/xml/jaxp/unittest/parsers/Bug6594813.java ! test/javax/xml/jaxp/unittest/parsers/Bug6608841.java ! test/javax/xml/jaxp/unittest/parsers/Bug6690015.java ! test/javax/xml/jaxp/unittest/parsers/Bug6760982.java ! test/javax/xml/jaxp/unittest/parsers/Bug6849942Test.java ! test/javax/xml/jaxp/unittest/parsers/Bug7157608Test.java ! test/javax/xml/jaxp/unittest/parsers/Bug7166896Test.java ! test/javax/xml/jaxp/unittest/parsers/Bug8003147Test.java ! test/javax/xml/jaxp/unittest/parsers/Bug8003147TestClass.java ! test/javax/xml/jaxp/unittest/parsers/Bug8073385.java ! test/javax/xml/jaxp/unittest/parsers/FactoryFindTest.java ! test/javax/xml/jaxp/unittest/parsers/MyDefaultHandler.java ! test/javax/xml/jaxp/unittest/parsers/MyErrorHandler.java ! test/javax/xml/jaxp/unittest/parsers/ParseEmptyStream.java ! test/javax/xml/jaxp/unittest/parsers/SupplementaryChars.java ! test/javax/xml/jaxp/unittest/parsers/xinclude/Bug6794483Test.java ! test/javax/xml/jaxp/unittest/sax/Attributes2ImplTest.java ! test/javax/xml/jaxp/unittest/sax/Bug6889654Test.java ! test/javax/xml/jaxp/unittest/sax/Bug6925410Test.java ! test/javax/xml/jaxp/unittest/sax/Bug6949607Test.java ! test/javax/xml/jaxp/unittest/sax/Bug6992561Test.java ! test/javax/xml/jaxp/unittest/sax/Bug7057778Test.java ! test/javax/xml/jaxp/unittest/sax/DefaultHandler2Test.java ! test/javax/xml/jaxp/unittest/sax/IssueTracker56Test.java ! test/javax/xml/jaxp/unittest/sax/MyDefaultHandler2.java ! test/javax/xml/jaxp/unittest/sax/NSSupportTest.java ! test/javax/xml/jaxp/unittest/sax/SAXExceptionExt.java ! test/javax/xml/jaxp/unittest/sax/XMLReaderTest.java ! test/javax/xml/jaxp/unittest/stream/AttributeLocalNameTest/AttributeLocalNameTest.java ! test/javax/xml/jaxp/unittest/stream/Bug6370703.java ! test/javax/xml/jaxp/unittest/stream/Bug6378422.java ! test/javax/xml/jaxp/unittest/stream/Bug6380870.java ! test/javax/xml/jaxp/unittest/stream/Bug6489502.java ! test/javax/xml/jaxp/unittest/stream/Bug6509774.java ! test/javax/xml/jaxp/unittest/stream/Bug6688002Test.java ! test/javax/xml/jaxp/unittest/stream/Bug6976938Test.java ! test/javax/xml/jaxp/unittest/stream/CoalesceTest/CoalesceTest.java ! test/javax/xml/jaxp/unittest/stream/EntitiesTest/EntityTest.java ! test/javax/xml/jaxp/unittest/stream/EventReaderDelegateTest.java ! test/javax/xml/jaxp/unittest/stream/EventsTest/Issue41Test.java ! test/javax/xml/jaxp/unittest/stream/EventsTest/Issue48Test.java ! test/javax/xml/jaxp/unittest/stream/EventsTest/Issue53Test.java ! test/javax/xml/jaxp/unittest/stream/EventsTest/Issue58Test.java ! test/javax/xml/jaxp/unittest/stream/FactoryFindTest.java ! test/javax/xml/jaxp/unittest/stream/IgnoreExternalDTDTest.java ! test/javax/xml/jaxp/unittest/stream/ProcessingInstructionTest/ProcessingInstructionTest.java ! test/javax/xml/jaxp/unittest/stream/StreamReaderDelegateTest.java ! test/javax/xml/jaxp/unittest/stream/XMLEventLocationTest.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6489890.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6555001.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6586466Test.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6613059Test.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6668115Test.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6846133Test.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug8153781.java ! test/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Issue40Test.java ! test/javax/xml/jaxp/unittest/stream/XMLEventWriterTest/ReaderToWriterTest.java ! test/javax/xml/jaxp/unittest/stream/XMLEventWriterTest/XMLEventWriterTest.java ! test/javax/xml/jaxp/unittest/stream/XMLInputFactoryTest/Bug6756677Test.java ! test/javax/xml/jaxp/unittest/stream/XMLInputFactoryTest/Bug6909759Test.java ! test/javax/xml/jaxp/unittest/stream/XMLInputFactoryTest/IssueTracker38.java ! test/javax/xml/jaxp/unittest/stream/XMLInputFactoryTest/MyInputFactory.java ! test/javax/xml/jaxp/unittest/stream/XMLOutputFactoryTest/Bug6846132Test.java ! test/javax/xml/jaxp/unittest/stream/XMLOutputFactoryTest/DuplicateNSDeclarationTest.java ! test/javax/xml/jaxp/unittest/stream/XMLOutputFactoryTest/StreamResultTest.java ! test/javax/xml/jaxp/unittest/stream/XMLResolverTest/XMLResolverTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamExceptionTest/ExceptionTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/Bug6481615.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/Bug6481678.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/HasNextTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/HasNextTypeFilter.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/BOMTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6388460.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6472982Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6767322Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6847819Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/BugTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/DefaultAttributeTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/DoubleXmlnsTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IsValidatingTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Issue44Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Issue47Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IssueTracker24.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IssueTracker35.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IssueTracker70.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Jsr173MR1Req5Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Jsr173MR1Req8Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/NamespaceTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/SupportDTDTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/VoiceXMLDTDTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/XML11Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/AttributeEscapeTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug6452107.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug6600882Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug6675332Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug7037352Test.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/DOMUtil.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/DomUtilTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/EmptyElementTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/EncodingTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/NamespaceTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/NullUriDetectionTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SqeLinuxTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/UnprefixedNameTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/WriterTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/XMLStreamWriterTest.java ! test/javax/xml/jaxp/unittest/transform/Bug4693341Test.java ! test/javax/xml/jaxp/unittest/transform/Bug4892774.java ! test/javax/xml/jaxp/unittest/transform/Bug5073477.java ! test/javax/xml/jaxp/unittest/transform/Bug6175602.java ! test/javax/xml/jaxp/unittest/transform/Bug6206491.java ! test/javax/xml/jaxp/unittest/transform/Bug6216226Test.java ! test/javax/xml/jaxp/unittest/transform/Bug6311448.java ! test/javax/xml/jaxp/unittest/transform/Bug6384805.java ! test/javax/xml/jaxp/unittest/transform/Bug6465722.java ! test/javax/xml/jaxp/unittest/transform/Bug6467808.java ! test/javax/xml/jaxp/unittest/transform/Bug6490380.java ! test/javax/xml/jaxp/unittest/transform/Bug6490921.java ! test/javax/xml/jaxp/unittest/transform/Bug6513892.java ! test/javax/xml/jaxp/unittest/transform/Bug6537167.java ! test/javax/xml/jaxp/unittest/transform/Bug6540545.java ! test/javax/xml/jaxp/unittest/transform/Bug6551616.java ! test/javax/xml/jaxp/unittest/transform/Bug6559595.java ! test/javax/xml/jaxp/unittest/transform/Bug6565260.java ! test/javax/xml/jaxp/unittest/transform/Bug6940416.java ! test/javax/xml/jaxp/unittest/transform/BugDB12665704Test.java ! test/javax/xml/jaxp/unittest/transform/CLITest.java ! test/javax/xml/jaxp/unittest/transform/CR6401137Test.java ! test/javax/xml/jaxp/unittest/transform/CR6551600Test.java ! test/javax/xml/jaxp/unittest/transform/CR6577667Test.java ! test/javax/xml/jaxp/unittest/transform/CR6652519Test.java ! test/javax/xml/jaxp/unittest/transform/CR6689809Test.java ! test/javax/xml/jaxp/unittest/transform/CR6905829Test.java ! test/javax/xml/jaxp/unittest/transform/CR6935697Test.java ! test/javax/xml/jaxp/unittest/transform/CR6941869Test.java ! test/javax/xml/jaxp/unittest/transform/CR6957215Test.java ! test/javax/xml/jaxp/unittest/transform/CR7098746Test.java ! test/javax/xml/jaxp/unittest/transform/DOMResultTest.java ! test/javax/xml/jaxp/unittest/transform/DocumentExtFunc.java ! test/javax/xml/jaxp/unittest/transform/FactoryFindTest.java ! test/javax/xml/jaxp/unittest/transform/Issue2204Test.java ! test/javax/xml/jaxp/unittest/transform/Issue2290Test.java ! test/javax/xml/jaxp/unittest/transform/OpenJDK100017Test.java ! test/javax/xml/jaxp/unittest/transform/SAX2DOMTest.java ! test/javax/xml/jaxp/unittest/transform/SecureProcessingTest.java ! test/javax/xml/jaxp/unittest/transform/SourceTest.java ! test/javax/xml/jaxp/unittest/transform/StAXSourceTest.java ! test/javax/xml/jaxp/unittest/transform/TemplatesTest.java ! test/javax/xml/jaxp/unittest/transform/TransformerFactoryTest.java ! test/javax/xml/jaxp/unittest/transform/TransformerTest.java ! test/javax/xml/jaxp/unittest/transform/TransformerUtilFactory.java ! test/javax/xml/jaxp/unittest/transform/VersionDefaultHandler.java ! test/javax/xml/jaxp/unittest/transform/VersionEventWriter.java ! test/javax/xml/jaxp/unittest/transform/sax/Bug6451633.java ! test/javax/xml/jaxp/unittest/transform/util/DOMUtil.java ! test/javax/xml/jaxp/unittest/transform/util/SAXUtil.java ! test/javax/xml/jaxp/unittest/transform/util/StAXUtil.java ! test/javax/xml/jaxp/unittest/transform/util/StreamUtil.java ! test/javax/xml/jaxp/unittest/util/BOMInputStream.java ! test/javax/xml/jaxp/unittest/util/BaseStAXUT.java ! test/javax/xml/jaxp/unittest/validation/AnyElementTest.java ! test/javax/xml/jaxp/unittest/validation/Bug4966232.java ! test/javax/xml/jaxp/unittest/validation/Bug4966254.java ! test/javax/xml/jaxp/unittest/validation/Bug4969042.java ! test/javax/xml/jaxp/unittest/validation/Bug4969089.java ! test/javax/xml/jaxp/unittest/validation/Bug4969110.java ! test/javax/xml/jaxp/unittest/validation/Bug4969689.java ! test/javax/xml/jaxp/unittest/validation/Bug4969692.java ! test/javax/xml/jaxp/unittest/validation/Bug4969693.java ! test/javax/xml/jaxp/unittest/validation/Bug4969695.java ! test/javax/xml/jaxp/unittest/validation/Bug4969732.java ! test/javax/xml/jaxp/unittest/validation/Bug4970380.java ! test/javax/xml/jaxp/unittest/validation/Bug4970383.java ! test/javax/xml/jaxp/unittest/validation/Bug4970400.java ! test/javax/xml/jaxp/unittest/validation/Bug4970402.java ! test/javax/xml/jaxp/unittest/validation/Bug4970951.java ! test/javax/xml/jaxp/unittest/validation/Bug4971605.java ! test/javax/xml/jaxp/unittest/validation/Bug4971607.java ! test/javax/xml/jaxp/unittest/validation/Bug4972882.java ! test/javax/xml/jaxp/unittest/validation/Bug4986844.java ! test/javax/xml/jaxp/unittest/validation/Bug4987574.java ! test/javax/xml/jaxp/unittest/validation/Bug4988267.java ! test/javax/xml/jaxp/unittest/validation/Bug4988268.java ! test/javax/xml/jaxp/unittest/validation/Bug4988387.java ! test/javax/xml/jaxp/unittest/validation/Bug4996446.java ! test/javax/xml/jaxp/unittest/validation/Bug4997818.java ! test/javax/xml/jaxp/unittest/validation/Bug5011500.java ! test/javax/xml/jaxp/unittest/validation/Bug5072946.java ! test/javax/xml/jaxp/unittest/validation/Bug6378043.java ! test/javax/xml/jaxp/unittest/validation/Bug6449797.java ! test/javax/xml/jaxp/unittest/validation/Bug6457662.java ! test/javax/xml/jaxp/unittest/validation/Bug6467424Test.java ! test/javax/xml/jaxp/unittest/validation/Bug6483188.java ! test/javax/xml/jaxp/unittest/validation/Bug6493687.java ! test/javax/xml/jaxp/unittest/validation/Bug6509668.java ! test/javax/xml/jaxp/unittest/validation/Bug6526547.java ! test/javax/xml/jaxp/unittest/validation/Bug6531160.java ! test/javax/xml/jaxp/unittest/validation/Bug6695843Test.java ! test/javax/xml/jaxp/unittest/validation/Bug6773084Test.java ! test/javax/xml/jaxp/unittest/validation/Bug6859210.java ! test/javax/xml/jaxp/unittest/validation/Bug6925531Test.java ! test/javax/xml/jaxp/unittest/validation/Bug6946312Test.java ! test/javax/xml/jaxp/unittest/validation/Bug6954738_Test.java ! test/javax/xml/jaxp/unittest/validation/CR6708840Test.java ! test/javax/xml/jaxp/unittest/validation/CR6740048.java ! test/javax/xml/jaxp/unittest/validation/ErrorHandlerImpl.java ! test/javax/xml/jaxp/unittest/validation/Issue682Test.java ! test/javax/xml/jaxp/unittest/validation/IssueTracker30.java ! test/javax/xml/jaxp/unittest/validation/JaxpIssue43Test.java ! test/javax/xml/jaxp/unittest/validation/JaxpIssue49.java ! test/javax/xml/jaxp/unittest/validation/LargeMaxOccursTest.java ! test/javax/xml/jaxp/unittest/validation/MultiOccursTest.java ! test/javax/xml/jaxp/unittest/validation/MultiOccursUnboundedTest.java ! test/javax/xml/jaxp/unittest/validation/OccursTest.java ! test/javax/xml/jaxp/unittest/validation/OccursUnboundedTest.java ! test/javax/xml/jaxp/unittest/validation/OccursWildcardTest.java ! test/javax/xml/jaxp/unittest/validation/OccursWildcardUnbounded.java ! test/javax/xml/jaxp/unittest/validation/ParticlesId005Test.java ! test/javax/xml/jaxp/unittest/validation/ParticlesIg004Test.java ! test/javax/xml/jaxp/unittest/validation/ParticlesQ013Test.java ! test/javax/xml/jaxp/unittest/validation/SchemaTest.java ! test/javax/xml/jaxp/unittest/validation/TCKGroupA008Test.java ! test/javax/xml/jaxp/unittest/validation/ValidatorTest.java ! test/javax/xml/jaxp/unittest/validation/XMLDocBuilder.java ! test/javax/xml/jaxp/unittest/validation/XMLSchemaValidator.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6943252Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6963124Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6963468Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6964720Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6967214Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6970890Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6971190Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6974551Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6975265Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6977201Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug6989956Test.java ! test/javax/xml/jaxp/unittest/validation/tck/Bug7014246Test.java ! test/javax/xml/jaxp/unittest/validation/tck/ParticleTest.java ! test/javax/xml/jaxp/unittest/validation/tck/RegexWord.java ! test/javax/xml/jaxp/unittest/xpath/Bug4991857.java ! test/javax/xml/jaxp/unittest/xpath/Bug4991939.java ! test/javax/xml/jaxp/unittest/xpath/Bug4992788.java ! test/javax/xml/jaxp/unittest/xpath/Bug4992793.java ! test/javax/xml/jaxp/unittest/xpath/Bug4992805.java ! test/javax/xml/jaxp/unittest/xpath/ClassLoaderTest.java ! test/javax/xml/jaxp/unittest/xpath/MyClassLoader.java ! test/javax/xml/jaxp/unittest/xpath/SecureProcessingTest.java ! test/javax/xml/jaxp/unittest/xpath/XPathAnyTypeTest.java ! test/javax/xml/jaxp/unittest/xpath/XPathExpAnyTypeTest.java Changeset: f1eafcb0eb71 Author: lana Date: 2016-09-08 22:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f1eafcb0eb71 Merge Changeset: 6ca33c34e9df Author: mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6ca33c34e9df Merge ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/test/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider1/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/module-info.java Changeset: cad105430cf5 Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/cad105430cf5 Added tag jdk-9+136 for changeset f1eafcb0eb71 ! .hgtags Changeset: 0c2361d26582 Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0c2361d26582 Merge From mandy.chung at oracle.com Thu Sep 15 21:17:02 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:17:02 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201609152117.u8FLH2T1003544@aojmv0008.oracle.com> Changeset: 297c16d401c5 Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/297c16d401c5 Added tag jdk-9+136 for changeset 09ec13a99f50 ! .hgtags Changeset: b70d94739d62 Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b70d94739d62 Merge From mandy.chung at oracle.com Thu Sep 15 21:17:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:17:15 +0000 Subject: hg: jigsaw/jake/jdk: 37 new changesets Message-ID: <201609152117.u8FLHGgI003847@aojmv0008.oracle.com> Changeset: 7c15548ab9d6 Author: shurailine Date: 2016-09-06 17:07 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7c15548ab9d6 8148859: Fix module dependences for java/time tests Reviewed-by: alanb, rriggs ! test/java/time/TEST.properties Changeset: 76ba1b74f268 Author: smarks Date: 2016-09-06 16:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/76ba1b74f268 8159404: throw UnsupportedOperationException unconditionally for mutator methods Reviewed-by: martin, psandoz ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/java/util/List.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/Set.java ! test/java/util/Collection/MOAT.java Changeset: 60d7fbe25cd7 Author: igerasim Date: 2016-09-07 10:14 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60d7fbe25cd7 8165413: Typos in javadoc: extra period, wrong number, misspelled word Reviewed-by: weijun, mullan ! src/java.base/share/classes/java/security/DigestInputStream.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/SignatureSpi.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java ! src/java.desktop/share/classes/com/sun/media/sound/DLSInfo.java Changeset: c49bca5eedb3 Author: sundar Date: 2016-09-07 18:35 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c49bca5eedb3 8165503: jlink exclude VM plugin's handling of jvmlibs is wrong Reviewed-by: jlaskey ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java Changeset: 7916fca71cd6 Author: skovalev Date: 2016-09-07 10:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7916fca71cd6 8165604: Fix module dependencies for sun/util/* tests Reviewed-by: rriggs, naoto ! test/sun/util/locale/provider/Bug8038436.java ! test/sun/util/locale/provider/Bug8152817.java ! test/sun/util/resources/Calendar/Bug4518811.java ! test/sun/util/resources/Calendar/Bug4527203.java ! test/sun/util/resources/Locale/Bug4429024.java ! test/sun/util/resources/Locale/Bug4965260.java ! test/sun/util/resources/Locale/Bug6275682.java ! test/sun/util/resources/TimeZone/Bug4938846.java ! test/sun/util/resources/TimeZone/Bug6271396.java ! test/sun/util/resources/TimeZone/Bug6317929.java ! test/sun/util/resources/TimeZone/Bug6377794.java ! test/sun/util/resources/TimeZone/Bug6442006.java ! test/sun/util/resources/cldr/Bug8134250.java ! test/sun/util/resources/cldr/Bug8145136.java Changeset: fc1be68dffc8 Author: ksrini Date: 2016-09-07 10:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fc1be68dffc8 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR Reviewed-by: jrose ! src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java ! src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! test/ProblemList.txt ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/pack200-verifier/data/golden.jar Changeset: 0ac0a3b43f0a Author: smarks Date: 2016-09-07 14:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ac0a3b43f0a 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text Reviewed-by: iris, darcy, mchung ! src/java.base/share/classes/java/lang/Runtime.java Changeset: 30aba497f34e Author: sundar Date: 2016-09-08 20:21 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30aba497f34e 8165697: jlink running on Mac with Windows jmods produces non-runnable image Reviewed-by: jlaskey, redestad ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java Changeset: 32540f1a8a70 Author: coffeys Date: 2016-09-08 16:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32540f1a8a70 8165711: java/net/SetFactoryPermission/SetFactoryPermission.java needs to run in ovm mode Reviewed-by: chegar ! test/java/net/SetFactoryPermission/SetFactoryPermission.java Changeset: c2895dc9842f Author: mchung Date: 2016-09-08 09:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c2895dc9842f 8165563: ClassLoader::getSystemClassLoader will never be null Reviewed-by: alanb, dholmes, psandoz ! src/java.base/share/classes/java/lang/ClassLoader.java Changeset: 10d8bdeabfa5 Author: skovalev Date: 2016-09-08 09:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/10d8bdeabfa5 8165583: Fix module dependencies for jdk/java/util/* tests Reviewed-by: alanb ! test/java/util/Calendar/Bug4302966.java ! test/java/util/Date/Bug8135055.java ! test/java/util/Formatter/FormatLocale.java ! test/java/util/ResourceBundle/modules/security/TestPermission.java ! test/java/util/ServiceLoader/modules/ServicesTest.java ! test/java/util/TimeZone/HongKong.java ! test/java/util/logging/modules/GetResourceBundleTest.java Changeset: 0d5787987564 Author: darcy Date: 2016-09-08 14:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d5787987564 8039854: Broken link in java.lang.RuntimePermission Reviewed-by: lancea ! src/java.base/share/classes/java/lang/RuntimePermission.java Changeset: caf0b176cf70 Author: lana Date: 2016-09-08 22:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/caf0b176cf70 Merge Changeset: 08bbb5882450 Author: martin Date: 2016-09-07 14:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/08bbb5882450 8165643: SecureDirectoryStream doesn't work on linux non-x86 Reviewed-by: alanb ! src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c ! test/java/nio/file/DirectoryStream/SecureDS.java Changeset: 5cfe381e52f2 Author: skovalev Date: 2016-09-09 10:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5cfe381e52f2 8165592: Fix module dependencies for sun/text/* tests Reviewed-by: naoto ! test/sun/text/resources/Collator/Bug4248694.java ! test/sun/text/resources/Collator/Bug4804273.java ! test/sun/text/resources/Collator/Bug6755060.java ! test/sun/text/resources/Format/Bug4395196.java ! test/sun/text/resources/Format/Bug4442855.java ! test/sun/text/resources/Format/Bug4621320.java ! test/sun/text/resources/Format/Bug4651568.java ! test/sun/text/resources/Format/Bug4762201.java ! test/sun/text/resources/Format/Bug4807540.java ! test/sun/text/resources/Format/Bug4810032.java ! test/sun/text/resources/Format/Bug4994312.java ! test/sun/text/resources/Format/Bug5096553.java ! test/sun/text/resources/Format/Bug8037343.java ! test/sun/text/resources/Format/Bug8074791.java ! test/sun/text/resources/LocaleDataTest.java Changeset: b48fd6299b71 Author: smarks Date: 2016-09-09 12:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b48fd6299b71 4285505: deprecate java.lang.Compiler Reviewed-by: shade, forax, kmo, tellison, mchung, alanb, rriggs ! src/java.base/share/classes/java/lang/Compiler.java Changeset: b2af67961b70 Author: kbarrett Date: 2016-09-09 16:24 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2af67961b70 8165393: bad merge in java/lang/ref/package-info.java Summary: Added the missing change. Reviewed-by: rriggs ! src/java.base/share/classes/java/lang/ref/package-info.java Changeset: 33f7b960dab0 Author: mchung Date: 2016-09-09 13:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33f7b960dab0 8165346: j.l.ClassLoader.getDefinedPackage(String) throws NPE Reviewed-by: alanb, lancea, shade ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Package.java + test/java/lang/ClassLoader/GetDefinedPackage.java Changeset: 04fab572c203 Author: psandoz Date: 2016-09-09 14:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/04fab572c203 8165731: Reference to removed method in VarHandle JavaDoc Reviewed-by: shade, bpb ! src/java.base/share/classes/java/lang/invoke/VarHandle.java Changeset: d4fe8a79e382 Author: psandoz Date: 2016-09-09 14:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d4fe8a79e382 8164691: Stream specification clarifications for iterate and collect Reviewed-by: briangoetz, smarks, tvaleev ! src/java.base/share/classes/java/util/stream/DoubleStream.java ! src/java.base/share/classes/java/util/stream/IntStream.java ! src/java.base/share/classes/java/util/stream/LongStream.java ! src/java.base/share/classes/java/util/stream/Stream.java Changeset: ba6f73d87fae Author: psandoz Date: 2016-09-09 14:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba6f73d87fae 8161230: ClassLoader: add resource methods returning java.util.stream.Stream Reviewed-by: psandoz, alanb, mchung, tvaleev Contributed-by: Patrick Reinhart ! src/java.base/share/classes/java/lang/ClassLoader.java + test/java/lang/ClassLoader/ResourcesStreamTest.java Changeset: f2e94fd11c41 Author: sundar Date: 2016-09-10 06:46 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f2e94fd11c41 8165726: fix for 8165595 revealed a bug in pack200 tool's handling of main class attribute of module-info classes Reviewed-by: ksrini ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties Changeset: 353638476788 Author: darcy Date: 2016-09-11 13:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/353638476788 8165810: Problem list VersionCheck.java until JDK-8165772 is fixed Reviewed-by: lancea, redestad ! test/ProblemList.txt Changeset: 149261d5ece8 Author: redestad Date: 2016-09-12 13:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/149261d5ece8 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy Reviewed-by: mhaupt, vlivanov, psandoz, shade ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 3c22a1f8176c Author: sundar Date: 2016-09-12 18:27 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3c22a1f8176c 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java Reviewed-by: alanb, jlaskey ! test/ProblemList.txt Changeset: ed1e774e93cf Author: redestad Date: 2016-09-12 17:45 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ed1e774e93cf 8165723: JarFile::isMultiRelease() method returns false when it should return true Reviewed-by: alanb ! src/java.base/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java ! test/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java Changeset: bcc0dd4d9fe9 Author: naoto Date: 2016-09-12 09:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bcc0dd4d9fe9 8165605: Thai resources in jdk.localedata cause split package issue with java.base Reviewed-by: mchung, erikj ! make/gendata/GendataBreakIterator.gmk - src/java.base/share/classes/sun/text/resources/BreakIteratorRulesProvider.java ! src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java ! src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java + src/jdk.localedata/share/classes/sun/text/resources/ext/thai_dict - src/jdk.localedata/share/classes/sun/text/resources/thai_dict ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: c82edcbf45ce Author: redestad Date: 2016-09-12 20:12 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c82edcbf45ce 8165890: [TESTBUG] Compilation issue in MultiReleaseJarTest after 8165723 Reviewed-by: darcy ! test/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java Changeset: 9babcc5b3e2d Author: dl Date: 2016-09-12 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9babcc5b3e2d 8164983: Improve CountedCompleter code samples; add corresponding tests Reviewed-by: martin, psandoz, shade ! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java ! test/java/util/concurrent/tck/CountedCompleterTest.java Changeset: d6ccab83a5f8 Author: dl Date: 2016-09-12 13:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6ccab83a5f8 8139237: java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java fails intermittently Reviewed-by: martin, psandoz, shade ! test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Changeset: 708383deec79 Author: dl Date: 2016-09-12 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/708383deec79 8164169: Miscellaneous changes imported from jsr166 CVS 2016-09 Reviewed-by: martin, psandoz, shade ! src/java.base/share/classes/java/util/ArrayDeque.java ! src/java.base/share/classes/java/util/PriorityQueue.java ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CyclicBarrier.java ! src/java.base/share/classes/java/util/concurrent/Flow.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/Semaphore.java ! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java ! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java ! test/java/util/PriorityQueue/NoNulls.java ! test/java/util/concurrent/BlockingQueue/LoopHelpers.java ! test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java ! test/java/util/concurrent/ConcurrentHashMap/LoopHelpers.java ! test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java ! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/DelayQueue/Stress.java ! test/java/util/concurrent/Exchanger/LoopHelpers.java ! test/java/util/concurrent/ExecutorCompletionService/LoopHelpers.java ! test/java/util/concurrent/FutureTask/LoopHelpers.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCorePoolSize.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCoreThreads.java ! test/java/util/concurrent/ThreadPoolExecutor/ThreadRestarts.java ! test/java/util/concurrent/ThreadPoolExecutor/TimeOutShrink.java ! test/java/util/concurrent/atomic/AtomicReferenceTest.java ! test/java/util/concurrent/forkjoin/SubmissionTest.java ! test/java/util/concurrent/locks/Lock/LoopHelpers.java ! test/java/util/concurrent/locks/Lock/Mutex.java ! test/java/util/concurrent/locks/LockSupport/ParkLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LoopHelpers.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/LoopHelpers.java ! test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java ! test/java/util/concurrent/tck/AtomicIntegerArray9Test.java ! test/java/util/concurrent/tck/AtomicLongArray9Test.java ! test/java/util/concurrent/tck/AtomicReferenceArray9Test.java ! test/java/util/concurrent/tck/CompletableFutureTest.java ! test/java/util/concurrent/tck/ConcurrentHashMap8Test.java ! test/java/util/concurrent/tck/CopyOnWriteArrayListTest.java ! test/java/util/concurrent/tck/CopyOnWriteArraySetTest.java ! test/java/util/concurrent/tck/ExecutorCompletionService9Test.java ! test/java/util/concurrent/tck/ExecutorCompletionServiceTest.java ! test/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/java/util/concurrent/tck/ForkJoinTask8Test.java ! test/java/util/concurrent/tck/ForkJoinTaskTest.java ! test/java/util/concurrent/tck/JSR166TestCase.java ! test/java/util/concurrent/tck/RecursiveActionTest.java ! test/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java ! test/java/util/concurrent/tck/ScheduledExecutorTest.java ! test/java/util/concurrent/tck/StampedLockTest.java ! test/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java ! test/java/util/concurrent/tck/ThreadPoolExecutorTest.java Changeset: 08d703b88378 Author: sspitsyn Date: 2016-09-12 15:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/08d703b88378 8160950: Agent JAR added to app class loader rather than system class loader when running with -Djava.system.class.loader Summary: Add agent JAR to the custom system class loader Reviewed-by: alanb, mchung, dholmes ! src/java.instrument/share/classes/java/lang/instrument/package.html ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.h + test/java/lang/instrument/CustomSystemLoader/Agent.java + test/java/lang/instrument/CustomSystemLoader/App.java + test/java/lang/instrument/CustomSystemLoader/CustomLoader.java Changeset: 54c5931849a3 Author: sspitsyn Date: 2016-09-12 22:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/54c5931849a3 Merge - src/java.base/share/classes/sun/text/resources/BreakIteratorRulesProvider.java - src/jdk.localedata/share/classes/sun/text/resources/thai_dict Changeset: b2361ae612b9 Author: mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2361ae612b9 Merge ! make/gendata/GendataBreakIterator.gmk ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java - src/java.base/share/classes/java/lang/module/Dependence.java - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java ! src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java ! src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/java.instrument/share/classes/java/lang/instrument/package.html ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java ! test/ProblemList.txt - test/java/lang/Class/getResource/src/m3/module-info.java - test/java/lang/Class/getResource/src/m3/p3/Main.java - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java - test/java/lang/reflect/Module/access/src/target/p/Exported.java - test/java/lang/reflect/Module/access/src/target/p/Helper.java - test/java/lang/reflect/Module/access/src/target/q/Internal.java ! test/java/time/TEST.properties ! test/java/util/Collection/MOAT.java - test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/MyResources_ja_JP.properties ! test/java/util/ResourceBundle/modules/security/TestPermission.java - test/java/util/ServiceLoader/modules/MiscTests.java - test/java/util/ServiceLoader/modules/ServicesTest.java - test/java/util/ServiceLoader/modules/src/bananascript/module-info.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/src/test/module-info.java - test/java/util/ServiceLoader/modules/src/test/test/Main.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCoreThreads.java ! test/java/util/concurrent/tck/JSR166TestCase.java ! test/java/util/logging/modules/GetResourceBundleTest.java ! test/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java ! test/sun/text/resources/LocaleDataTest.java ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: 680a8e8684b0 Author: mchung Date: 2016-09-15 13:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/680a8e8684b0 Merge Changeset: 32d957185656 Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32d957185656 Added tag jdk-9+136 for changeset 54c5931849a3 ! .hgtags Changeset: 7285b429a33a Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7285b429a33a Merge ! .hgtags - src/java.base/share/classes/java/lang/module/Dependence.java - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java - test/java/lang/Class/getResource/src/m3/module-info.java - test/java/lang/Class/getResource/src/m3/p3/Main.java - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java - test/java/lang/reflect/Module/access/src/target/p/Exported.java - test/java/lang/reflect/Module/access/src/target/p/Helper.java - test/java/lang/reflect/Module/access/src/target/q/Internal.java - test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/MyResources_ja_JP.properties - test/java/util/ServiceLoader/modules/MiscTests.java - test/java/util/ServiceLoader/modules/ServicesTest.java - test/java/util/ServiceLoader/modules/src/bananascript/module-info.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/src/test/module-info.java - test/java/util/ServiceLoader/modules/src/test/test/Main.java From mandy.chung at oracle.com Thu Sep 15 21:17:28 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:17:28 +0000 Subject: hg: jigsaw/jake/langtools: 7 new changesets Message-ID: <201609152117.u8FLHSe5004014@aojmv0008.oracle.com> Changeset: 589ff4d43428 Author: vromero Date: 2016-09-06 17:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/589ff4d43428 8162546: change hidden options -Xdebug to --debug, -XshouldStop to --should-stop, and -diags to --diags Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Options.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/Diagnostics/6722234/T6722234a.java ! test/tools/javac/Diagnostics/6722234/T6722234b.java ! test/tools/javac/Diagnostics/6722234/T6722234c.java ! test/tools/javac/Diagnostics/6722234/T6722234d.java ! test/tools/javac/Diagnostics/6862608/T6862608a.java ! test/tools/javac/Diagnostics/6862608/T6862608b.java ! test/tools/javac/Diagnostics/7010608/Test.java ! test/tools/javac/Diagnostics/8010387/T8010387.java ! test/tools/javac/InterfaceMemberClassModifiers.java ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T6214885.java ! test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.java ! test/tools/javac/annotations/neg/8022765/VerifyErroneousAnnotationsAttributed.java ! test/tools/javac/annotations/typeAnnotations/newlocations/AfterMethodTypeParams.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/taskListeners/EventsBalancedTest.java ! test/tools/javac/completionDeps/DepsAndAnno.java ! test/tools/javac/completionDeps/DepsAndDocLint.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples/ApplicableMethodFound.java ! test/tools/javac/diags/examples/ApplicableMethodFound1.java ! test/tools/javac/diags/examples/DeferredMethodInst.java ! test/tools/javac/diags/examples/LambdaStat.java ! test/tools/javac/diags/examples/MrefStat.java ! test/tools/javac/diags/examples/MrefStat1.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PartialInstSig.java ! test/tools/javac/diags/examples/VerboseResolveMulti.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereIntersection2.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/diags/examples/WhereTypeVar2.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/failover/FailOver01.java ! test/tools/javac/failover/FailOver02.java ! test/tools/javac/failover/FailOver03.java ! test/tools/javac/failover/FailOver04.java ! test/tools/javac/failover/FailOver05.java ! test/tools/javac/failover/FailOver06.java ! test/tools/javac/failover/FailOver07.java ! test/tools/javac/failover/FailOver08.java ! test/tools/javac/failover/FailOver09.java ! test/tools/javac/failover/FailOver10.java ! test/tools/javac/failover/FailOver11.java ! test/tools/javac/failover/FailOver12.java ! test/tools/javac/failover/FailOver13.java ! test/tools/javac/failover/FailOver14.java ! test/tools/javac/failover/FailOver15.java ! test/tools/javac/generics/inference/8158355/T8158355.java ! test/tools/javac/lambda/MostSpecific09.java ! test/tools/javac/lambda/MostSpecific09.out ! test/tools/javac/lambda/TestLambdaToMethodStats.java ! test/tools/javac/lambda/XDdumpLambdaToMethodStats.java ! test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/policy/test3/Test.java ! test/tools/javac/positions/TreeEndPosTest.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/unicode/UnicodeNewline.java ! test/tools/sjavac/JavacOptionPrep.java Changeset: e07ed6317649 Author: rfield Date: 2016-09-07 12:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e07ed6317649 8080352: jshell tool: Error message for using "package" should be more descriptive than "Failed" Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java ! test/jdk/jshell/RejectedFailedTest.java Changeset: 560204c4944f Author: jlahoda Date: 2016-09-08 15:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/560204c4944f 8131025: JShell: crash on tab-complete reference to bad class file Summary: Catching CompletionFailure when iterating through Scope. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/jdk/jshell/CompletionSuggestionTest.java Changeset: c8f02f0ecbd7 Author: lana Date: 2016-09-08 22:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c8f02f0ecbd7 Merge Changeset: 4ad21ff4219c Author: mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4ad21ff4219c Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Options.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/JDIListeningExecutionControlTest.java ! test/tools/javac/diags/CheckResourceKeys.java - test/tools/javac/diags/examples/DuplicateExports/exported/Class.java - test/tools/javac/diags/examples/DuplicateExports/module-info.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/modules/AddLimitMods.java - test/tools/javac/modules/RequiresPublicTest.java - test/tools/jdeps/modules/src/m1/module-info.java - test/tools/jdeps/modules/src/m1/p1/Goo.java - test/tools/jdeps/modules/src/m1/p1/Lib.java - test/tools/jdeps/modules/src/m1/p1/S.java - test/tools/jdeps/modules/src/m1/p1/internal/Impl.java - test/tools/jdeps/modules/src/m2/module-info.java - test/tools/jdeps/modules/src/m2/p2/Bar.java - test/tools/jdeps/modules/src/m2/p2/internal/T2.java - test/tools/jdeps/modules/src/m3/module-info.java - test/tools/jdeps/modules/src/m3/p3/Foo.java - test/tools/jdeps/modules/src/m3/p3/Main.java - test/tools/jdeps/modules/src/m6/module-info.java - test/tools/jdeps/modules/src/m6/p6/indirect/UnsafeRef.java - test/tools/jdeps/modules/src/m6/p6/safe/Lib.java - test/tools/jdeps/modules/src/m7/module-info.java - test/tools/jdeps/modules/src/m7/p7/Main.java Changeset: ab580b8d745d Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ab580b8d745d Added tag jdk-9+136 for changeset c8f02f0ecbd7 ! .hgtags Changeset: ee601290a7d5 Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ee601290a7d5 Merge ! .hgtags - src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java - test/tools/javac/diags/examples/DuplicateExports/exported/Class.java - test/tools/javac/diags/examples/DuplicateExports/module-info.java - test/tools/javac/modules/RequiresPublicTest.java - test/tools/jdeps/modules/src/m1/module-info.java - test/tools/jdeps/modules/src/m1/p1/Goo.java - test/tools/jdeps/modules/src/m1/p1/Lib.java - test/tools/jdeps/modules/src/m1/p1/S.java - test/tools/jdeps/modules/src/m1/p1/internal/Impl.java - test/tools/jdeps/modules/src/m2/module-info.java - test/tools/jdeps/modules/src/m2/p2/Bar.java - test/tools/jdeps/modules/src/m2/p2/internal/T2.java - test/tools/jdeps/modules/src/m3/module-info.java - test/tools/jdeps/modules/src/m3/p3/Foo.java - test/tools/jdeps/modules/src/m3/p3/Main.java - test/tools/jdeps/modules/src/m6/module-info.java - test/tools/jdeps/modules/src/m6/p6/indirect/UnsafeRef.java - test/tools/jdeps/modules/src/m6/p6/safe/Lib.java - test/tools/jdeps/modules/src/m7/module-info.java - test/tools/jdeps/modules/src/m7/p7/Main.java From mandy.chung at oracle.com Thu Sep 15 21:17:32 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 21:17:32 +0000 Subject: hg: jigsaw/jake/nashorn: 5 new changesets Message-ID: <201609152117.u8FLHWWW004078@aojmv0008.oracle.com> Changeset: 925e7b26b363 Author: hannesw Date: 2016-09-07 22:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/925e7b26b363 8077149: __noSuchProperty__ and __noSuchMethod__ invocations are not properly guarded Reviewed-by: jlaskey, mhaupt ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SharedPropertyMap.java + test/script/basic/JDK-8077149.js Changeset: f11b8f5c4ccb Author: lana Date: 2016-09-08 22:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f11b8f5c4ccb Merge Changeset: ea1e3e3e6d92 Author: mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ea1e3e3e6d92 Merge Changeset: 17ed43add2f9 Author: lana Date: 2016-09-15 17:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/17ed43add2f9 Added tag jdk-9+136 for changeset f11b8f5c4ccb ! .hgtags Changeset: 0f5a26cc67b0 Author: mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0f5a26cc67b0 Merge ! .hgtags From mandy.chung at oracle.com Thu Sep 15 22:17:53 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 15 Sep 2016 22:17:53 +0000 Subject: hg: jigsaw/jake/jdk: Add test for checking StackTraceElement format Message-ID: <201609152217.u8FMHsNf020270@aojmv0008.oracle.com> Changeset: e0864f0eb268 Author: mchung Date: 2016-09-15 15:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e0864f0eb268 Add test for checking StackTraceElement format + test/java/lang/StackTraceElement/SerialTest.java From david.lloyd at redhat.com Fri Sep 16 14:21:06 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 16 Sep 2016 09:21:06 -0500 Subject: Revisiting JDK-8161269 Message-ID: Hi Alan, In JDK-8161269 you said [1] that the "null" class loader has never been specified to contain all Java SE types, using this as a justification to reject this issue as "Not an Issue", regardless of the compatibility impact (particularly the common case of a class loader with a null parent). However in a recent email [2] on the topic of letting module path modules each reside in a separate class loader so as to allow for duplicate non-exported packages, you seem to imply that the impact of changing the class loader of a library, even one on the module path, is a compatibility risk though there were no concrete details given. What is the standard for compatibility? I contend that there are real frameworks today that are in wide usage that have assumed that a null class loader contains all platform classes; however, I have yet to run across any framework that worked under a class path (i.e. application class loader) but failed as soon as it was loaded under its own isolated class loader (in our case, as a module under JBoss Modules). By my empirical experience, the former is a significant compatibility risk, while the latter is not; by the standard you have set in these two places, it appears that the former is not a risk (or not enough of one to warrant action) but the latter would be, so I was hoping you'd expand a bit so I can get a better understanding of where you're coming from. Thanks! [1] https://bugs.openjdk.java.net/browse/JDK-8161269?focusedCommentId=13973088#comment-13973088 [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009255.html -- - DML From Alan.Bateman at oracle.com Fri Sep 16 15:30:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Sep 2016 08:30:35 -0700 Subject: Revisiting JDK-8161269 In-Reply-To: References: Message-ID: On 16/09/2016 07:21, David M. Lloyd wrote: > Hi Alan, > > In JDK-8161269 you said [1] that the "null" class loader has never > been specified to contain all Java SE types, using this as a > justification to reject this issue as "Not an Issue", regardless of > the compatibility impact (particularly the common case of a class > loader with a null parent). The context here is de-privileging non-core components so that they are no longer defined to the boot loader with all permissions. Modules such as java.corba, java.xml.ws, java.sql and many more have no business or need to be defined to the boot loader. It would be nice, if over the very long term, that we could get to the point where the only module defined to the boot loader is java.base. I don't know if we will ever get there. We of course acknowledge that there is potential compatibility impact with this change and this is why it is called out in the Risks and Assumption section of JEP 261 [1] as "Some Java SE types have been de-privileged and are now loaded by the platform class loader rather than the bootstrap class loader, as noted above. Existing custom class loaders that delegate directly to the bootstrap class loader might not work correctly; they should be updated to delegate to the platform class loader, which is easily available via the new ClassLoader::getPlatformClassLoader method." So far then there hasn't been a lot of feedback on this. The default loader for delegation is the system class loader so someone creating a class loader that delegates to the boot loader is probably an advanced case. As noted in the bug report, the ClassLoader javadoc has been updated for Java SE 9 to define the built-in class loaders. The most important part of this is specifying that all platform classes are visible via the platform class loader. That works for Java SE 8 and older if you replace "platform" with "extension". I mention this in case there is concerns about using a new API in code that needs to be compiled for JDK 8 and run on 8 or 9. I don't have cycles just now to get into the topic of radically changing the class loader hierarchy or how modules on the module path are mapped to loaders - that topic is an order of magnitude larger than the above, esp. once you get into all the scenarios around migration. -Alan [1] http://openjdk.java.net/jeps/261 From david.lloyd at redhat.com Fri Sep 16 15:36:23 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 16 Sep 2016 10:36:23 -0500 Subject: Revisiting JDK-8161269 In-Reply-To: References: Message-ID: <1742ccd4-c8e4-f6e9-0096-c01da4c440a3@redhat.com> On 09/16/2016 10:30 AM, Alan Bateman wrote: > On 16/09/2016 07:21, David M. Lloyd wrote: > >> Hi Alan, >> >> In JDK-8161269 you said [1] that the "null" class loader has never >> been specified to contain all Java SE types, using this as a >> justification to reject this issue as "Not an Issue", regardless of >> the compatibility impact (particularly the common case of a class >> loader with a null parent). > The context here is de-privileging non-core components so that they are > no longer defined to the boot loader with all permissions. Modules such > as java.corba, java.xml.ws, java.sql and many more have no business or > need to be defined to the boot loader. It would be nice, if over the > very long term, that we could get to the point where the only module > defined to the boot loader is java.base. I don't know if we will ever > get there. > > We of course acknowledge that there is potential compatibility impact > with this change and this is why it is called out in the Risks and > Assumption section of JEP 261 [1] as > > "Some Java SE types have been de-privileged and are now loaded by the > platform class loader rather than the bootstrap class loader, as noted > above. Existing custom class loaders that delegate directly to the > bootstrap class loader might not work correctly; they should be updated > to delegate to the platform class loader, which is easily available via > the new ClassLoader::getPlatformClassLoader method." > > So far then there hasn't been a lot of feedback on this. The default > loader for delegation is the system class loader so someone creating a > class loader that delegates to the boot loader is probably an advanced > case. > > As noted in the bug report, the ClassLoader javadoc has been updated for > Java SE 9 to define the built-in class loaders. The most important part > of this is specifying that all platform classes are visible via the > platform class loader. That works for Java SE 8 and older if you replace > "platform" with "extension". I mention this in case there is concerns > about using a new API in code that needs to be compiled for JDK 8 and > run on 8 or 9. > > I don't have cycles just now to get into the topic of radically changing > the class loader hierarchy or how modules on the module path are mapped > to loaders - that topic is an order of magnitude larger than the above, > esp. once you get into all the scenarios around migration. OK. For this issue though, would it not make sense to look at the null parent class loader case in a specific and separate way: in the past, such class loaders had access to all platform classes, so as a compatibility factor it would not be unreasonable to take "null" in this *specific* context to mean "platform class loader" and do this translation inside the constructor? Since the change that is really occurring (in any real, observable sense) is that the "null" parent is suddenly shrinking with respect to what it was going back far into history, then the _compatible_ change would appear to be to provide a new ClassLoader value that indicates "java.base (and optionally a few more modules that can decrease over time)", which in reality maps to the bootstrap class loader. This way compatibility is maintained, and the new (in the observable sense) functionality of having a more limited parent CL is still available. WDYT? -- - DML From Alan.Bateman at oracle.com Fri Sep 16 15:52:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Sep 2016 08:52:12 -0700 Subject: Revisiting JDK-8161269 In-Reply-To: <1742ccd4-c8e4-f6e9-0096-c01da4c440a3@redhat.com> References: <1742ccd4-c8e4-f6e9-0096-c01da4c440a3@redhat.com> Message-ID: On 16/09/2016 08:36, David M. Lloyd wrote: > > OK. For this issue though, would it not make sense to look at the > null parent class loader case in a specific and separate way: in the > past, such class loaders had access to all platform classes, so as a > compatibility factor it would not be unreasonable to take "null" in > this *specific* context to mean "platform class loader" and do this > translation inside the constructor? Since the change that is really > occurring (in any real, observable sense) is that the "null" parent is > suddenly shrinking with respect to what it was going back far into > history, then the _compatible_ change would appear to be to provide a > new ClassLoader value that indicates "java.base (and optionally a few > more modules that can decrease over time)", which in reality maps to > the bootstrap class loader. This way compatibility is maintained, and > the new (in the observable sense) functionality of having a more > limited parent CL is still available. Fair point, these constructors could be changed to translate null to the platform class loader. That would need examination from a compatibility point of view too (esp. getParent). It would also create anomalies with other APIs where null is translated to the system class loader. However, I agree it's wroth exploring. -Alan From mandy.chung at oracle.com Fri Sep 16 17:57:43 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 16 Sep 2016 17:57:43 +0000 Subject: hg: jigsaw/jake/jdk: Replace use of Collections/HashSet with Set.of in SystemModuleDescriptionPlugin Message-ID: <201609161757.u8GHvh5A027425@aojmv0008.oracle.com> Changeset: c743bdb70352 Author: redestad Date: 2016-09-16 10:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c743bdb70352 Replace use of Collections/HashSet with Set.of in SystemModuleDescriptionPlugin Reviewed-by: alanb, mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java From david.lloyd at redhat.com Fri Sep 16 18:44:22 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 16 Sep 2016 13:44:22 -0500 Subject: Alternatives and fixes to #ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation proposals In-Reply-To: <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> Message-ID: I've recently sent the below message to the jpms-spec-experts list. For the reasons listed below, we find the current proposals unworkable, and would like to propose some refinements and/or alternatives. I'll follow up soon with separate emails to discuss specific alternatives and fixes in various areas, and to cover what our minimum requirements are in each area. On 09/16/2016 10:30 AM, David M. Lloyd wrote: > After a fairly detailed review of this proposal, we have determined that > it is not acceptable to Red Hat in its present form. I will list the > primary problems here, and then I'll start up discussion on jigsaw-dev > of several possible solutions that could work for us. I'll number these > in case anyone wants to respond piece-wise. > > #1) The "weak" designation appears to be pejorative > > Under this solution, many existing frameworks and/or the modules which > consume them must be marked "weak" in order to work correctly, or else a > much more complex module descriptor must be used. While this seems to > be a stepping stone for migration, we find that it rather makes > middleware appear as a second-class citizen. > > #2) Weak modules are, in fact, weak > > The idea of retaining the Java 8 rules for transition modules appears > good on the surface, however the problem is that users may be forced to > use weak modules indefinitely in order to interoperate with certain > existing middleware and libraries, or else be faced with a potentially > complex migration. If the security benefits of "strong" modules are > real, then users will be rightly inclined to move from weak modules to > strong modules. This can be severely problematic if existing > middleware, libraries, and large applications cannot easily operate as > or with "strong" modules or cannot do so in an "easy to learn"/"easy to > use" fashion. This also means that "weak" modules exist only for the > purposes of maintaining a transition period - at some point they will > inevitably transition from "convenience" to "attractive nuisance". We > believe that it is feasible to solve compatibility to a satisfactory > degree without relegating users of existing software to a lower tier of > security or functionality. > > #3) Controlling reflection access is always bound up with controlling > exports > > The proposed exports system is simplistic but not exactly simple, yet > several useful modes remain left unaccounted-for. Internally we > examined the usefulness of controlling access to public and so-called > "deep" reflection in combination with whether or not a member was > exported, and we came up with this logical table: > > +------------------+---------------------------+ > | | Module is... | > | Reflection is... +------------+--------------+ > | | Exported | Not Exported | > +----------------------------------------------+ > | Forbidden | Not Useful | Useful | > +----------------------------------------------+ > | Public Only | Useful | Useful | > +----------------------------------------------+ > | Public & Private | Useful | Useful | > +------------------+------------+--------------+ > > Some of these useful modes seem not to be available, or are not usable > in an obvious or simple manner. These modes are useful, possibly even > necessary, to introduce in Java 9 in order to provide a good > compatibility story with the many existing frameworks in the wild, in > the absence of weak modules. > > It has been observed that in some cases, the necessity of granting > public or private reflective access to a module is actually bound not > with what that module exports, but rather with what it requires or uses, > which might be useful in consideration of a solution; for example, > "using" a persistence framework which operates only on public types > would imply that the module would grant back public-only reflective > access to the framework which provides the service. > > #4) There isn't always a container > > The justification for not providing an easy mechanism to restrict > private reflective access to a trusted framework is that a container can > always rewrite a module or inject classes. However there isn't always a > container present - something which the existence of weak modules > acknowledges. Some frameworks and middleware are meant to be usable > with or without a container, and it is undesirable to force these use > cases into a weak module situation or to require a strong coupling in > the module descriptor in this case. Some other solution should be found > that works both for containers and "regular" applications. > > Broadly speaking, a container would be able to do additional things that > are useful do to specifically in a container. But a container should > not be _necessary_ in order to do things that are generally useful, at > least to the greatest extent possible. > > #6) Not all reflection is 100% "friendly", and that's OK > > Serialization frameworks generally need private reflective access to the > module which contains the classes being serialized. For some > frameworks, this access will already be adequate. Some existing > frameworks utilize Unsafe to create uninitialized instances. However > other frameworks, including frameworks that seek to comply with the > Serialization Specification [1], use ReflectionFactory, as that class > provides (exclusively, as far as I know) the ability to acquire a > constructor that produces a _partially_-initialized class where only the > constructors of superclasses to a certain depth are called. It is our > view that it would be a regression to force such frameworks to use > --add-exports or JVMTI, and using Unsafe for this purpose, or continuing > to use it, (as I understand it) puts at risk the ability to perform > optimizations which depend on entry point control, which I am given to > understand are a strong motivator for many of the design constraints > that exist on the Jigsaw implementation. It should be possible for > these frameworks to continue to use ReflectionFactory (unsupported > though it may be) if suitably privileged (in the security manager > sense), as long as all of the module(s) upon which the framework > reflects have granted private reflective access to it (in the module > declaration sense). This may be imperfect in the event that class > hierarchies are spread across several modules, but that is something > that can be hashed out in detail on jigsaw-dev. > > A better alternative to ReflectionFactory itself could be sought in > future releases, if necessary, though one hopes that traditional > serialization will die out in favor of more modern approaches, rendering > the issue less relevant over time. Admittedly, maybe a very long period > of time. > > #7) More loose coupling seems necessary and useful > > In order for typical applications to function with modern middleware as > modules, without compromising security, it may be necessary to enhance > the loose coupling mechanism (uses/provides), or to provide an > additional, similar mechanism, which allows a symbolic coupling which > would allow modules to declare (in an abstract manner) modules which > need to have reflective access to it in a "friendly" manner. > Implementation ideas are forthcoming on jigsaw-dev. > > Providing a way within the system to grant public and/or private > reflection access in a specific manner, and doing so in a manner which > is easy to use and not prejudicial against existing or future middleware > and small or large applications which consume such middleware in the > Java SE or EE space, is our most basic requirement for satisfactory > resolution of this issue. I will follow up on jigsaw-dev with some > implementation thoughts and more specific requirements. > > This list may not be exhaustive but it should be, at the least, a very > good starting point for discussion, hopefully with a short path to > implementation. > > On 09/12/2016 10:08 AM, Mark Reinhold wrote: >> Issue summary >> ------------- >> >> #ReflectiveAccessToNonExportedTypes --- Some kinds of framework >> libraries require reflective access to members of the non-exported >> types of other modules; examples include dependency injection (Guice), >> persistence (JPA), debugging tools, code-automation tools, and >> serialization (XStream). In some cases the particular library to be >> used is not known until run time (e.g., Hibernate and EclipseLink both >> implement JPA). This capability is also sometimes used to work around >> bugs in unchangeable code. Access to non-exported packages can, at >> present, only be done via command-line flags, which is extremely >> awkward. Provide an easier way for reflective code to access such >> non-exported types. [1] >> >> #AwkwardStrongEncapsulation --- A non-public element of an exported >> package can still be accessed via the `AccessibleObject::setAccessible` >> method of the core reflection API. The only way to strongly >> encapsulate such an element is to move it to a non-exported package. >> This makes it awkward, at best, to encapsulate the internals of a >> package that defines a public API. [2] >> >> Proposal >> -------- >> >> (Warning: This is somewhat long, and in the end it affects both `exports` >> and `requires` directives.) >> >> Extend the language of module declarations with the concept of _weak >> modules_. Weak modules make it easy to modularize components whose >> internals will be accessed by reflection-based frameworks. Every >> package in a weak module has the following properties: >> >> (A) It is exported at both compile time and run time, as if by an >> `exports` directive, and >> >> (B) Its non-public elements are available for _deep_ reflection, i.e., >> at run time they can be made accessible to code outside the module >> via the `AccessibleObject::setAccessible` method of the core >> reflection API. >> >> In other words, every type defined in a weak module, whether public or >> not, is subject to exactly the same access checks as in Java SE 8 and >> earlier releases. >> >> A weak module is declared by placing the modifier `weak` before the >> `module` keyword. The declaration of a weak module cannot contain any >> explicit `exports` directives. If the `weak` modifier does not appear >> before the `module` keyword then the declared module is _strong_, and >> it can contain explicit `exports` directives. >> >> Suppose we have a module `foo.bar` which has an internal package >> `com.foo.bar.model` that contains entity classes to be manipulated by >> Hibernate, via core reflection. Then the module declaration >> >> weak module foo.bar { >> // No exports >> requires hibernate.core; >> requires hibernate.entitymanager; >> } >> >> exports the public types in `com.foo.bar.model`, and those of any other >> packages, in all phases. It additionally makes all non-public elements >> of all packages available for deep reflection, enabling Hibernate to >> access such elements in the `com.foo.bar.model` package via the >> `setAccessible` method. >> >> Weak modules simplify the process of migrating to modules. The steps >> to convert an existing component into a module were, previously: >> >> (1) Make any changes necessary to get it working as an automatic >> module (e.g., eliminate duplicate packages), and then >> >> (2) Write an explicit module declaration, which entails identifying >> both the component's dependences (`requires`) and the packages >> whose public types are to be made available to other modules >> (`exports`). >> >> With weak modules we can now divide the second step into two steps: >> >> (2a) Write an explicit module declaration for a weak module, which >> entails identifying just the component's dependences (`requires`). >> >> (2b) Convert the weak module into a strong module, which entails >> identifying the packages of the component whose public types >> are to be made available to other modules (`exports`). >> >> In other words, weak modules make it possible to focus first upon the >> reliable configuration of a module (`requires`), and then later think >> about its strong encapsulation (`exports`). >> >> Weak modules are "weak" in what they export, but they remain subject >> to all of the constraints required to achieve reliable configuration. >> They do not read the unnamed module (i.e., the class path), they do not >> allow cycles in the module graph, and they do not allow split packages. >> Weak modules read named modules only as indicated by their `requires` >> directives, and they consume and provide services only as indicated by >> their `uses` and `provides` directives. >> >> * * * >> >> In a strong module, an ordinary `exports` directive exports a package at >> both compile time and run time (property (A) above) but does not make its >> non-public types available for deep reflection (B). In order to enable a >> package in a strong module to be exported in the same way as in a weak >> module we introduce the per-export modifier `private` to denote this >> second property. >> >> If the above weak `foo.bar` module, e.g., contains some other packages >> besides `com.foo.bar.model`, and we wish to encapsulate those packages, >> we can convert it into a strong module with the declaration >> >> module foo.bar { >> exports private com.foo.bar.model; >> requires hibernate.core; >> requires hibernate.entitymanager; >> } >> >> Now Hibernate can still access any public or non-public entity classes in >> the `com.foo.bar.model` package, but all the other packages are strongly >> encapsulated. >> >> The `private` modifier should generally not be used to export a package >> containing an API, since normally an API's internal implementation >> details should be strongly encapsulated. It may, however, be useful for >> legacy APIs whose internals are known to be accessed by existing code. >> >> Every package in a weak module, an automatic module, or an unnamed module >> is exported as if by an `exports private` directive. >> >> To ensure the integrity of the platform we expect few, if any, packages >> in the JDK itself to be exported with the `private` modifier. >> >> * * * >> >> The new `private` modifier can also be used with qualified exports, >> though they interact with unqualified exports in a non-obvious way. >> >> - If you write `exports p` then you can also write `exports private >> p to m`, so that code in module `m` can access the non-public types >> of `p` via deep reflection but code outside of `m` can only access >> the public types of `p`. >> >> - If you write `exports p to m1` then you can also write `exports >> private p to m2`, so that code in `m2` can access the non-public >> types of `p` via deep reflection, code in `m1` can access the >> public types of `p`, but no code in any other module can access >> any of the types of `p`. >> >> - If you write `exports private p` then you cannot also have a >> qualified export of `p`, since code in all other modules already >> has access to the non-public types of `p` via deep reflection. >> >> Put informally, you can give your friends additional access, but you >> can't discriminate against them by giving them less access than everyone >> else. >> >> As before, duplicate `exports` directives are not permitted, in order to >> ensure easy readability. At most one `exports` directive is relevant to >> any given package/module pair, and it's easy to determine which one. >> >> * * * >> >> The introduction of `private` as a modifier of `exports` directives calls >> the existing syntax of `requires public` even more strongly into question >> than before. A module declaration of the form >> >> module foo.bar { >> exports private com.foo.bar.baz; >> requires public java.sql; >> } >> >> is likely to be very confusing to an uninformed reader. The `private` >> modifier in the `exports` directive means that the private elements of >> the `com.foo.bar.baz` package are exported for deep reflection at run >> time. The `public` modifier in the `requires` directive, however, does >> not mean that the public elements of the `java.sql` module are needed by >> this module; that is true of any plain `requires` directive. It means >> that, additionally, any client of this module is granted implied >> readability to the `java.sql` module, thereby gaining access to all of >> its exported types. >> >> To reduce this confusion we rename the `public` modifier in `requires` >> directives to `transitive`. Thus the above example becomes >> >> module foo.bar { >> exports private com.foo.bar.baz; >> requires transitive java.sql; >> } >> >> This is potentially confusing in a different way, since in mathematics >> the term "transitive" is usually applied to an entire relation rather >> than to three specific elements of a set. Its use here does not, in >> particular, mean that the resolver does not interpret plain `requires` >> directives when computing the transitive closure of a set of root >> modules. "Transitive" as used here is in the more abstract sense, >> expressing the notion of conveying a property -- in this case, the >> readability of the required module -- from one thing to another. >> >> >> Notes >> ----- >> >> - This is significantly different from the first proposal [3]. It adds >> the notion of weak modules, to ease migration, and also the notion of >> exporting a package without enabling deep reflection, to strengthen >> encapsulation. >> >> - This proposal removes the notion of dynamic exports, which in the >> presence of private exports would introduce considerable complexity >> into the interactions between qualified and unqualified exports. >> This means that it is no longer possible to export a package only at >> run time, so it is no longer possible for the author of a module to >> express the intent that the types of a non-API package are meant to >> be available to frameworks for deep reflection at run time but >> inaccessible at compile time. The dynamic-export feature could, if >> needed, be added in a future release. >> >> - A strong module with no exports makes no types accessible to code in >> other modules while a weak module makes all of its types accessible, >> both directly and via deep reflection. The declarations of such >> modules are, however, visually similar since most of their text lies >> between the curly braces: >> >> module m1 { >> requires ...; >> uses ...; >> provides ...; >> } >> >> weak module m2 { >> requires ...; >> uses ...; >> provides ...; >> } >> >> We suspect that this visual similarity will not cause much confusion >> in practice since strong modules that export no packages will be very >> rare. >> >> - If a container is to ensure that a package in an application module >> is available for deep reflection only by a trusted framework then it >> can arrange for that by rewriting that module's descriptor, as >> suggested previously [4], to insert the appropriate qualified private >> export. If there is a possibility that two modules will need to >> export a package of the same name to the same framework module, as >> suggested by Jason Greene [5], then the container should instead >> inject a small class into each module whose static initializer >> invokes the `Module::addExports` method in order to export the >> package to the framework module. There is no need any longer for >> the resolution algorithm to take this scenario into account [6]. >> >> - This proposal primarily addresses "friendly" uses of reflection, such >> as dependency injection and persistence, in which the author of a >> module knows in advance that one or more packages must be exported at >> run time for deep reflective access by frameworks. Intrusive access >> to arbitrary packages of arbitrary modules by, e.g., serialization >> frameworks or debugging tools, will still require the use of sharp >> knives such as the `--add-exports` command-line option, the legacy >> unsupported `sun.misc.Unsafe` API and related APIs, or JVM TI. >> >> - Using the `--add-exports` option or its equivalent remains awkward, >> and sometimes it's the only way out. To ease migration it's worth >> considering some way for an application packaged as a JAR file to >> include such options in its `MANIFEST.MF` file, as suggested by Simon >> Nash [7]. This is tracked as #AddExportsInManifest [8]. >> >> >> [1] >> http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes >> >> [2] >> http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation >> >> [3] >> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-June/000307.html >> >> [4] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008637.html >> [5] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008641.html >> [6] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008727.html >> [7] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005745.html >> >> [8] >> http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest >> > -- - DML From dawid.weiss at gmail.com Mon Sep 19 07:12:51 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 19 Sep 2016 09:12:51 +0200 Subject: JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500) In-Reply-To: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> Message-ID: Guice 4.1.0 throws an exception from within the embedded cglib with this release: >java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+135-jigsaw-nightly-h5500-20160914) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+135-jigsaw-nightly-h5500-20160914, mixed mode) > [apptest] > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > at com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:252) > at com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:203) > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:53) > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:158) > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3542) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2323) > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2286) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2201) We had it working just fine with: Java(TM) SE Runtime Environment (build 9-ea+129-jigsaw-nightly-h5343-20160802) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+129-jigsaw-nightly-h5343-20160802, mixed mode) Dawid On Thu, Sep 15, 2016 at 7:07 PM, Alan Bateman wrote: > The EA download [1] has been refreshed with new builds that are mostly > aligned with the current proposals for JPMS issues [2]. Not everything is > there yet of course (and some areas need a few more iterations) but there is > enough to test and try things out. > > For #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation then > the initial support for `weak module` and `exports private` is in place. > These are probably the highest priority changes to try out. > > The changes to setAccessible in #AwkwardStrongEncapsulation is going to be > disruptive and will no doubt expose hacks in many areas. We've run into > several of these already. The command line option to allow existing code to > break into non-public types/members is --add-exports-private. The format of > the value passed to this option is the same--add-exports. With > #AddExportsInManifest then there are equivalents in the application JAR main > manifest to try out too. > > As part of the #ClassLoaderNames then the format of the stack trace elements > has changed. > > For #ServiceLoaderEnhancements then the implementation is mostly aligned, > except for the static factory method which needs an update to javac and SL > to align with the proposal (should be there soon, just not in this build). > > Several people have brought up #ResourceEncapsulation and > #ClassFilesAsResources here so it would be good to try this out. > > As always, the most valuable feedback is from those trying out the builds so > please let us know what you have tried and what works or doesn't work. > > -Alan > > [1] https://jdk9.java.net/jigsaw/ > [2] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009365.html From Alan.Bateman at oracle.com Mon Sep 19 12:12:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Sep 2016 05:12:43 -0700 Subject: NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> Message-ID: <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> On 19/09/2016 00:12, Dawid Weiss wrote: > Guice 4.1.0 throws an exception from within the embedded cglib with > this release: > >> java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+135-jigsaw-nightly-h5500-20160914) > Java HotSpot(TM) 64-Bit Server VM (build > 9-ea+135-jigsaw-nightly-h5500-20160914, mixed mode) > >> [apptest] > > Caused by: java.lang.NoClassDefFoundError: Could not initialize > class com.google.inject.internal.cglib.core.$ReflectUtils > > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > > at com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:252) > > at com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:203) > > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:53) > > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:158) > > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3542) > > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2323) > > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2286) > > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2201) > Can you run this with -Dsun.reflect.debugModuleAccessChecks=true to see if there is any exception thrown? -Alan From dawid.weiss at gmail.com Mon Sep 19 12:35:23 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 19 Sep 2016 14:35:23 +0200 Subject: NoClassDefFoundError: Could not initialize, class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> Message-ID: Yes, it prints: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "exports private java.lang" to unnamed module @4527468c at java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192) at java.base/java.lang.reflect.Method.setAccessible(Method.java:186) at com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUtils.java:52) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.google.inject.internal.cglib.core.$ReflectUtils.(ReflectUtils.java:42) at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) [truncated] D. On Mon, Sep 19, 2016 at 2:12 PM, Alan Bateman wrote: > On 19/09/2016 00:12, Dawid Weiss wrote: > >> Guice 4.1.0 throws an exception from within the embedded cglib with >> this release: >> >>> java -version >> >> java version "9-ea" >> Java(TM) SE Runtime Environment (build >> 9-ea+135-jigsaw-nightly-h5500-20160914) >> Java HotSpot(TM) 64-Bit Server VM (build >> 9-ea+135-jigsaw-nightly-h5500-20160914, mixed mode) >> >>> [apptest] >> >> > Caused by: java.lang.NoClassDefFoundError: Could not initialize >> class com.google.inject.internal.cglib.core.$ReflectUtils >> > at >> com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) >> > at >> com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) >> > at >> com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) >> > at >> com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:252) >> > at >> com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:203) >> > at >> com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:53) >> > at >> com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:158) >> > at >> com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) >> > at >> com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) >> > at >> com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) >> > at >> com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) >> > at >> com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) >> > at >> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3542) >> > at >> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2323) >> > at >> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2286) >> > at >> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2201) >> > Can you run this with -Dsun.reflect.debugModuleAccessChecks=true to see if > there is any exception thrown? > > -Alan From Alan.Bateman at oracle.com Mon Sep 19 12:47:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Sep 2016 05:47:58 -0700 Subject: NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> Message-ID: <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> On 19/09/2016 05:35, Dawid Weiss wrote: > Yes, it prints: > > java.lang.reflect.InaccessibleObjectException: Unable to make > protected final java.lang.Class > java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) > throws java.lang.ClassFormatError accessible: module java.base does > not "exports private java.lang" to unnamed module @4527468c > at java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414) > at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196) > at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192) > at java.base/java.lang.reflect.Method.setAccessible(Method.java:186) > at com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUtils.java:52) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.google.inject.internal.cglib.core.$ReflectUtils.(ReflectUtils.java:42) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > [truncated] > I assume running with `--add-exports-private java.base/java.lang=ALL-UNNAMED` will allow you get past this. -Alan From forax at univ-mlv.fr Mon Sep 19 13:27:56 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Sep 2016 15:27:56 +0200 (CEST) Subject: NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> Message-ID: <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> I wonder what is the best way to fix the code of Guice ? Use Unsafe.defineAnonymousClass ? cheers, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Dawid Weiss" > Cc: "jigsaw-dev" > Envoy?: Lundi 19 Septembre 2016 14:47:58 > Objet: Re: NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils > On 19/09/2016 05:35, Dawid Weiss wrote: > >> Yes, it prints: >> >> java.lang.reflect.InaccessibleObjectException: Unable to make >> protected final java.lang.Class >> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) >> throws java.lang.ClassFormatError accessible: module java.base does >> not "exports private java.lang" to unnamed module @4527468c >> at >> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414) >> at >> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196) >> at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192) >> at java.base/java.lang.reflect.Method.setAccessible(Method.java:186) >> at >> com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUtils.java:52) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at >> com.google.inject.internal.cglib.core.$ReflectUtils.(ReflectUtils.java:42) >> at >> com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) >> [truncated] >> > I assume running with `--add-exports-private > java.base/java.lang=ALL-UNNAMED` will allow you get past this. > > -Alan From dawid.weiss at gmail.com Mon Sep 19 17:01:34 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 19 Sep 2016 19:01:34 +0200 Subject: NoClassDefFoundError: Could not initialize, class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> Message-ID: Exactly. I reported the problem having the --add-exports-private option in the back of my mind (saw it in a recent thread somewhere), but what I'd be more interested in what R?mi asked about. As a separate note, having multiple non-compatible options becomes quite a burden to maintain in a complex build. We use shell scripts to launch (command-line) software, so shell scripts have to detect java version first and modify options accordingly (currently adding the missing modules with annotations), maven builds need a separate profile that adds these options to the compilation (and build), etc. Is there any other, more elegant way of doing this that I overlooked? Pardon the example, but Microsoft's executable manifest files come to mind -- something that permits attaching "metadata" options to the program without having to provide it explicitly. Ideally, this metadata could be conditionally specified for a given JVM version. It would be interesting to have "java -jar" have such "metadata" in the manifest.mf file or somewhere else, so that you could specify JVM-version-specific options there instead of providing them on command line. Just a thought. Dawid On Mon, Sep 19, 2016 at 3:27 PM, Remi Forax wrote: > I wonder what is the best way to fix the code of Guice ? > > Use Unsafe.defineAnonymousClass ? > > cheers, > R?mi > > ----- Mail original ----- >> De: "Alan Bateman" >> ?: "Dawid Weiss" >> Cc: "jigsaw-dev" >> Envoy?: Lundi 19 Septembre 2016 14:47:58 >> Objet: Re: NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils > >> On 19/09/2016 05:35, Dawid Weiss wrote: >> >>> Yes, it prints: >>> >>> java.lang.reflect.InaccessibleObjectException: Unable to make >>> protected final java.lang.Class >>> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) >>> throws java.lang.ClassFormatError accessible: module java.base does >>> not "exports private java.lang" to unnamed module @4527468c >>> at >>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414) >>> at >>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196) >>> at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192) >>> at java.base/java.lang.reflect.Method.setAccessible(Method.java:186) >>> at >>> com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUtils.java:52) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at >>> com.google.inject.internal.cglib.core.$ReflectUtils.(ReflectUtils.java:42) >>> at >>> com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) >>> [truncated] >>> >> I assume running with `--add-exports-private >> java.base/java.lang=ALL-UNNAMED` will allow you get past this. >> >> -Alan From Alan.Bateman at oracle.com Mon Sep 19 17:09:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Sep 2016 10:09:14 -0700 Subject: NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> Message-ID: <47659b76-8883-0c52-7c93-0ba28c4b87b6@oracle.com> On 19/09/2016 10:01, Dawid Weiss wrote: > Exactly. I reported the problem having the --add-exports-private > option in the back of my mind (saw it in a recent thread somewhere), > but what I'd be more interested in what R?mi asked about. > > As a separate note, having multiple non-compatible options becomes > quite a burden to maintain in a complex build. We use shell scripts to > launch (command-line) software, so shell scripts have to detect java > version first and modify options accordingly (currently adding the > missing modules with annotations), maven builds need a separate > profile that adds these options to the compilation (and build), etc. If you specify -XX:+IgnoreUnrecognizedVMOptions then JDK 8/older will ignore the JDK 9 options that it doesn't recognize. > > Is there any other, more elegant way of doing this that I overlooked? > Pardon the example, but Microsoft's executable manifest files come to > mind -- something that permits attaching "metadata" options to the > program without having to provide it explicitly. Ideally, this > metadata could be conditionally specified for a given JVM version. It > would be interesting to have "java -jar" have such "metadata" in the > manifest.mf file or somewhere else, so that you could specify > JVM-version-specific options there instead of providing them on > command line. Just a thought. > In the main manifest of the main application JAR then you can put: Add-Exports-Private: java.base/java.lang and it will be the equivalent of `--add-exports-private java.base/java.lang=ALL-UNNAMED` on the command-line. Only the main application JAR can have this attribute (it doesn't make sense for library JARs of course). -Alan From stephen.felts at oracle.com Mon Sep 19 18:43:29 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 19 Sep 2016 11:43:29 -0700 (PDT) Subject: NoClassDefFoundError: Could not initialize, class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> Message-ID: <873a9d74-47d3-4bbb-bac8-a1588b84161f@default> I have raised the issue of command line options several times.? I think the summary is the following. 1. I don't always have control of the command line. 2. I don't always own the main. 3. When multiple projects are merged into the same JVM, there is not a good way to merge command line options. 4. Different releases of the JDK require different options. ? One way to resolve this is to embed versioned command line option information into library jar files. ? Regarding using command line arguments in argument files: 1. Path names are relative to the current working directory, not the argument file.? - To use an argument file from anywhere, you need to have full pathnames. - To generate full pathnames in an argument file, you need to do processing on the argument file? (unzip is not sufficient). ? ? ? -----Original Message----- From: Dawid Weiss [mailto:dawid.weiss at gmail.com] Sent: Monday, September 19, 2016 1:02 PM To: Remi Forax Cc: jigsaw-dev Subject: Re: NoClassDefFoundError: Could not initialize, class com.google.inject.internal.cglib.core.$ReflectUtils ? Exactly. I reported the problem having the --add-exports-private option in the back of my mind (saw it in a recent thread somewhere), but what I'd be more interested in what R?mi asked about. ? As a separate note, having multiple non-compatible options becomes quite a burden to maintain in a complex build. We use shell scripts to launch (command-line) software, so shell scripts have to detect java version first and modify options accordingly (currently adding the missing modules with annotations), maven builds need a separate profile that adds these options to the compilation (and build), etc. ? Is there any other, more elegant way of doing this that I overlooked? Pardon the example, but Microsoft's executable manifest files come to mind -- something that permits attaching "metadata" options to the program without having to provide it explicitly. Ideally, this metadata could be conditionally specified for a given JVM version. It would be interesting to have "java -jar" have such "metadata" in the manifest.mf file or somewhere else, so that you could specify JVM-version-specific options there instead of providing them on command line. Just a thought. ? Dawid ? On Mon, Sep 19, 2016 at 3:27 PM, Remi Forax wrote: > I wonder what is the best way to fix the code of Guice ? >? > Use Unsafe.defineAnonymousClass ? >? > cheers, > R?mi >? > ----- Mail original ----- >> De: "Alan Bateman" >> ?: "Dawid Weiss" >> Cc: "jigsaw-dev" >> Envoy?: Lundi 19 Septembre 2016 14:47:58 >> Objet: Re: NoClassDefFoundError: Could not initialize,class?? com.google.inject.internal.cglib.core.$ReflectUtils >? >> On 19/09/2016 05:35, Dawid Weiss wrote: >>? >>> Yes, it prints: >>>? >>> java.lang.reflect.InaccessibleObjectException: Unable to make >>> protected final java.lang.Class >>> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,ja >>> va.security.ProtectionDomain) throws java.lang.ClassFormatError >>> accessible: module java.base does not "exports private java.lang" to >>> unnamed module @4527468c at >>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectExc >>> eption(Reflection.java:414) >>> at >>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(A >>> ccessibleObject.java:196) at >>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java >>> :192) at >>> java.base/java.lang.reflect.Method.setAccessible(Method.java:186) >>> at >>> com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUti >>> ls.java:52) at >>> java.base/java.security.AccessController.doPrivileged(Native Method) >>> at >>> com.google.inject.internal.cglib.core.$ReflectUtils.(Reflect >>> Utils.java:42) >>> at >>> com.google.inject.internal.cglib.reflect.$FastClass$Generator.getPro >>> tectionDomain(FastClass.java:73) >>> [truncated] >>>? >> I assume running with `--add-exports-private >> java.base/java.lang=ALL-UNNAMED` will allow you get past this. >>? >> -Alan ? From dawid.weiss at gmail.com Mon Sep 19 19:21:30 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 19 Sep 2016 21:21:30 +0200 Subject: NoClassDefFoundError: Could not initialize, class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: <47659b76-8883-0c52-7c93-0ba28c4b87b6@oracle.com> References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> <47659b76-8883-0c52-7c93-0ba28c4b87b6@oracle.com> Message-ID: > If you specify -XX:+IgnoreUnrecognizedVMOptions then JDK 8/older will ignore > the JDK 9 options that it doesn't recognize. But this only applies to -XX options, doesn't it? I can't quite use the gnu-style options with the above because how would it know what is an option and what is part of command line arguments? > jdk1.9\bin\java --add-modules jdk.xml.bind,java.activation -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+129-jigsaw-nightly-h5343-20160802) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+129-jigsaw-nightly-h5343-20160802, mixed mode) > jdk1.8\bin\java -XX:+IgnoreUnrecognizedVMOptions --add-modules jdk.xml.bind,java.activation -version Error: Could not find or load main class jdk.xml.bind,java.activation Also, we're can't really restrict our users to OpenJDK (or Oracle's distribution): > jdk1.8-ibm\bin\java -XX:+IgnoreUnrecognizedVMOptions --add-modules jdk.xml.bind,java.activation -version JVMJ9VM007E Command-line option unrecognised: --add-modules Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. > In the main manifest of the main application JAR then you can put: > > Add-Exports-Private: java.base/java.lang Yup, that's more what I had in mind. Dawid From Alan.Bateman at oracle.com Mon Sep 19 21:06:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Sep 2016 14:06:44 -0700 Subject: NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> <47659b76-8883-0c52-7c93-0ba28c4b87b6@oracle.com> Message-ID: <7d4d598b-b93d-7b68-1329-62decbbd5b64@oracle.com> On 19/09/2016 12:21, Dawid Weiss wrote: > : >> jdk1.8-ibm\bin\java -XX:+IgnoreUnrecognizedVMOptions --add-modules jdk.xml.bind,java.activation -version > JVMJ9VM007E Command-line option unrecognised: --add-modules > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. The space separator will confuse it, you can you try `--add-modules=jdk.xml.bind,java.activation`? -Alan From scolebourne at joda.org Tue Sep 20 05:19:59 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 19 Sep 2016 22:19:59 -0700 Subject: Java 9 EA javac exception on Windows Message-ID: I ran javac on Windows and I would have expected the error to have been caught, not to dump a stack trace. The command was to try and compile "*.java", (which should really be implemented to find all java files , but doesn't). >javac --module-source-path src -d mods *.java The exception was: Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <*> at index 0: *.java at sun.nio.fs.WindowsPathParser.normalize(java.base at 9-ea/WindowsPathPars er.java:182) at sun.nio.fs.WindowsPathParser.parse(java.base at 9-ea/WindowsPathParser.j ava:153) at sun.nio.fs.WindowsPathParser.parse(java.base at 9-ea/WindowsPathParser.j ava:77) at sun.nio.fs.WindowsPath.parse(java.base at 9-ea/WindowsPath.java:92) at sun.nio.fs.WindowsFileSystem.getPath(java.base at 9-ea/WindowsFileSystem .java:229) at java.nio.file.Paths.get(java.base at 9-ea/Paths.java:84) at com.sun.tools.javac.main.Option$34.process(jdk.compiler at 9-ea/Option.j ava:619) at com.sun.tools.javac.main.Option.handleOption(jdk.compiler at 9-ea/Option .java:988) at com.sun.tools.javac.main.Arguments.doProcessArgs(jdk.compiler at 9-ea/Ar guments.java:381) at com.sun.tools.javac.main.Arguments.processArgs(jdk.compiler at 9-ea/Argu ments.java:303) at com.sun.tools.javac.main.Arguments.init(jdk.compiler at 9-ea/Arguments.j ava:201) at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9-ea/Main.java:212 ) at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9-ea/Main.java:148 ) at com.sun.tools.javac.Main.compile(jdk.compiler at 9-ea/Main.java:55) at com.sun.tools.javac.Main.main(jdk.compiler at 9-ea/Main.java:41) From scolebourne at joda.org Tue Sep 20 05:25:36 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 19 Sep 2016 22:25:36 -0700 Subject: Java 9 EA 136 error Message-ID: When trying to compile a module-info.java file, "weak" is rejected (I assume not implemented yet). But, this is a report about the error handling, which fails to recognise that this is a module-info file, and thus outputs messages about missing class/interface/enum. Some additional processing is needed to work out that the user was trying to declare a module and got the syntax wrong: >\apps\jdk-9-ea\bin\javac --module-source-path src -d mods src\myapp\ org\myapp\MyApp.java src\mylib\org\mylib\MyLib.java src\myapp\module-info.java s rc\mylib\module-info.java src\myapp\module-info.java:1: error: class, interface, or enum expected weak module myapp { ^ src\myapp\module-info.java:3: error: class, interface, or enum expected } ^ 2 errors Stephen From dawid.weiss at gmail.com Tue Sep 20 06:58:57 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 20 Sep 2016 08:58:57 +0200 Subject: NoClassDefFoundError: Could not initialize, class com.google.inject.internal.cglib.core.$ReflectUtils In-Reply-To: <7d4d598b-b93d-7b68-1329-62decbbd5b64@oracle.com> References: <7aa2fc63-4c7e-3320-703a-a55b2caef3bf@oracle.com> <76f5a286-dd35-0c9c-2690-4fa32b804844@oracle.com> <716aa1b9-0924-5282-24af-b3fe829d9f12@oracle.com> <1946786525.335572.1474291676257.JavaMail.zimbra@u-pem.fr> <47659b76-8883-0c52-7c93-0ba28c4b87b6@oracle.com> <7d4d598b-b93d-7b68-1329-62decbbd5b64@oracle.com> Message-ID: Yes, the assignment version works on 1.8, 1.9, but it doesn't work on J9 (-XX:+IgnoreUnrecognizedVMOptions isn't implemented). I do have a java version check and conditional logic implemented in the bootstrap script, Alan, I just wanted to point out the issue, I'm not complaining ;) Dawid On Mon, Sep 19, 2016 at 11:06 PM, Alan Bateman wrote: > > On 19/09/2016 12:21, Dawid Weiss wrote: >> >> : >>> >>> jdk1.8-ibm\bin\java -XX:+IgnoreUnrecognizedVMOptions --add-modules >>> jdk.xml.bind,java.activation -version >> >> JVMJ9VM007E Command-line option unrecognised: --add-modules >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. > > The space separator will confuse it, you can you try > `--add-modules=jdk.xml.bind,java.activation`? > > -Alan From Alan.Bateman at oracle.com Tue Sep 20 12:58:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Sep 2016 05:58:01 -0700 Subject: Java 9 EA 136 error In-Reply-To: References: Message-ID: <7a9ea5c0-e839-286a-7083-77153ef93c2a@oracle.com> On 19/09/2016 22:25, Stephen Colebourne wrote: > When trying to compile a module-info.java file, "weak" is rejected (I > assume not implemented yet). Can you the Jigsaw EA download [1]? The regular JDK 9 downloads don't have support for the design issues that are till under discussion. -Alan [1] https://jdk9.java.net/jigsaw/ From scolebourne at joda.org Tue Sep 20 13:43:51 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 20 Sep 2016 06:43:51 -0700 Subject: Java 9 EA 136 error In-Reply-To: <7a9ea5c0-e839-286a-7083-77153ef93c2a@oracle.com> References: <7a9ea5c0-e839-286a-7083-77153ef93c2a@oracle.com> Message-ID: Just to note that the report below is mostly about the confusing error message, something which users will get if they write "wek" instead of "weak". (I've downloaded the correct build now and it has the same error message issue) thanks Stephen On 20 September 2016 at 05:58, Alan Bateman wrote: > > On 19/09/2016 22:25, Stephen Colebourne wrote: >> >> When trying to compile a module-info.java file, "weak" is rejected (I >> assume not implemented yet). > > Can you the Jigsaw EA download [1]? The regular JDK 9 downloads don't have > support for the design issues that are till under discussion. > > -Alan > > [1] https://jdk9.java.net/jigsaw/ From Alan.Bateman at oracle.com Tue Sep 20 14:49:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Sep 2016 07:49:09 -0700 Subject: Java 9 EA 136 error In-Reply-To: References: <7a9ea5c0-e839-286a-7083-77153ef93c2a@oracle.com> Message-ID: On 20/09/2016 06:43, Stephen Colebourne wrote: > Just to note that the report below is mostly about the confusing error > message, something which users will get if they write "wek" instead of > "weak". Understood, I'm sure Jon or Jan will comment on that. > (I've downloaded the correct build now and it has the same > error message issue) > What does `java -version` show? I ask because "weak module myapp { }" should compile with the EA builds. -Alan From scolebourne at joda.org Tue Sep 20 14:54:59 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 20 Sep 2016 07:54:59 -0700 Subject: Java 9 EA 136 error In-Reply-To: References: <7a9ea5c0-e839-286a-7083-77153ef93c2a@oracle.com> Message-ID: On 20 September 2016 at 07:49, Alan Bateman wrote: > What does `java -version` show? I ask because "weak module myapp { }" should > compile with the EA builds. Sorry I wasn't clear. The "weak module" part compiles now. Stephen From jonathan.gibbons at oracle.com Tue Sep 20 22:58:00 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Sep 2016 15:58:00 -0700 Subject: Java 9 EA 136 error In-Reply-To: References: <7a9ea5c0-e839-286a-7083-77153ef93c2a@oracle.com> Message-ID: <57E1BEF8.80308@oracle.com> On 09/20/2016 07:49 AM, Alan Bateman wrote: > On 20/09/2016 06:43, Stephen Colebourne wrote: > >> Just to note that the report below is mostly about the confusing error >> message, something which users will get if they write "wek" instead of >> "weak". > Understood, I'm sure Jon or Jan will comment on that. Stephen, Thanks for the report. Filed as https://bugs.openjdk.java.net/browse/JDK-8166420 -- Jon > >> (I've downloaded the correct build now and it has the same >> error message issue) >> > What does `java -version` show? I ask because "weak module myapp { }" > should compile with the EA builds. > > -Alan From blackdrag at gmx.org Wed Sep 21 05:50:13 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 21 Sep 2016 07:50:13 +0200 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> Message-ID: <57E21F95.3070700@gmx.org> On 12.09.2016 17:08, Mark Reinhold wrote: > Issue summary > ------------- > > #ReflectiveAccessToNonExportedTypes --- Some kinds of framework > libraries require reflective access to members of the non-exported > types of other modules; examples include dependency injection (Guice), > persistence (JPA), debugging tools, code-automation tools, and > serialization (XStream). In some cases the particular library to be > used is not known until run time (e.g., Hibernate and EclipseLink both > implement JPA). This capability is also sometimes used to work around > bugs in unchangeable code. Access to non-exported packages can, at > present, only be done via command-line flags, which is extremely > awkward. Provide an easier way for reflective code to access such > non-exported types. [1] > > #AwkwardStrongEncapsulation --- A non-public element of an exported > package can still be accessed via the `AccessibleObject::setAccessible` > method of the core reflection API. The only way to strongly > encapsulate such an element is to move it to a non-exported package. > This makes it awkward, at best, to encapsulate the internals of a > package that defines a public API. [2] [...] I?d like to give some feedback on this. Our situation was this, that we finally managed to get the Groovy build running on JDK9 with the jigsaw version before this change here came live. The situation now is, that gradle broke and we are not even starting compilation anymore. Well, can happen with a change like this. But the issue at hand was about using setAccessible (without exporting private) to get access to a protected method in java.base. When this proposal mentioned non-public I was actually automatically thinking private, but of course there are at least two more visibility options to think of. So I find another awkward point in #AwkwardStrongEncapsulation in that you have exported API and you have a protected method in it. You can write a class in your own module, that will overwrite or use that method given that it is in a subclass. But if I want to use setAccessible to invoke the method I cannot do that? This is awkward to me, because it degrades the former (and often misused) swiss-army-knife setAccessible to something that is even less capable than what I can do by subclassing - unless special action are taken. I can understand the idea for private methods or package private - but protected is for me always part of the API to program against and as such it makes not sense to me to prevent setAccessible accessing it here. bye Jochen From kasperni at gmail.com Wed Sep 21 10:36:51 2016 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 21 Sep 2016 12:36:51 +0200 Subject: Class names in java.lang.Module Message-ID: Hi, I was wondering if there are any reasons for why these 3 classes in java.lang.Module Configuration FindException ResolutionException Does not include the name Module? I especially am not to fond of the very generic Configuration name in my source code would much prefer something like ModuleConfiguration. Best Kasper From forax at univ-mlv.fr Wed Sep 21 10:58:15 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 21 Sep 2016 10:58:15 +0000 Subject: Class names in java.lang.Module In-Reply-To: References: Message-ID: <9F4B8C0F-B90E-462B-8309-D959BFAEC5BB@univ-mlv.fr> I agree. And Layer should also be called Module Layer. Remi On September 21, 2016 12:36:51 PM GMT+02:00, Kasper Nielsen wrote: >Hi, > >I was wondering if there are any reasons for why these 3 classes in >java.lang.Module > >Configuration >FindException >ResolutionException > >Does not include the name Module? >I especially am not to fond of the very generic Configuration name in >my >source code would much prefer something like ModuleConfiguration. > >Best > Kasper -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From ropalka at redhat.com Wed Sep 21 11:45:28 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 21 Sep 2016 13:45:28 +0200 Subject: Class names in java.lang.Module In-Reply-To: <9F4B8C0F-B90E-462B-8309-D959BFAEC5BB@univ-mlv.fr> References: <9F4B8C0F-B90E-462B-8309-D959BFAEC5BB@univ-mlv.fr> Message-ID: <8e3a4cd5-e3d7-b749-0bb5-e564a048ba62@redhat.com> +1 I'd also propose FindException -> ModuleNotFoundException Richard On 09/21/2016 12:58 PM, Remi Forax wrote: > I agree. > And Layer should also be called Module Layer. > > Remi > > On September 21, 2016 12:36:51 PM GMT+02:00, Kasper Nielsen wrote: >> Hi, >> >> I was wondering if there are any reasons for why these 3 classes in >> java.lang.Module >> >> Configuration >> FindException >> ResolutionException >> >> Does not include the name Module? >> I especially am not to fond of the very generic Configuration name in >> my >> source code would much prefer something like ModuleConfiguration. >> >> Best >> Kasper From david.lloyd at redhat.com Wed Sep 21 11:53:42 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 21 Sep 2016 06:53:42 -0500 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: <57E21F95.3070700@gmx.org> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <57E21F95.3070700@gmx.org> Message-ID: <58dc18e0-863d-661c-bfc8-e6d62ddd2074@redhat.com> On 09/21/2016 12:50 AM, Jochen Theodorou wrote: > On 12.09.2016 17:08, Mark Reinhold wrote: >> Issue summary >> ------------- >> >> #ReflectiveAccessToNonExportedTypes --- Some kinds of framework >> libraries require reflective access to members of the non-exported >> types of other modules; examples include dependency injection (Guice), >> persistence (JPA), debugging tools, code-automation tools, and >> serialization (XStream). In some cases the particular library to be >> used is not known until run time (e.g., Hibernate and EclipseLink both >> implement JPA). This capability is also sometimes used to work around >> bugs in unchangeable code. Access to non-exported packages can, at >> present, only be done via command-line flags, which is extremely >> awkward. Provide an easier way for reflective code to access such >> non-exported types. [1] >> >> #AwkwardStrongEncapsulation --- A non-public element of an exported >> package can still be accessed via the >> `AccessibleObject::setAccessible` >> method of the core reflection API. The only way to strongly >> encapsulate such an element is to move it to a non-exported package. >> This makes it awkward, at best, to encapsulate the internals of a >> package that defines a public API. [2] > [...] > > I?d like to give some feedback on this. Our situation was this, that we > finally managed to get the Groovy build running on JDK9 with the jigsaw > version before this change here came live. The situation now is, that > gradle broke and we are not even starting compilation anymore. Well, can > happen with a change like this. But the issue at hand was about using > setAccessible (without exporting private) to get access to a protected > method in java.base. When this proposal mentioned non-public I was > actually automatically thinking private, but of course there are at > least two more visibility options to think of. > > So I find another awkward point in #AwkwardStrongEncapsulation in that > you have exported API and you have a protected method in it. You can > write a class in your own module, that will overwrite or use that method > given that it is in a subclass. But if I want to use setAccessible to > invoke the method I cannot do that? This is awkward to me, because it > degrades the former (and often misused) swiss-army-knife setAccessible > to something that is even less capable than what I can do by subclassing > - unless special action are taken. I can understand the idea for private > methods or package private - but protected is for me always part of the > API to program against and as such it makes not sense to me to prevent > setAccessible accessing it here. It turns out that you don't actually need setAccessible to access a superclass protected method from a subclass. If you have an instance of a subclass of the type containing the protected method, any class in the _same package_ as the _subclass_ can call invoke() on a Method without first making it accessible, as long as you pass in that subclass instance (even if the method is static, which is a little weird but necessary to make the check work!). As to whether this makes sense in 100% of cases... that's a different discussion (and a fairly complex one at that - the code for checking protected access is (AFAICT) the most complex part of access checking in the JDK and the JVM). -- - DML From adinn at redhat.com Wed Sep 21 12:09:43 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 21 Sep 2016 13:09:43 +0100 Subject: Class names in java.lang.Module In-Reply-To: <9F4B8C0F-B90E-462B-8309-D959BFAEC5BB@univ-mlv.fr> References: <9F4B8C0F-B90E-462B-8309-D959BFAEC5BB@univ-mlv.fr> Message-ID: <547b3aba-b86e-f06a-3f3a-fca0f2b7ce7e@redhat.com> On 21/09/16 11:58, Remi Forax wrote: > I agree. > And Layer should also be called Module Layer. I don't really agree or disagree whether the above and previous names might have been better choices but is it really important enough to merit changing it all now after users have already started writing code to this set of names? (my Byteman agent for example). This sounds to me a tad like asking for class BikeShedding to be renamed to ModuleBikeShedding. Yes, if we are going to bike shed about module nomenclature then we probably ought to do so as diligently and earnestly as possible but ... really? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From blackdrag at gmx.org Wed Sep 21 12:29:45 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 21 Sep 2016 14:29:45 +0200 Subject: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports In-Reply-To: <58dc18e0-863d-661c-bfc8-e6d62ddd2074@redhat.com> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <57E21F95.3070700@gmx.org> <58dc18e0-863d-661c-bfc8-e6d62ddd2074@redhat.com> Message-ID: <57E27D39.1010308@gmx.org> On 21.09.2016 13:53, David M. Lloyd wrote: [...] > It turns out that you don't actually need setAccessible to access a > superclass protected method from a subclass. I can even override a non-final protected method and make it public, yes. > If you have an instance of a subclass of the type containing the > protected method, any class in the _same package_ as the _subclass_ can > call invoke() on a Method without first making it accessible, as long as > you pass in that subclass instance (even if the method is static, which > is a little weird but necessary to make the check work!). This will not work if the instance is not created by me > As to whether this makes sense in 100% of cases... that's a different > discussion (and a fairly complex one at that - the code for checking > protected access is (AFAICT) the most complex part of access checking in > the JDK and the JVM). and has many rules I did learn of quite late, yes. bye Jochen From scolebourne at joda.org Wed Sep 21 15:18:21 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 21 Sep 2016 08:18:21 -0700 Subject: Class names in java.lang.Module In-Reply-To: References: Message-ID: I had the same thought while watching the slides. Configuration is certainly a class name that exists other places, and would benefit from being ModuleConfiguration. Layer is less common, so not worried so much. Exceptions with "Module" in the name like ModuleNotFoundException would also be clearer. Stephen On 21 September 2016 at 03:36, Kasper Nielsen wrote: > Hi, > > I was wondering if there are any reasons for why these 3 classes in > java.lang.Module > > Configuration > FindException > ResolutionException > > Does not include the name Module? > I especially am not to fond of the very generic Configuration name in my > source code would much prefer something like ModuleConfiguration. > > Best > Kasper From david.lloyd at redhat.com Wed Sep 21 16:39:45 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 21 Sep 2016 11:39:45 -0500 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> Message-ID: In our internal discussion of the proposal for #ReflectiveAccessToNonExportedTypes, we discussed the ins and outs of various behaviors and have come up with a few ideas or starting points for solutions that we think would be more workable in conjunction with existing middleware (ours and others'). For reasons previously explained, we do not think that weak modules are a good way forward; I won't go into that again here. But the logical re-starting point is: If not weak modules, then what? I will boil it down to a few basic requirements that we have established. This list is probably non-exhaustive but hopefully complete enough to go on for now: ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public reflection only. ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public or private reflection only. ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public reflection and compilation/linkage (i.e. it's an export by today's terminology). ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public or private reflection and compilation/linkage (i.e. it's a "private" export by today's terminology). ? As today, any packages not declared in one or more of the above categories is inaccessible outside of the module in any way (note that as I showed previously we have also concluded that it should continue to be impossible to export a package for compilation/linkage without public reflection, as we have not discovered any use for such a mode). More generally: ? The syntax for all of the above has no particular constraint (in fact I will try to actively avoid touching what could be a very bikeshedding-rich discussion), except that it should not be construable as being pejorative against the usage of reflective frameworks; rather, it should be clear what level of trust is being established without raising undue warning. ? Applications should not need gratuitous amounts of declarations in their module(s) in order to utilize frameworks. ? As previously established, it should not be possible for one declaration to reduce the scope of access of another declaration in a module definition. ? Access to a module (for reflective purposes only) must not cause conflicts if multiple such modules which contain identical packages are accessible to a single consumer; in other words, reflection-only access into non-dependency modules is not bound by duplicate package restrictions as long as each package is unique per class loader, as per the current (Java 8) class loader rules. The above cover the useful access modes that we have identified. This is _nearly_ adequate to cover the use cases that we are currently concerned about; for example, I could export all packages for public reflection only to a specific framework, if only I know the module name of the implementation. Unfortunately, this does not work well in the case where a module may consume a framework whose specification is separate from the implementation. An application module may need to use (say) EJB and JPA; there is presently no clean way to do so without either (a) relying on a container environment to rewrite the descriptor or (b) opening up the module and defeating the security mechanism (e.g. "weak"). Without either of these workarounds, the application developer must have a good deal of knowledge about what modules provide what services within a framework-rich environment, possibly resulting in a very verbose (and error-prone) descriptor; none of these options is really satisfactory. Thus, apart from the option of redesigning (to an extent) the security mechanism (thereby eliminating the need to seal off access to public reflection, which is definitely still an attractive option for various reasons from our perspective, but which is also a very different discussion), we need some sort of mechanism which decouples the literal dependency system from access permission (much like uses/provides does). For example if I could declare that my module uses "javax.ejb", and, in so doing, automatically grants public and private reflective access to the module that provides that service, this would be a good outcome. A module which answers to that service name could be responsible for reflective access to the application module, providing that information privately to any other framework modules which require it. The migration story looks much better in this light: module descriptors still can be quite terse and specific. Applications which use reflective frameworks do not need gratuitous exports; in fact it's much more fluid for a user to say "I require these helper libraries; I use EJB; that's it" which means they don't have to worry about the details of whatever particular environment they run in. This also has the advantage of allowing new Java 9-generation specifications to stipulate standard service names for each specification (e.g. "javax.ejb", "javax.cdi", that sort of thing). While this doesn't cover 100% of our remaining issues with Jigsaw (of course; we'll all continue moving through the issues list as we have been to get us there), meeting these requirements would go a long way towards at least having a reflection story that is more practical for present-day frameworks to move forward with. So the last requirement would be: ? A module definition must be able to establish that an "indirect" dependency exists on an otherwise unknown module providing a capability, wherein that module may require public or public+private reflection access to some or all packages without compile/link access. This could possibly exist in conjunction with, or as an evolution of, the current services mechanism, however a complicating factor is that the current mechanism is based specifically on types, whereas a purely symbolic relationship might be better for this purpose (this is not a requirement though if it can be made to work as-is). Note that any symbolic relationship system would need some in-code discovery mechanism such that consumers of the capability are made available to the provider and/or vice-versa, in order to make practical use of the relationship. The following example syntax is meant to be unambiguous and illustrative; no specific attempt is made to reuse existing keywords (for example), or even to imply an endorsement of the current descriptor mechanism at all, but to clarify how this might look in practice and provide a practical application of the ideas herein. Example 1: A contrived provider of the fictional framework "javax.fictional.orm" illustrating provides/uses-based access granting module org.foo.orm.provider { // Require a module dependency, and give it private reflection access to everything requires org.apache.commons.beanutils with private reflection on *; // Require a module dependency with no reflection requires org.apache.commons.logging; // Provide the framework provides javax.fictional.orm.ORM using private reflection with org.foo.orm.provider.ORMImpl1, org.foo.orm.provider.ORMImpl2; } Example 2: A contrived consumer of #1 module com.mycompany.application { uses javax.fictional.orm.ORM; // automatically gives private reflection } Example 3: Grant reflection access to a couple of packages to a named non-dependency module module com.mycompany.application { grant public reflection on com.mycompay.application.package1, com.mycompay.application.package2 to org.foo.framework; } Example 4: Behave like Java 8 module com.mycompany.application { grant private reflection on * to *; } Example 5: Behave like Java 8, but restrict private access without requiring a security manager module com.mycompany.application { grant public reflection on * to *; } Example 6: An example of using CDI and EJB with symbolic capabilities module com.mycompany.application { uses capability javax.ejb, javax.cdi } Example 7: An example of providing EJB with symbolic capabilities module org.foo.ejb.provider { [...] provides capability javax.ejb using private reflection; } -- - DML From martin.lehmann at gmx.de Wed Sep 21 19:48:31 2016 From: martin.lehmann at gmx.de (Martin Lehmann) Date: Wed, 21 Sep 2016 21:48:31 +0200 Subject: Follow-up question on new proposals for #ResourceEncapsulation & #ClassFilesAsResources Message-ID: <000201d21441$21a3fa30$64ebee90$@gmx.de> Hi all, I have a follow-up question on the new proposal on #ResourceEncapsulation, which states: > The effective package name of a resource named by the string > `"/foo/bar/baz"`, e.g., is 'foo.bar'. The idea of using resource paths as "effective package names" definitely makes sense to me. Sounds like a pragmatic way of getting this important requirement finally done. Great! But with the new module system, classes on the unnamed package are no longer allowed. The compiler rejects them with "error: unnamed package is not allowed in named modules". I am wondering what's going to happen with resources on the "unnamed path", so to say. It's not uncommon that resources like a "log4j.properties" are put and searched on the top-level path - i.e. the equivalent of the unnamed (class) package. What will happen to that at compile time (probably nothing?), at packaging time (jar does complain?) and at runtime? Thanks in advance, cheers, Martin -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Mark Reinhold Sent: Monday, September 12, 2016 5:20 PM To: jigsaw-dev at openjdk.java.net Subject: More proposals for open JPMS issues FYI, I've just posted new or revised proposals for some of the open issues in the JPMS specification: #ReflectiveAccessToNonExportedTypes & #AwkwardStrongEncapsulation http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 90.html #AddExportsInManifest http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 91.html #ResourceEncapsulation & #ClassFilesAsResources http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 92.html #VersionsInModuleNames http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 93.html #ClassLoaderNames http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 94.html #ServiceLoaderEnhancements http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 95.html Links to the proposals are also available in the issue summary [1]. The first proposal, for #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation, is likely to be of the broadest interest since it makes significant changes to the syntax and semantics of module declarations. The latter issue is a new issue, reported by Martin Buchholz and Aleksey Shipilev, and is summarized thus: #AwkwardStrongEncapsulation --- A non-public element of an exported package can still be accessed via the `AccessibleObject::setAccessible` method of the core reflection API. The only way to strongly encapsulate such an element is to move it to a non-exported package. This makes it awkward, at best, to encapsulate the internals of a package that defines a public API. The present design suffers this limitation due to an earlier compromise made to accommodate reflective access by frameworks, but experience has now shown that to be a problematic approach. It would be unfortunate indeed to bake this limitation into the module system for all time: It would make it much more difficult for developers to strongly encapsulate the internals of their own modules, yet enabling such encapsulation is one of the primary goals of this project. Thus this new proposal, which introduces the concepts of weak modules and private exports and removes the previously-proposed notion of dynamic exports. This has taken some time to work out but, in the end, appears to achieve a better balance of usability, ease of migration, and expressive power. Comments and discussion are welcome here on jigsaw-dev but, as usual, the best way to ensure that the EG sees any specific comment is to send it to the EG's "suggestion box" list, jpms-spec-comments [2]. If you comment on one of these proposals, via any channel, please include its hashtag in the subject line of your message to simplify tracking. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ [2] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments From peter.levart at gmail.com Wed Sep 21 20:44:29 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 21 Sep 2016 13:44:29 -0700 Subject: Class names in java.lang.Module In-Reply-To: References: Message-ID: This would only make sense if it was likely to have to deal with two Configuration classes in the same source file. How likely is that? OTOH, short names make code easier to read. Just my 2c. Regards, Peter On Sep 21, 2016 8:19 AM, "Stephen Colebourne" wrote: > I had the same thought while watching the slides. Configuration is > certainly a class name that exists other places, and would benefit > from being ModuleConfiguration. Layer is less common, so not worried > so much. Exceptions with "Module" in the name like > ModuleNotFoundException would also be clearer. > Stephen > > On 21 September 2016 at 03:36, Kasper Nielsen wrote: > > Hi, > > > > I was wondering if there are any reasons for why these 3 classes in > > java.lang.Module > > > > Configuration > > FindException > > ResolutionException > > > > Does not include the name Module? > > I especially am not to fond of the very generic Configuration name in my > > source code would much prefer something like ModuleConfiguration. > > > > Best > > Kasper > From Alan.Bateman at oracle.com Wed Sep 21 20:50:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Sep 2016 13:50:04 -0700 Subject: Follow-up question on new proposals for #ResourceEncapsulation & #ClassFilesAsResources In-Reply-To: <000201d21441$21a3fa30$64ebee90$@gmx.de> References: <000201d21441$21a3fa30$64ebee90$@gmx.de> Message-ID: <093b88a1-467c-4f54-4775-560c4b1311e9@oracle.com> On 21/09/2016 12:48, Martin Lehmann wrote: > : > But with the new module system, classes on the unnamed package are no longer > allowed. The compiler rejects them with "error: unnamed package is not > allowed in named modules". > I am wondering what's going to happen with resources on the "unnamed path", > so to say. > > It's not uncommon that resources like a "log4j.properties" are put and > searched on the top-level path - i.e. the equivalent of the unnamed (class) > package. > > What will happen to that at compile time (probably nothing?), at packaging > time (jar does complain?) and at runtime? Resources in the "top-level directory" aren't encapsulated (as a module module can't contain types in the unnamed package as you noted) so no issue when compiling, packaging or at runtime. -Alan From mandy.chung at oracle.com Fri Sep 23 00:02:48 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:02:48 +0000 Subject: hg: jigsaw/jake: 12 new changesets Message-ID: <201609230002.u8N02m3D025822@aojmv0008.oracle.com> Changeset: 46e9e983e97b Author: sundar Date: 2016-09-13 20:59 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/46e9e983e97b 8163320: JAVA_VERSION in release file should come from java.base module Reviewed-by: mchung ! make/Images.gmk Changeset: ed4e02fb36c3 Author: ctornqvi Date: 2016-08-25 08:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ed4e02fb36c3 8164737: Remove Unsafe dependency from ProcessTools Reviewed-by: gtriantafill, dholmes ! test/lib/jdk/test/lib/Utils.java + test/lib/jdk/test/lib/unsafe/UnsafeHelper.java Changeset: cc86bba93a12 Author: amurillo Date: 2016-08-26 10:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cc86bba93a12 Merge Changeset: 2d994eeff61a Author: dpochepk Date: 2016-08-23 19:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2d994eeff61a 8164608: [TESTBUG] compiler/profiling tests fail to compile Reviewed-by: ctornqvi ! test/lib/jdk/test/lib/Utils.java Changeset: 9a47ecd3eeb9 Author: iveresov Date: 2016-08-26 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9a47ecd3eeb9 Merge ! test/lib/jdk/test/lib/Utils.java Changeset: 9f7fee220f87 Author: amurillo Date: 2016-09-01 14:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9f7fee220f87 Merge Changeset: c7d95b8c9857 Author: amurillo Date: 2016-09-01 15:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c7d95b8c9857 Merge ! test/lib/jdk/test/lib/Utils.java Changeset: 4ad4af1f5ce5 Author: amurillo Date: 2016-09-10 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4ad4af1f5ce5 Merge Changeset: 2621705c0d5a Author: amurillo Date: 2016-09-14 11:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2621705c0d5a Merge Changeset: d7f519b00425 Author: lana Date: 2016-09-15 21:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d7f519b00425 Merge Changeset: 35258ac238e8 Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/35258ac238e8 Added tag jdk-9+137 for changeset d7f519b00425 ! .hgtags Changeset: 2df0e2d31b10 Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2df0e2d31b10 Merge ! make/Images.gmk From mandy.chung at oracle.com Fri Sep 23 00:02:54 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:02:54 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201609230002.u8N02t5g025876@aojmv0008.oracle.com> Changeset: 27bb44be3207 Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/27bb44be3207 Added tag jdk-9+137 for changeset 258cf18fa7fc ! .hgtags Changeset: 159c8c670ecc Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/159c8c670ecc Merge From mandy.chung at oracle.com Fri Sep 23 00:03:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:03:15 +0000 Subject: hg: jigsaw/jake/hotspot: 82 new changesets Message-ID: <201609230003.u8N03FhO025944@aojmv0008.oracle.com> Changeset: dd951011f433 Author: dfazunen Date: 2016-08-25 14:12 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dd951011f433 8164133: Tests gc/arguments/TestAlignmentToUseLargePages.java and gc/cms/TestBubbleUpRef.java use too small heap Reviewed-by: jmasa, sangheki, kzhaldyb ! test/gc/arguments/TestAlignmentToUseLargePages.java ! test/gc/cms/TestBubbleUpRef.java Changeset: da9cc21bd128 Author: ctornqvi Date: 2016-08-25 08:40 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/da9cc21bd128 8164737: Remove Unsafe dependency from ProcessTools Reviewed-by: gtriantafill, dholmes ! test/compiler/intrinsics/unsafe/TestUnsafeMismatchedArrayFieldAccess.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java ! test/compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java ! test/compiler/loopopts/superword/TestVectorizationWithInvariant.java ! test/compiler/rtm/locking/TestRTMAbortRatio.java ! test/compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java ! test/compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java ! test/compiler/rtm/locking/TestRTMLockingThreshold.java ! test/compiler/rtm/locking/TestRTMTotalCountIncrRate.java ! test/compiler/testlibrary/rtm/XAbortProvoker.java ! test/compiler/unsafe/UnsafeRaw.java ! test/gc/arguments/TestMaxMinHeapFreeRatioFlags.java ! test/gc/arguments/TestTargetSurvivorRatioFlag.java ! test/runtime/ErrorHandling/CreateCoredumpOnCrash.java ! test/runtime/ErrorHandling/ProblematicFrameTest.java ! test/runtime/Unsafe/AllocateInstance.java ! test/runtime/Unsafe/AllocateMemory.java ! test/runtime/Unsafe/CopyMemory.java ! test/runtime/Unsafe/DefineClass.java ! test/runtime/Unsafe/FieldOffset.java ! test/runtime/Unsafe/GetField.java ! test/runtime/Unsafe/GetPutAddress.java ! test/runtime/Unsafe/GetPutBoolean.java ! test/runtime/Unsafe/GetPutByte.java ! test/runtime/Unsafe/GetPutChar.java ! test/runtime/Unsafe/GetPutDouble.java ! test/runtime/Unsafe/GetPutFloat.java ! test/runtime/Unsafe/GetPutInt.java ! test/runtime/Unsafe/GetPutLong.java ! test/runtime/Unsafe/GetPutObject.java ! test/runtime/Unsafe/GetPutShort.java ! test/runtime/Unsafe/GetUncompressedObject.java ! test/runtime/Unsafe/NestedUnsafe.java ! test/runtime/Unsafe/PageSize.java ! test/runtime/Unsafe/RangeCheck.java ! test/runtime/Unsafe/Reallocate.java ! test/runtime/Unsafe/SetMemory.java ! test/runtime/Unsafe/ThrowException.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java Changeset: 92e705c1e6e6 Author: rprotacio Date: 2016-08-25 09:23 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/92e705c1e6e6 8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent Summary: Added default format checking of class names loaded by the app class loader Reviewed-by: coleenp, lfoltan ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/reflection.cpp + test/runtime/ClassFile/BadHelloWorld.jcod + test/runtime/ClassFile/FormatCheckingTest.java Changeset: 12f7e6595b9f Author: rprotacio Date: 2016-08-25 13:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/12f7e6595b9f Merge Changeset: 22c1219edf6f Author: ysuenaga Date: 2016-08-25 12:24 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/22c1219edf6f 8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap Reviewed-by: dholmes, sjohanss ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java Changeset: b50061da090e Author: dsamersoff Date: 2016-08-26 13:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b50061da090e 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. Summary: Update jmap-hashcode/Test8028623.java to use LingeredApp and rename it to jhsdb/HeapDumpTest.java Reviewed-by: dsamersoff, dholmes Contributed-by: sharath.ballal at oracle.com - test/serviceability/sa/jmap-hashcode/Test8028623.java Changeset: c78972384b23 Author: iklam Date: 2016-08-26 06:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c78972384b23 8161280: assert failed: reference count underflow for symbol Reviewed-by: dholmes, coleenp, kbarrett ! src/share/vm/oops/symbol.cpp ! src/share/vm/runtime/atomic.hpp Changeset: b94f7c960bc4 Author: amurillo Date: 2016-08-26 10:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b94f7c960bc4 Merge Changeset: 6f10754f85d9 Author: kvn Date: 2016-08-18 14:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6f10754f85d9 8162496: missing precedence edge for anti_dependence Summary: fix Implicit Null Check optimization code. Reviewed-by: roland, aph ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/lcm.cpp Changeset: e0a8f4132724 Author: thartmann Date: 2016-08-19 08:34 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e0a8f4132724 8064892: Non-methods code cache overflow is not handled correctly Summary: Should keep track of requested code blob type for error reporting. Added additional debug output. Reviewed-by: kvn, dpochepk ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp Changeset: 7c52bc363c21 Author: iveresov Date: 2016-08-19 14:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7c52bc363c21 Merge - test/runtime/modules/Visibility/XpatchVisibility.java - test/runtime/modules/Xpatch/BasicJarBuilder.java - test/runtime/modules/Xpatch/Xpatch2Dirs.java - test/runtime/modules/Xpatch/Xpatch2DirsMain.java - test/runtime/modules/Xpatch/XpatchDupJavaBase.java - test/runtime/modules/Xpatch/XpatchDupModule.java - test/runtime/modules/Xpatch/XpatchJavaBase.java - test/runtime/modules/Xpatch/XpatchMain.java - test/runtime/modules/Xpatch/XpatchTest.java - test/runtime/modules/Xpatch/XpatchTestJar.java - test/runtime/modules/Xpatch/XpatchTestJarDir.java - test/runtime/modules/Xpatch/XpatchTraceCL.java - test/runtime/modules/XpatchCDS.java - test/testlibrary/ClassFileInstaller.java - test/testlibrary/RedefineClassHelper.java - test/testlibrary/jdk/test/lib/AllocationHelper.java - test/testlibrary/jdk/test/lib/Asserts.java - test/testlibrary/jdk/test/lib/BuildHelper.java - test/testlibrary/jdk/test/lib/ByteCodeLoader.java - test/testlibrary/jdk/test/lib/DynamicVMOption.java - test/testlibrary/jdk/test/lib/ExitCode.java - test/testlibrary/jdk/test/lib/FileInstaller.java - test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java - test/testlibrary/jdk/test/lib/InMemoryJavaCompiler.java - test/testlibrary/jdk/test/lib/InfiniteLoop.java - test/testlibrary/jdk/test/lib/InputArguments.java - test/testlibrary/jdk/test/lib/JDKToolFinder.java - test/testlibrary/jdk/test/lib/JDKToolLauncher.java - test/testlibrary/jdk/test/lib/OutputAnalyzer.java - test/testlibrary/jdk/test/lib/OutputBuffer.java - test/testlibrary/jdk/test/lib/Pair.java - test/testlibrary/jdk/test/lib/Platform.java - test/testlibrary/jdk/test/lib/ProcessTools.java - test/testlibrary/jdk/test/lib/StreamPumper.java - test/testlibrary/jdk/test/lib/TimeLimitedRunner.java - test/testlibrary/jdk/test/lib/Triple.java - test/testlibrary/jdk/test/lib/Utils.java - test/testlibrary/jdk/test/lib/cli/CPUSpecificCommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/CommandLineOptionTest.java - test/testlibrary/jdk/test/lib/cli/predicate/AndPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/CPUSpecificPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/NotPredicate.java - test/testlibrary/jdk/test/lib/cli/predicate/OrPredicate.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutor.java - test/testlibrary/jdk/test/lib/dcmd/CommandExecutorException.java - test/testlibrary/jdk/test/lib/dcmd/FileJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JMXExecutor.java - test/testlibrary/jdk/test/lib/dcmd/JcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/MainClassJcmdExecutor.java - test/testlibrary/jdk/test/lib/dcmd/PidJcmdExecutor.java - test/testlibrary/jdk/test/lib/dtrace/DtraceResultsAnalyzer.java - test/testlibrary/jdk/test/lib/dtrace/DtraceRunner.java Changeset: decd90cdad6f Author: dpochepk Date: 2016-08-20 00:15 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/decd90cdad6f 8139700: compiler/jvmci/compilerToVM/DisassembleCodeBlobTest and InvalidateInstalledCodeTest timeout Reviewed-by: kvn ! test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java Changeset: 89151398365e Author: iveresov Date: 2016-08-19 15:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89151398365e Merge ! test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java Changeset: aad37d930942 Author: iveresov Date: 2016-08-19 18:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aad37d930942 Merge Changeset: 8eab4734c758 Author: iveresov Date: 2016-08-22 11:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8eab4734c758 8164122: C1: assert(false) failed: stack or locks not matching (invalid bytecodes) Summary: Ignore return value if MH intrinsic returns void Reviewed-by: roland, kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp Changeset: d92ba4bc628e Author: dnsimon Date: 2016-08-22 19:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d92ba4bc628e 8163864: [JVMCI] move MethodProfileWidth to jvmci_globals.hpp Reviewed-by: zmajo ! src/share/vm/jvmci/jvmci_globals.cpp ! src/share/vm/jvmci/jvmci_globals.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp Changeset: 153bd3fefb24 Author: dnsimon Date: 2016-08-22 20:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/153bd3fefb24 Merge Changeset: 2629b100a7e3 Author: thartmann Date: 2016-08-23 13:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2629b100a7e3 8038348: Instance field load is replaced by wrong data Phi Summary: Store additional information in PhiNodes corresponding to known instance field values to avoid incorrect reusage. Reviewed-by: kvn, vlivanov ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.hpp Changeset: 4fe8f74f70d0 Author: dnsimon Date: 2016-08-23 15:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4fe8f74f70d0 8164214: [JVMCI] include VarHandle in signature polymorphic method test Reviewed-by: kvn, twisti, iveresov, psandoz ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaMethod.java ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java Changeset: 10f876d80ff3 Author: dpochepk Date: 2016-08-23 19:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/10f876d80ff3 8164608: [TESTBUG] compiler/profiling tests fail to compile Reviewed-by: ctornqvi ! test/compiler/profiling/spectrapredefineclass/Launcher.java ! test/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: 142dffd0a218 Author: dpochepk Date: 2016-08-23 18:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/142dffd0a218 Merge Changeset: d1caa7589bfb Author: tpivovarova Date: 2016-08-23 19:53 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d1caa7589bfb 8164648: [TESTBUG] jittester failed compilation after 8157957 Reviewed-by: vlivanov ! test/testlibrary/jittester/Makefile Changeset: c4da53d89b97 Author: tpivovarova Date: 2016-08-23 18:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c4da53d89b97 Merge Changeset: 60e84c7db2f7 Author: vdeshpande Date: 2016-08-23 12:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/60e84c7db2f7 8151988: Hotspot deoptimizes div/mod pair usage Summary: don't remove control edge of Mod node until DivMod node matching Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/divnode.cpp Changeset: 2c21dc5d3b36 Author: dnsimon Date: 2016-08-23 22:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2c21dc5d3b36 8164358: [JVMCI] expose Hotspot intrinsics and HotSpotIntrinsicCandidate info to JVMCI Reviewed-by: twisti, kvn, never ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigStore.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/VMIntrinsicMethod.java ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.hpp ! src/share/vm/jvmci/jvmciJavaClasses.hpp ! src/share/vm/jvmci/systemDictionary_jvmci.hpp ! src/share/vm/jvmci/vmStructs_jvmci.cpp ! src/share/vm/jvmci/vmSymbols_jvmci.hpp - test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java + test/compiler/jvmci/compilerToVM/ReadConfigurationTest.java Changeset: 1e1704f8d3c1 Author: dnsimon Date: 2016-08-23 22:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1e1704f8d3c1 Merge Changeset: 10dad1d40843 Author: vlivanov Date: 2016-08-25 12:51 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/10dad1d40843 8162101: C2: Handle "wide" aliases for unsafe accesses Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/type.hpp ! test/compiler/unsafe/OpaqueAccesses.java Changeset: bde4bcd58309 Author: vlivanov Date: 2016-08-25 12:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bde4bcd58309 8155635: C2: Mixed unsafe accesses break alias analysis Reviewed-by: jrose, kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/unsafe/MixedUnsafeStoreObject.java Changeset: 119a2a3cc29b Author: jcm Date: 2016-08-25 02:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/119a2a3cc29b 8158639: C2 compilation fails with SIGSEGV Summary: fixed the jvms for callsite traps based on declared signature. Reviewed-by: kvn, vlivanov, dlong ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/graphKit.hpp ! test/compiler/jsr292/NullConstantReceiver.java Changeset: 8dcab338ec58 Author: iveresov Date: 2016-08-26 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8dcab338ec58 Merge - src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp - src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp - src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp - src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp - src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp - src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp - src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp - src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp - src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp - src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp - src/share/vm/runtime/atomic.inline.hpp ! src/share/vm/runtime/globals.hpp - test/serviceability/sa/jmap-hashcode/Test8028623.java Changeset: 6ac1e2e55eaa Author: mlarsson Date: 2016-04-05 16:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ac1e2e55eaa 8150894: Unused -Xlog tag sequences are silently ignored. Reviewed-by: rehn, sla ! src/share/vm/logging/logConfiguration.cpp ! src/share/vm/logging/logTagLevelExpression.cpp ! src/share/vm/logging/logTagLevelExpression.hpp ! src/share/vm/logging/logTagSet.hpp ! test/native/logging/test_logConfiguration.cpp Changeset: 346a9ca4e31e Author: mlarsson Date: 2016-08-26 14:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/346a9ca4e31e 8150823: UL disables log outputs incorrectly Reviewed-by: rehn, sla ! src/share/vm/logging/logConfiguration.cpp ! test/native/logging/test_logConfiguration.cpp Changeset: 59fe439d8f97 Author: dfazunen Date: 2016-08-29 23:04 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59fe439d8f97 8164660: MinimalVM is not tested with GC tests Reviewed-by: jmasa, tschatzl ! test/gc/TestCardTablePageCommits.java ! test/gc/TestObjectAlignment.java ! test/gc/TestSmallHeap.java ! test/gc/TestSoftReferencesBehaviorOnOOME.java ! test/gc/TestVerifyDuringStartup.java ! test/gc/TestVerifySilently.java ! test/gc/TestVerifySubSet.java ! test/gc/g1/TestEagerReclaimHumongousRegions.java ! test/gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java ! test/gc/g1/TestEagerReclaimHumongousRegionsWithRefs.java ! test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java ! test/gc/g1/TestGCLogMessages.java ! test/gc/g1/TestHumongousAllocInitialMark.java ! test/gc/g1/TestHumongousAllocNearlyFullRegion.java ! test/gc/g1/TestHumongousCodeCacheRoots.java ! test/gc/g1/TestPrintRegionRememberedSetInfo.java ! test/gc/g1/TestStringDeduplicationAgeThreshold.java ! test/gc/g1/TestStringDeduplicationFullGC.java ! test/gc/g1/TestStringDeduplicationInterned.java ! test/gc/g1/TestStringDeduplicationPrintOptions.java ! test/gc/g1/TestStringDeduplicationTableRehash.java ! test/gc/g1/TestStringDeduplicationTableResize.java ! test/gc/g1/TestStringDeduplicationYoungGC.java ! test/gc/g1/TestStringSymbolTableStats.java ! test/gc/serial/HeapChangeLogging.java Changeset: 24d88ded4cb6 Author: dholmes Date: 2016-08-29 20:13 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/24d88ded4cb6 8158854: Ensure release_store is paired with load_acquire in lock-free code Reviewed-by: shade, dcubed, zgu ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/oops/arrayKlass.hpp + src/share/vm/oops/arrayKlass.inline.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlass.inline.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b9a861dc8f9d Author: tschatzl Date: 2016-08-30 09:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b9a861dc8f9d 8155917: Memory access in free regions during G1 full gc causes regressions in SPECjvm2008 scimark.fft,lu,sor,sparse with 9+116 on Linux-x64 Summary: Do not unnecessarily touch the memory of free regions during the compaction phase in G1 full gc causing some OSes to allocate physical memory for them, decreasing performance in some situations. Reviewed-by: mgerdin, jmasa ! src/share/vm/gc/shared/space.inline.hpp Changeset: 1357a160e4f2 Author: dsamersoff Date: 2016-08-30 11:06 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1357a160e4f2 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE Summary: Addition of ?XX:+UnlockDiagnosticVMOptions for the test invocation for jcmd and modularization related cleanup Reviewed-by: dholmes, mchung Contributed-by: jini.george at oracle.com ! test/serviceability/sa/TestInstanceKlassSize.java ! test/serviceability/sa/TestInstanceKlassSizeForInterface.java Changeset: dce4f03f16d2 Author: dsamersoff Date: 2016-08-30 09:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dce4f03f16d2 Merge Changeset: fe8e4400e0bd Author: akulyakh Date: 2016-08-30 12:48 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fe8e4400e0bd 8148103: add more tests for task "Update JDI and JDWP for modules" Summary: A new JDWP test Reviewed-by: sspitsyn + test/serviceability/jdwp/AllModulesCommandTest.java + test/serviceability/jdwp/AllModulesCommandTestDebuggee.java + test/serviceability/jdwp/DebuggeeLauncher.java + test/serviceability/jdwp/JdwpAllModulesCmd.java + test/serviceability/jdwp/JdwpAllModulesReply.java + test/serviceability/jdwp/JdwpCanReadCmd.java + test/serviceability/jdwp/JdwpCanReadReply.java + test/serviceability/jdwp/JdwpChannel.java + test/serviceability/jdwp/JdwpClassLoaderCmd.java + test/serviceability/jdwp/JdwpClassLoaderReply.java + test/serviceability/jdwp/JdwpCmd.java + test/serviceability/jdwp/JdwpExitCmd.java + test/serviceability/jdwp/JdwpModNameCmd.java + test/serviceability/jdwp/JdwpModNameReply.java + test/serviceability/jdwp/JdwpReply.java + test/serviceability/jdwp/StreamHandler.java Changeset: 3d026957cd98 Author: kbarrett Date: 2016-08-30 23:48 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3d026957cd98 8156500: Move Reference pending list into VM to prevent deadlocks Summary: Move reference pending list and locking into VM Reviewed-by: coleenp, dholmes, dcubed, mchung, plevart Contributed-by: kim.barrett at oracle.com, per.liden at oracle.com ! make/symbols/symbols-unix ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc/cms/concurrentMarkSweepThread.cpp ! src/share/vm/gc/cms/vmCMSOperations.cpp ! src/share/vm/gc/cms/vmCMSOperations.hpp ! src/share/vm/gc/g1/concurrentMarkThread.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/vm_operations_g1.cpp ! src/share/vm/gc/g1/vm_operations_g1.hpp ! src/share/vm/gc/shared/collectedHeap.hpp ! src/share/vm/gc/shared/genCollectedHeap.hpp - src/share/vm/gc/shared/referencePendingListLocker.cpp - src/share/vm/gc/shared/referencePendingListLocker.hpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/referenceProcessor.hpp ! src/share/vm/gc/shared/vmGCOperations.cpp ! src/share/vm/gc/shared/vmGCOperations.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 3652a2a22916 Author: dsamersoff Date: 2016-08-31 11:47 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3652a2a22916 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" Summary: Accounted for the new JVMCI related Deoptimization Reasons. Reviewed-by: dsamersoff, sla Contributed-by: jini.george at oracle.com ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 47bb3faf5b08 Author: coleenp Date: 2016-08-31 06:35 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/47bb3faf5b08 8164692: InstanceKlass::_previous_version_count goes negative Summary: decrement previous_version_count when it's removed from the list. Reviewed-by: dcubed, dlong, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp + test/runtime/RedefineTests/RedefineCount.java Changeset: 3f7812f59bf7 Author: erikj Date: 2016-08-31 16:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f7812f59bf7 8164862: 2 JVMCI tests should not be executed on linux-x86 Reviewed-by: kvn, gtriantafill ! test/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/MaxOopMapStackOffsetTest.java ! test/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java Changeset: 145e6c9b7643 Author: hseigel Date: 2016-08-31 10:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/145e6c9b7643 8162412: Ignore any System property specified as -Djdk.module that matches reserved module system properties Summary: Change the checks for module related properties to look for specific properties, not just jdk.module Reviewed-by: coleenp, gziemski, ddmitriev ! src/share/vm/runtime/arguments.cpp ! test/runtime/modules/ModuleOptionsWarn.java Changeset: a5f5a75e03ed Author: hseigel Date: 2016-08-31 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a5f5a75e03ed Merge Changeset: ee428b2585cd Author: mdoerr Date: 2016-08-31 19:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ee428b2585cd 8165014: Unaligned unsafe access should throw InternalError on Solaris Reviewed-by: dholmes, coleenp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp Changeset: e84c337743f5 Author: rehn Date: 2016-09-01 08:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e84c337743f5 8163589: Add back class id intrinsic method for event based tracing Reviewed-by: kvn, mgronlun ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp Changeset: 7286fe7ee4a3 Author: kzhaldyb Date: 2016-08-24 18:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7286fe7ee4a3 8164738: Convert AltHashing_test to GTest Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/classfile/altHashing.hpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/classfile/test_AltHashing.cpp Changeset: aec4f09f3575 Author: kzhaldyb Date: 2016-08-24 19:21 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aec4f09f3575 8164743: Convert TestAsUtf8 to GTest Reviewed-by: dholmes, rprotacio ! src/share/vm/utilities/internalVMTests.cpp ! src/share/vm/utilities/utf8.cpp + test/native/utilities/test_utf8.cpp Changeset: 8e33ab1e0856 Author: mlarsson Date: 2016-08-29 14:11 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8e33ab1e0856 8157948: UL allows same log file with multiple file= Reviewed-by: dholmes, rehn ! src/share/vm/logging/log.cpp ! src/share/vm/logging/logConfiguration.cpp ! src/share/vm/logging/logConfiguration.hpp ! src/share/vm/logging/logFileOutput.cpp ! src/share/vm/logging/logFileOutput.hpp ! test/native/logging/test_logConfiguration.cpp ! test/native/logging/test_logFileOutput.cpp Changeset: a5a5ae802430 Author: kzhaldyb Date: 2016-08-15 13:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a5a5ae802430 8163860: Convert TestOldFreeSpaceCalculation_test to GTest Reviewed-by: iignatyev, dfazunen ! src/share/vm/gc/parallel/psAdaptiveSizePolicy.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/parallel/test_psAdaptiveSizePolicy.cpp Changeset: 5824fc568091 Author: kzhaldyb Date: 2016-08-22 16:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5824fc568091 8164028: Convert TestPredictions_test to GTest Reviewed-by: jwilhelm, dfazunen, ehelin - src/share/vm/gc/g1/g1Predictions.cpp ! src/share/vm/gc/g1/g1Predictions.hpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/g1/test_g1Predictions.cpp Changeset: d4fedc85b584 Author: kzhaldyb Date: 2016-08-29 20:15 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d4fedc85b584 8164230: Convert TestCodeCacheRemSet_test to GTest Reviewed-by: mgerdin, dfazunen ! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp ! src/share/vm/gc/g1/g1CodeCacheRemSet.hpp + src/share/vm/gc/g1/g1CodeRootSetTable.hpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/g1/test_g1CodeCacheRemSet.cpp Changeset: 4a2c2f49eb2c Author: kzhaldyb Date: 2016-09-01 18:15 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4a2c2f49eb2c Merge Changeset: 2cbbeaf227c1 Author: amurillo Date: 2016-09-01 14:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2cbbeaf227c1 Merge ! test/runtime/Unsafe/NestedUnsafe.java Changeset: 94b5513984dd Author: amurillo Date: 2016-09-01 15:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/94b5513984dd Merge Changeset: 3bcb4cd1cf16 Author: coleenp Date: 2016-09-01 18:02 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3bcb4cd1cf16 8165268: [BACKOUT] InstanceKlass::_previous_version_count goes negative Reviewed-by: dcubed ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp - test/runtime/RedefineTests/RedefineCount.java Changeset: ca98af3254cc Author: coleenp Date: 2016-09-02 00:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ca98af3254cc Merge - test/runtime/RedefineTests/RedefineCount.java Changeset: 4dd38e97e16b Author: kzhaldyb Date: 2016-09-01 20:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4dd38e97e16b 8164039: Convert test_memset_with_concurrent_readers to GTest Reviewed-by: iignatyev, kbarrett - src/share/vm/gc/shared/memset_with_concurrent_readers.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/shared/test_memset_with_concurrent_readers.cpp Changeset: 519ab022ab10 Author: kzhaldyb Date: 2016-09-02 01:39 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/519ab022ab10 Merge - src/share/vm/gc/shared/memset_with_concurrent_readers.cpp Changeset: ab25b7b15ed0 Author: rehn Date: 2016-09-02 08:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ab25b7b15ed0 8165215: Setting same UL tag multiple times matches wrong tagset Reviewed-by: mlarsson, rprotacio ! src/share/vm/logging/logTagLevelExpression.cpp ! src/share/vm/logging/logTagLevelExpression.hpp ! test/native/logging/test_logTagLevelExpression.cpp Changeset: 4c39def70c5c Author: tschatzl Date: 2016-09-02 09:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c39def70c5c 8164936: G1 age table printout contains contents from previous GC Summary: Split tenuring threshold update and printing into two separate parts so that they can be used independently. Reviewed-by: jmasa, sangheki ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1DefaultPolicy.cpp ! src/share/vm/gc/g1/g1DefaultPolicy.hpp ! src/share/vm/gc/g1/g1Policy.hpp ! src/share/vm/gc/serial/defNewGeneration.cpp ! src/share/vm/gc/shared/ageTable.cpp ! src/share/vm/gc/shared/ageTable.hpp + test/gc/TestAgeOutput.java Changeset: f722ed07b76b Author: tschatzl Date: 2016-09-02 11:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f722ed07b76b Merge Changeset: fb9963f07435 Author: kzhaldyb Date: 2016-08-30 21:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fb9963f07435 8157468: gc/testlibrary contains a lot of duplicated code Reviewed-by: dfazunen, iignatyev ! test/gc/testlibrary/Helpers.java Changeset: a60eceb45884 Author: mlarsson Date: 2016-08-31 09:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a60eceb45884 8164939: GTest LogDecorations.iso8601_time_test fails on macOS Reviewed-by: sla, dsamersoff ! test/native/logging/test_logDecorations.cpp Changeset: 6ed5d1d6f24c Author: mdoerr Date: 2016-09-05 20:40 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ed5d1d6f24c 8165018: Missing memory barrier for PPC64 in Unsafe_GetObjectVolatile Reviewed-by: kbarrett, dholmes ! src/share/vm/prims/unsafe.cpp Changeset: c54ebf67ef13 Author: dsamersoff Date: 2016-09-06 09:54 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c54ebf67ef13 8165114: stale reference to hotspot test Test8028623.java Summary: Remove Test8028623.java from hotspot/test/TEST.groups Reviewed-by: sla, dholmes Contributed-by: sharath.ballal at oracle.com ! test/TEST.groups Changeset: 14336f84e4cc Author: rprotacio Date: 2016-09-06 16:29 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/14336f84e4cc 8161224: CONSTANT_NameAndType_info permits references to illegal names and descriptors Summary: Enforces proper format checking for NameAndType string content, and that the checking occurs even when not referenced in classfile Reviewed-by: coleenp, hseigel, ddmitriev ! src/share/vm/classfile/classFileParser.cpp Changeset: 176fb0d13598 Author: rprotacio Date: 2016-09-06 22:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/176fb0d13598 Merge ! src/share/vm/classfile/classFileParser.cpp - src/share/vm/gc/g1/g1Predictions.cpp - src/share/vm/gc/shared/memset_with_concurrent_readers.cpp - src/share/vm/gc/shared/referencePendingListLocker.cpp - src/share/vm/gc/shared/referencePendingListLocker.hpp - test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java - test/serviceability/sa/jmap-hashcode/Test8028623.java Changeset: 6d3c44100184 Author: tschatzl Date: 2016-09-07 09:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6d3c44100184 8165292: The gc+task logging is repeated a lot, decreasing the usefulness of -Xlog:gc*=info Summary: Separate number of workers used debugging information from adaptive worker sizing log messages. Reviewed-by: ehelin, sjohanss, jmasa ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/shared/workgroup.hpp + test/gc/TestNumWorkerOutput.java Changeset: 274dc4b09989 Author: hseigel Date: 2016-09-07 07:19 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/274dc4b09989 8058575: IllegalAccessError trying to access package-private class from VM anonymous class Summary: Put anonymous classes in unnamed package into host class's package. Throw exception if host class's package differs from anonymous class. Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/klassFactory.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/reflection.cpp ! test/compiler/jsr292/CallSiteDepContextTest.java + test/runtime/defineAnonClass/DefineAnon.java + test/runtime/defineAnonClass/NestedUnsafe.java + test/runtime/defineAnonClass/NestedUnsafe2.java Changeset: 188971305167 Author: mlarsson Date: 2016-09-07 14:36 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/188971305167 8165226: Bad -Xloggc: arguments crashes the VM Reviewed-by: dsamersoff, sjohanss ! src/share/vm/logging/logConfiguration.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: d3a49c3aa08f Author: mlarsson Date: 2016-09-07 15:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d3a49c3aa08f Merge Changeset: 1d7bc97f0b38 Author: fparain Date: 2016-09-07 12:52 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d7bc97f0b38 8137035: nsk/stress/stack/stack tests got EXCEPTION_STACK_OVERFLOW on Windows 64 bit Reviewed-by: dholmes, dcubed, coleenp ! src/cpu/x86/vm/globals_x86.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/interfaceSupport.hpp Changeset: fb5dcd613881 Author: coleenp Date: 2016-09-07 15:25 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fb5dcd613881 8165246: [REDO] InstanceKlass::_previous_version_count goes negative Summary: make _has_previous_version a boolean that is set to true when previous version of a class is added or during class unloading call to purge_previous_versions Reviewed-by: gtriantafill, dcubed, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp + test/runtime/RedefineTests/RedefinePreviousVersions.java Changeset: b6fea183465f Author: coleenp Date: 2016-09-07 19:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b6fea183465f Merge Changeset: 0fc5c6ca654e Author: dholmes Date: 2016-09-07 16:43 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0fc5c6ca654e 8165153: Crash in rebuild_cpu_to_node_map Summary: use processor_count(), not active_processor_count() to determine physical number of CPUs Reviewed-by: rehn, cjplummer ! src/os/linux/vm/os_linux.cpp Changeset: 5b52605562b0 Author: dholmes Date: 2016-09-07 23:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5b52605562b0 Merge Changeset: b69381e24635 Author: mgerdin Date: 2016-09-02 16:45 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b69381e24635 8161079: Default heap size causes native memory exhaustion on 32 bit Windows Reviewed-by: tschatzl, sjohanss ! src/os/windows/vm/os_windows.cpp Changeset: 94edac068fa7 Author: amurillo Date: 2016-09-10 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/94edac068fa7 Merge - src/share/vm/gc/g1/g1Predictions.cpp - src/share/vm/gc/shared/memset_with_concurrent_readers.cpp - src/share/vm/gc/shared/referencePendingListLocker.cpp - src/share/vm/gc/shared/referencePendingListLocker.hpp - test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java - test/serviceability/sa/jmap-hashcode/Test8028623.java Changeset: dfcbf839e299 Author: lana Date: 2016-09-15 21:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dfcbf839e299 Merge - src/share/vm/gc/g1/g1Predictions.cpp - src/share/vm/gc/shared/memset_with_concurrent_readers.cpp - src/share/vm/gc/shared/referencePendingListLocker.cpp - src/share/vm/gc/shared/referencePendingListLocker.hpp - test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java - test/serviceability/sa/jmap-hashcode/Test8028623.java Changeset: 0d3825c6afdf Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0d3825c6afdf Added tag jdk-9+137 for changeset dfcbf839e299 ! .hgtags Changeset: 294f2c1bdc4b Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/294f2c1bdc4b Merge ! .hgtags ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/utf8.cpp ! test/compiler/jsr292/CallSiteDepContextTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/compiler/unsafe/UnsafeRaw.java ! test/gc/TestSmallHeap.java ! test/gc/arguments/TestTargetSurvivorRatioFlag.java ! test/gc/g1/TestStringDeduplicationAgeThreshold.java ! test/gc/g1/TestStringDeduplicationFullGC.java ! test/gc/g1/TestStringDeduplicationInterned.java ! test/gc/g1/TestStringDeduplicationPrintOptions.java ! test/gc/g1/TestStringDeduplicationTableRehash.java ! test/gc/g1/TestStringDeduplicationTableResize.java ! test/gc/g1/TestStringDeduplicationYoungGC.java ! test/runtime/ErrorHandling/CreateCoredumpOnCrash.java ! test/runtime/ErrorHandling/ProblematicFrameTest.java ! test/runtime/Unsafe/AllocateInstance.java ! test/runtime/Unsafe/AllocateMemory.java ! test/runtime/Unsafe/CopyMemory.java ! test/runtime/Unsafe/DefineClass.java ! test/runtime/Unsafe/FieldOffset.java ! test/runtime/Unsafe/GetField.java ! test/runtime/Unsafe/GetPutAddress.java ! test/runtime/Unsafe/GetPutBoolean.java ! test/runtime/Unsafe/GetPutByte.java ! test/runtime/Unsafe/GetPutChar.java ! test/runtime/Unsafe/GetPutDouble.java ! test/runtime/Unsafe/GetPutFloat.java ! test/runtime/Unsafe/GetPutInt.java ! test/runtime/Unsafe/GetPutLong.java ! test/runtime/Unsafe/GetPutObject.java ! test/runtime/Unsafe/GetPutShort.java ! test/runtime/Unsafe/GetUncompressedObject.java ! test/runtime/Unsafe/PageSize.java ! test/runtime/Unsafe/RangeCheck.java ! test/runtime/Unsafe/Reallocate.java ! test/runtime/Unsafe/SetMemory.java ! test/runtime/Unsafe/ThrowException.java ! test/testlibrary/jittester/Makefile From mandy.chung at oracle.com Fri Sep 23 00:03:32 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:03:32 +0000 Subject: hg: jigsaw/jake/jaxp: 5 new changesets Message-ID: <201609230003.u8N03W0c026025@aojmv0008.oracle.com> Changeset: 3f32c0ee4f8d Author: joehw Date: 2016-09-14 13:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/3f32c0ee4f8d 8165784: Deprecate the internal Catalog API in JDK 9 Reviewed-by: dfuchs, rriggs ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/XMLCatalogResolver.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogManager.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Resolver.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/tools/CatalogResolver.java Changeset: f29a6bd39711 Author: lana Date: 2016-09-15 21:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f29a6bd39711 Merge Changeset: a8d5fe567ae7 Author: joehw Date: 2016-09-19 14:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a8d5fe567ae7 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage Reviewed-by: lancea ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport1.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport2.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport3.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport4.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupport5.java ! test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java Changeset: 6bcbde9a3ef2 Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6bcbde9a3ef2 Added tag jdk-9+137 for changeset a8d5fe567ae7 ! .hgtags Changeset: 34b631df1c90 Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/34b631df1c90 Merge From mandy.chung at oracle.com Fri Sep 23 00:03:36 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:03:36 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201609230003.u8N03agb026081@aojmv0008.oracle.com> Changeset: 7d3a8f52b124 Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7d3a8f52b124 Added tag jdk-9+137 for changeset 297c16d401c5 ! .hgtags Changeset: 0dbac66127c2 Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0dbac66127c2 Merge From mandy.chung at oracle.com Fri Sep 23 00:04:17 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:04:17 +0000 Subject: hg: jigsaw/jake/jdk: 82 new changesets Message-ID: <201609230004.u8N04KO5026245@aojmv0008.oracle.com> Changeset: d6a338c11d88 Author: amlu Date: 2016-09-13 14:55 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6a338c11d88 8165818: Remove tools/pack200/Pack200Props.java from ProblemList Reviewed-by: ksrini ! test/ProblemList.txt Changeset: af17b6bc08dd Author: vtewari Date: 2016-09-13 17:00 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/af17b6bc08dd 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set Reviewed-by: chegar, dsamersoff, msheppar, clanger ! src/java.base/aix/native/libnet/aix_close.c ! src/java.base/linux/native/libnet/linux_close.c ! src/java.base/macosx/native/libnet/bsd_close.c ! src/java.base/solaris/native/libnet/solaris_close.c ! src/java.base/unix/native/libnet/SocketInputStream.c ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/unix/native/libnet/net_util_md.h Changeset: e173966d872b Author: robm Date: 2016-09-13 14:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e173966d872b 6947916: JarURLConnection does not handle useCaches correctly Reviewed-by: chegar ! src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java + test/sun/net/www/protocol/jar/JarURLConnectionUseCaches.java Changeset: 967c9ee04457 Author: sundar Date: 2016-09-13 20:59 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/967c9ee04457 8163320: JAVA_VERSION in release file should come from java.base module Reviewed-by: mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! test/tools/jlink/IntegrationTest.java Changeset: 45a60f458ed8 Author: sdrach Date: 2016-09-13 13:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/45a60f458ed8 8163798: Create a JarFile versionedStream method Reviewed-by: mchung, psandoz, redestad ! src/java.base/share/classes/java/util/jar/JarFile.java + src/java.base/share/classes/jdk/internal/util/jar/VersionedStream.java + test/jdk/internal/util/jar/TestVersionedStream.java Changeset: b988584cda41 Author: skovalev Date: 2016-09-13 15:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b988584cda41 8165870: Fix module dependencies for javax.script/* tests Reviewed-by: sundar Contributed-by: sergei.kovalev at oracle.com ! test/javax/script/ExceptionTest.java ! test/javax/script/JavaScriptScopeTest.java ! test/javax/script/NullUndefinedVarTest.java ! test/javax/script/PluggableContextTest.java ! test/javax/script/Test1.java ! test/javax/script/Test2.java ! test/javax/script/Test3.java ! test/javax/script/Test4.java ! test/javax/script/Test5.java ! test/javax/script/Test6.java ! test/javax/script/Test7.java ! test/javax/script/Test8.java Changeset: 15badd72caae Author: jjiang Date: 2016-09-14 11:06 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/15badd72caae 8077138: Some PKCS11 tests fail because NSS library is not initialized Summary: Re-building NSS libraries with VS2013 to make the new libraries to depend on msvcr120.dll, which is already distributed with JDK 9 Reviewed-by: vinnie Contributed-by: John Jiang ! test/ProblemList.txt ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.chk ! test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.lib ! test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll ! test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.lib ! test/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll ! test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.chk ! test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll ! test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll ! test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/plc4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/plc4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/plds4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/plds4.lib ! test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.chk ! test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll ! test/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll ! test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll ! test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.lib ! test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.chk ! test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nspr4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nspr4.lib ! test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll ! test/sun/security/pkcs11/nss/lib/windows-i586/nss3.lib ! test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll ! test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.chk ! test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll ! test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll ! test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/plc4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/plc4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/plds4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/plds4.lib ! test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.chk ! test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll ! test/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll ! test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll ! test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.lib + test/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz + test/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz.sha256 Changeset: 2db0cfd76f91 Author: stuefe Date: 2016-09-14 14:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2db0cfd76f91 8166012: [linux] Remove remnants of LinuxThreads from Linux attach framework Reviewed-by: dholmes, alanb ! make/mapfiles/libattach/mapfile-linux ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c Changeset: 606ec12670fe Author: dfuchs Date: 2016-09-14 14:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/606ec12670fe 6543126: Level.known can leak memory Summary: Custom level instances will now be released when their defining class loader is no longer referenced. Reviewed-by: plevart, mchung, chegar ! src/java.base/share/classes/module-info.java ! src/java.logging/share/classes/java/util/logging/Level.java ! test/java/util/logging/Level/CustomLevel.java + test/java/util/logging/Level/myresource2.properties Changeset: 6ff142e70383 Author: ksrini Date: 2016-09-14 06:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6ff142e70383 8165524: Better detect JRE that Linux JLI will be using Reviewed-by: ksrini Contributed-by: chris.bensen at oracle.com ! src/java.base/share/native/libjli/java.h ! src/java.base/unix/native/libjli/java_md_common.c ! src/java.base/unix/native/libjli/java_md_solinux.c ! src/java.base/windows/native/libjli/java_md.c ! src/java.base/windows/native/libjli/java_md.h Changeset: 6f220f1f53db Author: jnimeh Date: 2016-09-14 07:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6f220f1f53db 8132926: PKIXParameters built with public key form of TrustAnchor causes NPE during cert path building/validation Summary: Fix cases where non-certificate issuer information may be passed into the OCSPResponse.verify method, thereby causing NPEs to be thrown. Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java + test/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java Changeset: b7f05783d86d Author: darcy Date: 2016-09-14 10:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b7f05783d86d 8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed Reviewed-by: dfuchs ! test/ProblemList.txt Changeset: 0c1c1c466ddc Author: peytoia Date: 2016-09-15 08:18 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c1c1c466ddc 8164791: Update existing test cases of test/java/text/Format. Reviewed-by: okutsu, peytoia Contributed-by: nancy.nigam at oracle.com ! test/java/text/Format/DateFormat/Bug4322313.java ! test/java/text/Format/DateFormat/Bug4736959.java ! test/java/text/Format/DateFormat/Bug4823811.java ! test/java/text/Format/DateFormat/Bug4845901.java ! test/java/text/Format/DateFormat/Bug6609750.java ! test/java/text/Format/DateFormat/Bug6683975.java ! test/java/text/Format/DateFormat/DateFormatRegression.java ! test/java/text/Format/DateFormat/DateFormatRoundTripTest.java ! test/java/text/Format/DateFormat/DateFormatSymbolsCloneTest.java ! test/java/text/Format/DateFormat/NonGregorianFormatTest.java ! test/java/text/Format/DateFormat/bug4358730.java ! test/java/text/Format/MessageFormat/Bug4185816Test.java ! test/java/text/Format/MessageFormat/LargeMessageFormat.java ! test/java/text/Format/MessageFormat/MessageRegression.java ! test/java/text/Format/MessageFormat/MessageTest.java ! test/java/text/Format/NumberFormat/BigDecimalCompatibilityTest.java ! test/java/text/Format/NumberFormat/BigDecimalFormat.java ! test/java/text/Format/NumberFormat/BigDecimalParse.java ! test/java/text/Format/NumberFormat/Bug4208135.java ! test/java/text/Format/NumberFormat/Bug4833877.java ! test/java/text/Format/NumberFormat/Bug4838107.java ! test/java/text/Format/NumberFormat/Bug4944439.java ! test/java/text/Format/NumberFormat/Bug4990596.java ! test/java/text/Format/NumberFormat/Bug6278616.java ! test/java/text/Format/NumberFormat/NumberRegression.java ! test/java/text/Format/NumberFormat/NumberRoundTrip.java ! test/java/text/Format/NumberFormat/NumberTest.java ! test/java/text/Format/NumberFormat/SerializationLoadTest.java ! test/java/text/Format/NumberFormat/SerializationSaveTest.java ! test/java/text/Format/common/FormatIteratorTest.java ! test/java/text/Format/common/PParser.java Changeset: ab540ca487c7 Author: skovalev Date: 2016-09-14 17:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab540ca487c7 8166032: Fix module dependencies for javax.SSL tests Reviewed-by: xuelei, weijun ! test/javax/net/ssl/DTLS/CipherSuite.java ! test/javax/net/ssl/DTLS/DTLSBufferOverflowUnderflowTest.java ! test/javax/net/ssl/DTLS/DTLSDataExchangeTest.java ! test/javax/net/ssl/DTLS/DTLSEnginesClosureTest.java ! test/javax/net/ssl/DTLS/DTLSHandshakeTest.java ! test/javax/net/ssl/DTLS/DTLSHandshakeWithReplicatedPacketsTest.java ! test/javax/net/ssl/DTLS/DTLSIncorrectAppDataTest.java ! test/javax/net/ssl/DTLS/DTLSMFLNTest.java ! test/javax/net/ssl/DTLS/DTLSNotEnabledRC4Test.java ! test/javax/net/ssl/DTLS/DTLSRehandshakeTest.java ! test/javax/net/ssl/DTLS/DTLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/DTLS/DTLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/DTLS/DTLSSequenceNumberTest.java ! test/javax/net/ssl/DTLS/DTLSUnsupportedCiphersTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10BufferOverflowUnderflowTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10DataExchangeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10EnginesClosureTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10HandshakeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10HandshakeWithReplicatedPacketsTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10IncorrectAppDataTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10MFLNTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10NotEnabledRC4Test.java ! test/javax/net/ssl/DTLSv10/DTLSv10RehandshakeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10RehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10RehandshakeWithDataExTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10SequenceNumberTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10UnsupportedCiphersTest.java ! test/javax/net/ssl/TLS/TLSClientPropertyTest.java ! test/javax/net/ssl/TLS/TLSDataExchangeTest.java ! test/javax/net/ssl/TLS/TLSEnginesClosureTest.java ! test/javax/net/ssl/TLS/TLSHandshakeTest.java ! test/javax/net/ssl/TLS/TLSMFLNTest.java ! test/javax/net/ssl/TLS/TLSNotEnabledRC4Test.java ! test/javax/net/ssl/TLS/TLSRehandshakeTest.java ! test/javax/net/ssl/TLS/TLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/TLS/TLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/TLS/TLSUnsupportedCiphersTest.java ! test/javax/net/ssl/TLSv1/TLSDataExchangeTest.java ! test/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java ! test/javax/net/ssl/TLSv1/TLSHandshakeTest.java ! test/javax/net/ssl/TLSv1/TLSMFLNTest.java ! test/javax/net/ssl/TLSv1/TLSNotEnabledRC4Test.java ! test/javax/net/ssl/TLSv1/TLSRehandshakeTest.java ! test/javax/net/ssl/TLSv1/TLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/TLSv1/TLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/TLSv1/TLSUnsupportedCiphersTest.java ! test/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/javax/net/ssl/TLSv11/TLSDataExchangeTest.java ! test/javax/net/ssl/TLSv11/TLSEnginesClosureTest.java ! test/javax/net/ssl/TLSv11/TLSHandshakeTest.java ! test/javax/net/ssl/TLSv11/TLSMFLNTest.java ! test/javax/net/ssl/TLSv11/TLSNotEnabledRC4Test.java ! test/javax/net/ssl/TLSv11/TLSRehandshakeTest.java ! test/javax/net/ssl/TLSv11/TLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/TLSv11/TLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/TLSv11/TLSUnsupportedCiphersTest.java ! test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java ! test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java Changeset: bcd1edb52592 Author: ysuenaga Date: 2016-08-25 12:24 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bcd1edb52592 8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap Reviewed-by: dholmes, sjohanss ! test/sun/tools/jhsdb/BasicLauncherTest.java Changeset: 659f01da7ec0 Author: dsamersoff Date: 2016-08-26 13:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/659f01da7ec0 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. Summary: Update jmap-hashcode/Test8028623.java to use LingeredApp and rename it to jhsdb/HeapDumpTest.java Reviewed-by: dsamersoff, dholmes Contributed-by: sharath.ballal at oracle.com ! test/ProblemList.txt ! test/sun/tools/jhsdb/BasicLauncherTest.java + test/sun/tools/jhsdb/HeapDumpTest.java + test/sun/tools/jhsdb/LingeredAppWithExtendedChars.java Changeset: 6840c15304e7 Author: amurillo Date: 2016-08-26 10:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6840c15304e7 Merge - src/java.base/share/classes/java/lang/reflect/AbstractClassLoaderValue.java - src/java.base/share/classes/java/lang/reflect/ClassLoaderValue.java - src/java.desktop/share/classes/sun/java2d/marlin/ArrayCache.java ! test/ProblemList.txt - test/java/lang/reflect/ClassLoaderValue/Driver.java - test/java/lang/reflect/ClassLoaderValue/java.base/java/lang/reflect/ClassLoaderValueTest.java Changeset: 7ccf4a4c5626 Author: dsamersoff Date: 2016-08-29 11:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ccf4a4c5626 8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools Summary: Cleanup build tag Reviewed-by: iklam, rehn, ctornqvi ! test/ProblemList.txt ! test/sun/tools/jps/TestJpsJar.java Changeset: ad6acec2501b Author: kbarrett Date: 2016-08-30 23:46 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ad6acec2501b 8156500: Move Reference pending list into VM to prevent deadlocks Summary: Move reference pending list and locking into VM Reviewed-by: coleenp, dholmes, dcubed, mchung, plevart Contributed-by: kim.barrett at oracle.com, per.liden at oracle.com ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangRefAccess.java ! src/java.base/share/native/include/jvm.h + src/java.base/share/native/libjava/Reference.c ! test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java Changeset: 8a0a818c3f28 Author: dsamersoff Date: 2016-08-31 11:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a0a818c3f28 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" Summary: Accounted for the new JVMCI related Deoptimization Reasons. Reviewed-by: dsamersoff, sla Contributed-by: jini.george at oracle.com ! test/sun/tools/jhsdb/BasicLauncherTest.java Changeset: 1743b2c51f51 Author: dsamersoff Date: 2016-08-31 12:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1743b2c51f51 8066635: Fix deprecation warnings in java.management module Summary: Fixed deprecation warnings in java.management module Reviewed-by: dholmes Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/java.management/share/classes/com/sun/jmx/interceptor/MBeanServerInterceptor.java ! src/java.management/share/classes/javax/management/MBeanServer.java Changeset: 039d732b80da Author: dsamersoff Date: 2016-08-31 10:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/039d732b80da Merge Changeset: ab687ee6cb9e Author: amurillo Date: 2016-09-01 14:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab687ee6cb9e Merge Changeset: 9fffb37f4af2 Author: amurillo Date: 2016-09-01 15:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9fffb37f4af2 Merge - make/data/cryptopolicy/limited/default_local.policy - make/data/cryptopolicy/limited/exempt_local.policy - make/data/cryptopolicy/unlimited/default_US_export.policy - make/data/cryptopolicy/unlimited/default_local.policy - make/gendata/GendataPolicyJars.gmk ! test/ProblemList.txt - test/sun/security/krb5/auto/unreachable.krb5.conf ! test/sun/tools/jhsdb/BasicLauncherTest.java Changeset: 090cbd92c744 Author: gtriantafill Date: 2016-09-02 11:20 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/090cbd92c744 8165293: Remove ClassesByName2Test.java and RedefineCrossEvent.java from ProblemList.txt Reviewed-by: dcubed ! test/ProblemList.txt Changeset: 03e9322dc0a5 Author: dsamersoff Date: 2016-09-06 09:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03e9322dc0a5 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes Summary: Change /test/lib/share/classes to /test/lib in HeapDumpTest.java Reviewed-by: dsamersoff, ctornqvi Contributed-by: sharath.ballal at oracle.com ! test/sun/tools/jhsdb/HeapDumpTest.java Changeset: 1c9c02f8eaee Author: sspitsyn Date: 2016-09-06 20:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c9c02f8eaee 6822627: NPE at ReferenceTypeImpl.constantPool Summary: fix the NullPointerException bug Reviewed-by: sspitsyn, dsamersoff Contributed-by: egor.ushakov at jetbrains.com ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java + test/com/sun/jdi/ConstantPoolInfoGC.java Changeset: 0f3ebc9f497a Author: sspitsyn Date: 2016-09-07 03:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f3ebc9f497a Merge Changeset: e54f4b7cd337 Author: hseigel Date: 2016-09-07 07:21 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e54f4b7cd337 8058575: IllegalAccessError trying to access package-private class from VM anonymous class Summary: Put anonymous classes in unnamed package into host class's package. Throw exception if host class's package differs from anonymous class. Reviewed-by: coleenp, acorn ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/invoke/VMAnonymousClass.java + test/jdk/internal/misc/Unsafe/TestBadHostClass.java Changeset: 7a118bc21cc9 Author: ddmitriev Date: 2016-09-07 15:34 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7a118bc21cc9 8165513: Quarantine sun/tools/jps/TestJpsJar.java Reviewed-by: dsamersoff ! test/ProblemList.txt Changeset: b5498c3caef2 Author: ddmitriev Date: 2016-09-07 16:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b5498c3caef2 Merge Changeset: 642790bf4c72 Author: vtewari Date: 2016-09-08 15:00 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/642790bf4c72 8152589: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object Reviewed-by: dholmes, dcubed ! test/java/lang/management/ThreadMXBean/Locks.java Changeset: 38f2b4b3828d Author: vtewari Date: 2016-09-08 15:53 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/38f2b4b3828d 8165579: Add missing javadoc information for javax.management.MBeanServer Summary: Added missing @implSpec javadoc information for deserialize api?s Reviewed-by: dfuchs, dholmes Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/javax/management/MBeanServer.java Changeset: 33ce711b8809 Author: amurillo Date: 2016-09-10 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33ce711b8809 Merge ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! test/ProblemList.txt Changeset: 301402d97370 Author: amurillo Date: 2016-09-14 11:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/301402d97370 Merge - src/java.base/share/classes/sun/text/resources/BreakIteratorRulesProvider.java - src/jdk.localedata/share/classes/sun/text/resources/thai_dict ! test/ProblemList.txt - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz.sha256 Changeset: e7de0a5d8396 Author: amurillo Date: 2016-09-14 17:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e7de0a5d8396 Merge Changeset: 2c087b0e4b60 Author: ssahoo Date: 2016-09-15 01:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2c087b0e4b60 8165660: Remove the intermittent keyword from sun/security/krb5/auto/MaxRetries.java Summary: Remove the intermittent keyword Reviewed-by: weijun ! test/sun/security/krb5/auto/MaxRetries.java Changeset: cc4ea9143f34 Author: ssahoo Date: 2016-09-15 01:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cc4ea9143f34 8165825: Remove the intermittent keyword from sun/security/krb5/auto/Unreachable.java Summary: Remove the intermittent keyword Reviewed-by: weijun ! test/sun/security/krb5/auto/Unreachable.java Changeset: 8ec0559cbd7e Author: stuefe Date: 2016-09-13 11:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ec0559cbd7e 8165936: Potential Heap buffer overflow when seaching timezone info files Summary: readdir_r called with too small buffer Reviewed-by: clanger, rriggs, okutsu, naoto ! src/java.base/unix/native/libjava/TimeZone_md.c Changeset: 251c889c4c32 Author: skovalev Date: 2016-09-15 13:03 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/251c889c4c32 8165689: Fix module dependencies for sun/security/pkcs11/* tests Reviewed-by: mullan ! test/sun/security/ec/NSASuiteB/TestSHAwithECDSASignatureOids.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/pkcs11/Cipher/ReinitCipher.java ! test/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java ! test/sun/security/pkcs11/Cipher/TestRSACipher.java ! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java ! test/sun/security/pkcs11/Cipher/TestRawRSACipher.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java ! test/sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java ! test/sun/security/pkcs11/KeyAgreement/TestDH.java ! test/sun/security/pkcs11/KeyAgreement/TestInterop.java ! test/sun/security/pkcs11/KeyAgreement/TestShort.java ! test/sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java ! test/sun/security/pkcs11/KeyGenerator/DESParity.java ! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java ! test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java ! test/sun/security/pkcs11/Mac/MacKAT.java ! test/sun/security/pkcs11/Mac/MacSameTest.java ! test/sun/security/pkcs11/Mac/ReinitMac.java ! test/sun/security/pkcs11/MessageDigest/ByteBuffers.java ! test/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/sun/security/pkcs11/MessageDigest/ReinitDigest.java ! test/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/sun/security/pkcs11/Provider/Absolute.java ! test/sun/security/pkcs11/SampleTest.java ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/LoadKeystore.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/pkcs11/SecureRandom/Basic.java ! test/sun/security/pkcs11/SecureRandom/TestDeserialization.java ! test/sun/security/pkcs11/Serialize/SerializeProvider.java ! test/sun/security/pkcs11/Signature/ByteBuffers.java ! test/sun/security/pkcs11/Signature/ReinitSignature.java ! test/sun/security/pkcs11/Signature/TestDSA.java ! test/sun/security/pkcs11/Signature/TestDSAKeyLength.java ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDH2.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/ec/TestECDSA2.java ! test/sun/security/pkcs11/ec/TestECGenSpec.java ! test/sun/security/pkcs11/ec/TestKeyFactory.java ! test/sun/security/pkcs11/rsa/KeyWrap.java ! test/sun/security/pkcs11/rsa/TestCACerts.java ! test/sun/security/pkcs11/rsa/TestKeyFactory.java ! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/sun/security/pkcs11/rsa/TestSignatures.java ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ! test/sun/security/pkcs11/tls/TestKeyMaterial.java ! test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java ! test/sun/security/pkcs11/tls/TestMasterSecret.java ! test/sun/security/pkcs11/tls/TestPRF.java ! test/sun/security/pkcs11/tls/TestPremaster.java ! test/sun/security/tools/keytool/DefaultSignatureAlgorithm.java ! test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java ! test/sun/security/x509/X509CertImpl/V3Certificate.java Changeset: 109fde5b023a Author: robm Date: 2016-09-15 15:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/109fde5b023a 8165988: Test JarURLConnectionUseCaches.java fails at windows: failed to clean up files after test Reviewed-by: chegar ! test/ProblemList.txt ! test/sun/net/www/protocol/jar/JarURLConnectionUseCaches.java Changeset: d0d2bcebda5b Author: asmotrak Date: 2016-09-15 11:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d0d2bcebda5b 8163924: SSLEngineBadBufferArrayAccess.java fails intermittently with Unrecognized SSL message Reviewed-by: xuelei ! test/sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: aab109341a41 Author: lancea Date: 2016-09-15 14:59 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aab109341a41 8159126: Add test to validate DriverManager.println output when DriverManager is initially loaded Reviewed-by: psandoz, joehw ! test/java/sql/testng/TEST.properties + test/java/sql/testng/test/sql/othervm/DriverManagerInitTests.java Changeset: 8e4d88e06913 Author: rriggs Date: 2016-09-15 16:05 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e4d88e06913 8166148: Fix for JDK-8165936 broke solaris builds Reviewed-by: naoto ! src/java.base/unix/native/libjava/TimeZone_md.c Changeset: 2e1e4c9c8af2 Author: bpb Date: 2016-09-15 13:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2e1e4c9c8af2 8165323: (fs) Files.getFileStore fails with "Mount point not found" in chroot environment Summary: Replace use of FileStore with FileSystem equivalent code. Reviewed-by: redestad ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java Changeset: 3094b847dd63 Author: lana Date: 2016-09-15 21:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3094b847dd63 Merge - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz.sha256 Changeset: 7fe4652bfef2 Author: henryjen Date: 2016-09-16 10:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7fe4652bfef2 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information Reviewed-by: ksrini ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: 28ce5e7cc724 Author: skovalev Date: 2016-09-15 16:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/28ce5e7cc724 8166126: Missing dependecies on jdk.zipfs module for jdk/nio/zipfs/jarfs/JFSTester.java Reviewed-by: alanb ! test/jdk/nio/zipfs/jarfs/JFSTester.java Changeset: a60d6bde3c57 Author: mchung Date: 2016-09-17 16:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a60d6bde3c57 8166237: jdk.jdi missing requires jdk.jdwp.agent Reviewed-by: alanb ! src/jdk.jdi/share/classes/module-info.java Changeset: 29ecac30ecae Author: nishjain Date: 2016-09-18 23:09 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/29ecac30ecae 8165984: ResourceBundle lookup fields not completely thread-safe Reviewed-by: okutsu, naoto ! src/java.base/share/classes/java/util/ListResourceBundle.java ! src/java.base/share/classes/java/util/PropertyResourceBundle.java Changeset: 9c4ef5048871 Author: alexsch Date: 2016-08-31 11:13 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c4ef5048871 8163193: Metal L&F gradient is lighter on HiDPI display after the fix JDK-8143064 Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/sun/swing/CachedPainter.java + test/javax/swing/plaf/metal/MetalGradient/8163193/ButtonGradientTest.java Changeset: e84007be0c2f Author: alexsch Date: 2016-08-31 12:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e84007be0c2f 8153287: [PIT] [hidpi] java/awt/image/multiresolution/MultiresolutionIconTest failed (GTK+ and Nimbus L&F) Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthButtonUI.java Changeset: 8cee7567e4a8 Author: prr Date: 2016-08-31 13:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8cee7567e4a8 8164818: Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails Reviewed-by: serb, psadhukhan ! src/java.desktop/share/native/libfontmanager/HBShaper.c ! src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc ! src/java.desktop/share/native/libfontmanager/hb-jdk.h ! test/java/awt/font/TextLayout/VisibleAdvance.java Changeset: 9808cd1963a5 Author: psadhukhan Date: 2016-09-01 10:21 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9808cd1963a5 8165146: [PIT][TEST_BUG] Doubtful usability of java/awt/print/PrinterJob/TestMediaTraySelection.java Reviewed-by: prr ! test/java/awt/print/PrinterJob/TestMediaTraySelection.java Changeset: 87ca8c53ab98 Author: alexsch Date: 2016-09-01 12:02 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/87ca8c53ab98 8158411: Regression on Swingmark on 8u102 b03 comparing 8u102 b02 on several configs on win32 Reviewed-by: prr, ssadetsky ! src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DesktopProperties.cpp Changeset: 14918637b76e Author: pkbalakr Date: 2016-09-01 16:18 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/14918637b76e 8144735: [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Reviewed-by: psadhukhan, vadim ! src/java.desktop/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! test/javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java Changeset: a0c8eb083f39 Author: prr Date: 2016-09-01 11:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0c8eb083f39 8144015: [PIT] failures of text layout font tests 8144023: [PIT] failure of text measurements in javax/swing/text/html/parser/Parser/6836089/bug6836089.java 8145542: The case failed automatically and thrown java.lang.ArrayIndexOutOfBoundsException exception 8151725: [macosx] ArrayIndexOOB exception when displaying Devanagari text in JEditorPane 8144240: [macosx][PIT] AIOOB in closed/javax/swing/text/GlyphPainter2/6427244/bug6427244.java 8152680: Regression in GlyphVector.getGlyphCharIndex behaviour 8158924: Incorrect i18n text document layout 8041480: ArrayIndexOutOfBoundsException when JTable contains certain string Reviewed-by: serb, srl ! src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/java.desktop/share/native/libfontmanager/HBShaper.c + test/java/awt/font/GlyphVector/GetGlyphCharIndexTest.java + test/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub.java + test/java/awt/font/TextLayout/LigatureCaretTest.java + test/java/awt/font/TextLayout/TestJustification.html + test/java/awt/font/TextLayout/TestJustification.java + test/javax/swing/text/DevanagariEditor.java + test/javax/swing/text/GlyphPainter2/6427244/bug6427244.java Changeset: d63da458491c Author: dmarkov Date: 2016-09-01 22:17 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d63da458491c 8050478: [macosx] Cursor not updating correctly after closing a modal dialog Reviewed-by: serb, alexsch ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/ModalDialogEnterExitEventsTest.java Changeset: 58224e71ea72 Author: prr Date: 2016-09-01 12:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/58224e71ea72 Merge - test/sun/security/krb5/auto/unreachable.krb5.conf Changeset: 91a200506397 Author: ssadetsky Date: 2016-09-02 10:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91a200506397 8164937: Remove code from SortingFocusTraversalPolicy that hacks into non-public Arrays.legacyMergeSort Reviewed-by: alexsch, serb ! src/java.desktop/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! test/java/awt/Focus/SortingFPT/JDK8048887.java Changeset: 03c248ab7484 Author: ssadetsky Date: 2016-09-02 10:36 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03c248ab7484 8163100: [hidpi] Linux: display-wise scaling factor issues Reviewed-by: alexsch, serb ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.c ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c Changeset: eb7d6244528a Author: iris Date: 2016-09-02 10:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb7d6244528a 8165269: (doc) Toolkit.isDynamicLayoutActive(): orphan '0' in first sentence Reviewed-by: alexsch ! src/java.desktop/share/classes/java/awt/Toolkit.java Changeset: 061d7d71f0ff Author: bpb Date: 2016-09-02 11:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/061d7d71f0ff 8154075: [TIFF] AIOOB Exception from TIFFLZWDecompressor Summary: For banded images make sure the step in the horizontal differencing predictor calculations for Deflate and LZW compression is unity (1) instead of the number of samples per pixel. Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDeflateDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFLZWDecompressor.java Changeset: f56da32c7826 Author: lana Date: 2016-09-01 01:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f56da32c7826 8145952: ISO 4217 amendment 161 8164784: ISO 4217 amendment 162 Reviewed-by: naoto Contributed-by: li.jiang at oracle.com ! make/data/currency/CurrencyData.properties ! src/java.base/share/classes/sun/util/resources/CurrencyNames.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_be_BY.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 23f1f1cf47da Author: lana Date: 2016-09-01 08:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23f1f1cf47da 8159408: duplicated data in rmic's javac.properties Reviewed-by: alanb Contributed-by: li.jiang at oracle.com ! src/jdk.rmic/share/classes/sun/tools/javac/resources/javac.properties Changeset: ac7243fd21f6 Author: lana Date: 2016-09-02 21:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ac7243fd21f6 Merge Changeset: 50c1bcbb4097 Author: azvegint Date: 2016-09-06 13:03 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/50c1bcbb4097 8155083: On Windows, usage of USER_ATTENTION_WINDOW depends on state setting order Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/java/awt/Taskbar.java ! src/java.desktop/share/classes/java/awt/peer/TaskbarPeer.java ! src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp Changeset: 475a24023fc5 Author: prr Date: 2016-09-06 08:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/475a24023fc5 8165345: JDK macro definition re-defined by MacOS core framework Reviewed-by: serb ! src/java.desktop/share/native/libfontmanager/HBShaper.c ! src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc ! src/java.desktop/share/native/libfontmanager/hb-jdk.h Changeset: 8c1bfb84c1a1 Author: prr Date: 2016-09-06 11:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c1bfb84c1a1 8164899: Provide package access to setComponentMixingCutoutShape Reviewed-by: serb ! src/java.desktop/share/classes/com/sun/awt/AWTUtilities.java ! src/java.desktop/share/classes/java/awt/Component.java Changeset: e30c36db6c44 Author: ant Date: 2016-09-08 19:25 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e30c36db6c44 8160570: [macosx] modal dialog can skip the activation/focus events Reviewed-by: serb, ssadetsky ! src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java Changeset: bae74ee4abe6 Author: aniyogi Date: 2016-09-09 11:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bae74ee4abe6 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java Reviewed-by: alexsch, rchamyal ! test/javax/swing/JColorChooser/Test7194184.java Changeset: 0917d2fc19d9 Author: pkbalakr Date: 2016-09-09 13:15 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0917d2fc19d9 8009477: PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick Reviewed-by: alexsch, aghaisas Contributed-by: prem.balakrishnan at oracle.com ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/SliderTick/SliderTickTest.java Changeset: 7df406400153 Author: ssadetsky Date: 2016-09-09 16:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7df406400153 8160054: The FileChooser didn't displayed large font with GTK LAF option. Reviewed-by: alexsch, serb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java Changeset: 755dd8ef4ed0 Author: psadhukhan Date: 2016-09-10 14:50 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/755dd8ef4ed0 4885375: Page Ranges 'To Page' field must be populated based on Pageable Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java + test/java/awt/print/PrinterJob/PrintDlgPageable.java Changeset: 25c0c37cd66a Author: jdv Date: 2016-09-12 12:07 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/25c0c37cd66a 4924727: reader.abort() method does not work when called inside imageStarted for PNG Reviewed-by: prr, serb, bpb ! make/mapfiles/libjpeg/mapfile-vers ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageReader.java ! src/java.desktop/share/native/libjavajpeg/imageioJPEG.c + test/javax/imageio/ReadAbortTest.java Changeset: ec667ddda43a Author: ddehaven Date: 2016-09-12 15:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ec667ddda43a Merge - src/java.base/share/classes/sun/text/resources/BreakIteratorRulesProvider.java - src/jdk.localedata/share/classes/sun/text/resources/thai_dict ! test/sun/text/resources/LocaleDataTest.java Changeset: fd45ca110802 Author: psadhukhan Date: 2016-09-13 13:40 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd45ca110802 7064425: PageFormat Dialog has no owner window to reactivate 6948907: sun.print.DialogOwner does not support Dialogs as DialogOwner Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/print/DialogOwner.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java + test/java/awt/print/PrinterJob/TestPageDlgFrameAssociation.java + test/java/awt/print/PrinterJob/TestPrintDlgFrameAssociation.java Changeset: e1d133b6bce5 Author: prr Date: 2016-09-14 15:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e1d133b6bce5 8166068: test/java/awt/font/GlyphVector/GetGlyphCharIndexTest.java does not compile Reviewed-by: ddehaven, yan ! test/java/awt/font/GlyphVector/GetGlyphCharIndexTest.java Changeset: e72df94364e3 Author: ddehaven Date: 2016-09-19 10:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e72df94364e3 Merge - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz - test/sun/security/pkcs11/nss/src/nss-3.16_nspr-4.10_src.tar.gz.sha256 Changeset: cf207e188ae2 Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cf207e188ae2 Added tag jdk-9+137 for changeset e72df94364e3 ! .hgtags Changeset: a354dc66ea68 Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a354dc66ea68 Merge ! .hgtags ! make/mapfiles/libjava/mapfile-vers - src/java.base/share/classes/java/lang/module/Dependence.java ! src/java.base/share/classes/java/nio/Bits.java - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/libjli/java.h ! src/java.base/windows/native/libjli/java_md.h ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.logging/share/classes/java/util/logging/Level.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! test/ProblemList.txt ! test/java/lang/Class/GetModuleTest.java - test/java/lang/Class/getResource/src/m3/module-info.java - test/java/lang/Class/getResource/src/m3/p3/Main.java - test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java - test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java ! test/java/lang/invoke/VMAnonymousClass.java - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java - test/java/lang/reflect/Module/access/src/target/p/Exported.java - test/java/lang/reflect/Module/access/src/target/p/Helper.java - test/java/lang/reflect/Module/access/src/target/q/Internal.java - test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/MyResources_ja_JP.properties - test/java/util/ServiceLoader/modules/MiscTests.java - test/java/util/ServiceLoader/modules/ServicesTest.java - test/java/util/ServiceLoader/modules/src/bananascript/module-info.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/src/test/module-info.java - test/java/util/ServiceLoader/modules/src/test/test/Main.java ! test/javax/net/ssl/DTLS/CipherSuite.java ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Provider/Absolute.java ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java ! test/sun/text/resources/LocaleDataTest.java ! test/sun/tools/jps/TestJpsJar.java ! test/tools/jlink/IntegrationTest.java Changeset: b230b5019a95 Author: mchung Date: 2016-09-22 17:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b230b5019a95 Fix tests to export private for use of setAccessible ! test/com/sun/jdi/ConstantPoolInfoGC.java ! test/javax/net/ssl/DTLS/DTLSBufferOverflowUnderflowTest.java ! test/javax/net/ssl/DTLS/DTLSDataExchangeTest.java ! test/javax/net/ssl/DTLS/DTLSEnginesClosureTest.java ! test/javax/net/ssl/DTLS/DTLSHandshakeTest.java ! test/javax/net/ssl/DTLS/DTLSHandshakeWithReplicatedPacketsTest.java ! test/javax/net/ssl/DTLS/DTLSIncorrectAppDataTest.java ! test/javax/net/ssl/DTLS/DTLSMFLNTest.java ! test/javax/net/ssl/DTLS/DTLSNotEnabledRC4Test.java ! test/javax/net/ssl/DTLS/DTLSRehandshakeTest.java ! test/javax/net/ssl/DTLS/DTLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/DTLS/DTLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/DTLS/DTLSSequenceNumberTest.java ! test/javax/net/ssl/DTLS/DTLSUnsupportedCiphersTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10BufferOverflowUnderflowTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10DataExchangeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10EnginesClosureTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10HandshakeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10HandshakeWithReplicatedPacketsTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10IncorrectAppDataTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10MFLNTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10NotEnabledRC4Test.java ! test/javax/net/ssl/DTLSv10/DTLSv10RehandshakeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10RehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10RehandshakeWithDataExTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10SequenceNumberTest.java ! test/javax/net/ssl/DTLSv10/DTLSv10UnsupportedCiphersTest.java ! test/javax/net/ssl/TLS/TLSClientPropertyTest.java ! test/javax/net/ssl/TLS/TLSDataExchangeTest.java ! test/javax/net/ssl/TLS/TLSEnginesClosureTest.java ! test/javax/net/ssl/TLS/TLSHandshakeTest.java ! test/javax/net/ssl/TLS/TLSMFLNTest.java ! test/javax/net/ssl/TLS/TLSNotEnabledRC4Test.java ! test/javax/net/ssl/TLS/TLSRehandshakeTest.java ! test/javax/net/ssl/TLS/TLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/TLS/TLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/TLS/TLSUnsupportedCiphersTest.java ! test/javax/net/ssl/TLSv1/TLSDataExchangeTest.java ! test/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java ! test/javax/net/ssl/TLSv1/TLSHandshakeTest.java ! test/javax/net/ssl/TLSv1/TLSMFLNTest.java ! test/javax/net/ssl/TLSv1/TLSNotEnabledRC4Test.java ! test/javax/net/ssl/TLSv1/TLSRehandshakeTest.java ! test/javax/net/ssl/TLSv1/TLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/TLSv1/TLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/TLSv1/TLSUnsupportedCiphersTest.java ! test/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/javax/net/ssl/TLSv11/TLSDataExchangeTest.java ! test/javax/net/ssl/TLSv11/TLSEnginesClosureTest.java ! test/javax/net/ssl/TLSv11/TLSHandshakeTest.java ! test/javax/net/ssl/TLSv11/TLSMFLNTest.java ! test/javax/net/ssl/TLSv11/TLSNotEnabledRC4Test.java ! test/javax/net/ssl/TLSv11/TLSRehandshakeTest.java ! test/javax/net/ssl/TLSv11/TLSRehandshakeWithCipherChangeTest.java ! test/javax/net/ssl/TLSv11/TLSRehandshakeWithDataExTest.java ! test/javax/net/ssl/TLSv11/TLSUnsupportedCiphersTest.java From mandy.chung at oracle.com Fri Sep 23 00:04:35 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:04:35 +0000 Subject: hg: jigsaw/jake/langtools: 8 new changesets Message-ID: <201609230004.u8N04ZBl026416@aojmv0008.oracle.com> Changeset: 31c022a17639 Author: sadayapalam Date: 2016-09-13 19:32 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/31c022a17639 8138667: java.lang.IllegalAccessError: tried to access method (for a protected method) Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/methodReference/ProtectedInaccessibleMethodRefTest.java + test/tools/javac/lambda/methodReference/pack/SuperClass.java Changeset: 6e028413ea08 Author: sadayapalam Date: 2016-09-14 20:00 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6e028413ea08 8160699: java.lang.VerifyError: Inconsistent stackmap frames at branch target Summary: Ensure out of scope locals are not treated as being alive Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/SwitchExitStateTest.java Changeset: 013e3e406ddf Author: lana Date: 2016-09-15 21:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/013e3e406ddf Merge Changeset: fc0a38e90a7c Author: dlsmith Date: 2016-09-16 11:58 -0600 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fc0a38e90a7c 8138822: Source version error missing version number Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/tools/javac/annotations/repeatingAnnotations/WrongVersion.java + test/tools/javac/annotations/repeatingAnnotations/WrongVersion6.out + test/tools/javac/annotations/repeatingAnnotations/WrongVersion7.out Changeset: 6077dc32728a Author: bpatel Date: 2016-09-16 12:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6077dc32728a 8166176: module search generates URLs with extra '/' Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js Changeset: dd56c243c199 Author: sadayapalam Date: 2016-09-19 05:31 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dd56c243c199 8164742: ServiceConfigurationError on invoke of getServiceLoader method of StandardJavaFileManager Reviewed-by: jlahoda ! make/tools/crules/MutableFieldsAnalyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java + test/tools/javac/modules/FileManagerGetServiceLoaderTest.java Changeset: 9f61004270d8 Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f61004270d8 Added tag jdk-9+137 for changeset dd56c243c199 ! .hgtags Changeset: 8684b932d0cf Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8684b932d0cf Merge ! .hgtags ! make/tools/crules/MutableFieldsAnalyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java - test/tools/javac/diags/examples/DuplicateExports/exported/Class.java - test/tools/javac/diags/examples/DuplicateExports/module-info.java - test/tools/javac/modules/RequiresPublicTest.java - test/tools/jdeps/modules/src/m1/module-info.java - test/tools/jdeps/modules/src/m1/p1/Goo.java - test/tools/jdeps/modules/src/m1/p1/Lib.java - test/tools/jdeps/modules/src/m1/p1/S.java - test/tools/jdeps/modules/src/m1/p1/internal/Impl.java - test/tools/jdeps/modules/src/m2/module-info.java - test/tools/jdeps/modules/src/m2/p2/Bar.java - test/tools/jdeps/modules/src/m2/p2/internal/T2.java - test/tools/jdeps/modules/src/m3/module-info.java - test/tools/jdeps/modules/src/m3/p3/Foo.java - test/tools/jdeps/modules/src/m3/p3/Main.java - test/tools/jdeps/modules/src/m6/module-info.java - test/tools/jdeps/modules/src/m6/p6/indirect/UnsafeRef.java - test/tools/jdeps/modules/src/m6/p6/safe/Lib.java - test/tools/jdeps/modules/src/m7/module-info.java - test/tools/jdeps/modules/src/m7/p7/Main.java From mandy.chung at oracle.com Fri Sep 23 00:04:38 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 23 Sep 2016 00:04:38 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201609230004.u8N04dVZ026502@aojmv0008.oracle.com> Changeset: d4b2baada058 Author: lana Date: 2016-09-22 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d4b2baada058 Added tag jdk-9+137 for changeset 17ed43add2f9 ! .hgtags Changeset: 88688bc37dfc Author: mchung Date: 2016-09-22 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/88688bc37dfc Merge ! .hgtags From greggwon at cox.net Mon Sep 26 03:50:03 2016 From: greggwon at cox.net (GREGG WONDERLY) Date: Sun, 25 Sep 2016 22:50:03 -0500 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> Message-ID: <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count. I understand that the JDK itself is not deployed with a security manager impl in most cases, and thus there would be no access context for the security manager to be used against. What?s odd, is that you are still trying to block access to reflective access to the ?open JDK?. If it?s really open and it?s really something that the community contributes to, why do we need to block access, hide details and otherwise obfuscate access details? Modularization should just be about separating pieces not needed should it not? Why has this degenerated into such a huge bit of access restriction too? Could people who think that modularity should solve these problems and the security manager not be part of the solution please provide some details about how security is the modularization mechanisms responsibility and not the security managers? For deployment, I?ve always used the security manager to limit/control access when I take some 3rd party code/jar and deploy it into a production environment. That helps me restrict its access to resources in a manageable and maintainable way. What I see happening, is that this single issue of ?access? to pieces of software, from other pieces of software is degenerating into huge amounts of complexity and specification and release control, which isn?t really what makes ?open software? work together. The conversation below, I feel, illustrates how big of a freight train of focus this single issue has degenerated into. David tries hard here to be brief it seems, but arguably, there is so many specifics of variability and lack of ability to fully specify detail, that it?s hard to imagine, at least for me, how this path can result in anything more than ?pseudo science? of specification and detail which will then result in a really hard to manage path forward, because there will still be no clean, clear and fully specified solution. This is stuff that?s hard to detail, and even harder to managed with a ?fixed? specification. In the end, I am still concerned that what is happening, is something very specific to what the JDK team feels they need to do, to keep people out of private implementation. It seems like that would best be done with a runtime security implementation, specific to the JVM, instead of a modularization specification which provides so many restrictions for open software systems that we end up only being able to say ?all? or ?nothing? is what we need to support. The JDK needs more than that, but it?s only because developers at Oracle are being obstructionist to use of software that they don?t feel should be used. For a long time, I have had conversations with a lot of different Sun, and now Oracle employees. I think that they all want to enable great things to happen with the Java platform. But the attempts at perfection and control involved in many of the JSRs (NIO2?s failure to provide a working, dependable filesystem observer for all platforms for example) which have resulted in only partial improvements and in many cases reduced penetration (java.util.logging still doesn?t get improvements to align it?s apis better with varargs and more brief API designs) into new projects demonstrates for me that there is not always the right focus on what needs to happen in actuality, and instead a shotgun approach that destroys a lot of opportunity and splatters things around making them visible without great, ongoing improvement. How can we make sure that this work doesn?t just result in a complete melt down of open software, causing huge migration to Harmony or Wine or some other Java platform abandonment? I know that seems far fetched, but software developers are never really interested in friction, going slower, or working harder to deal with new features. Gregg > On Sep 21, 2016, at 11:39 AM, David M. Lloyd wrote: > > In our internal discussion of the proposal for #ReflectiveAccessToNonExportedTypes, we discussed the ins and outs of various behaviors and have come up with a few ideas or starting points for solutions that we think would be more workable in conjunction with existing middleware (ours and others'). > > For reasons previously explained, we do not think that weak modules are a good way forward; I won't go into that again here. But the logical re-starting point is: If not weak modules, then what? > > I will boil it down to a few basic requirements that we have established. This list is probably non-exhaustive but hopefully complete enough to go on for now: > > ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public reflection only. > ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public or private reflection only. > ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public reflection and compilation/linkage (i.e. it's an export by today's terminology). > ? A module definition must be able to establish that a dependent has (or all modules have) access to one or more (or all) packages for public or private reflection and compilation/linkage (i.e. it's a "private" export by today's terminology). > ? As today, any packages not declared in one or more of the above categories is inaccessible outside of the module in any way (note that as I showed previously we have also concluded that it should continue to be impossible to export a package for compilation/linkage without public reflection, as we have not discovered any use for such a mode). > > More generally: > > ? The syntax for all of the above has no particular constraint (in fact I will try to actively avoid touching what could be a very bikeshedding-rich discussion), except that it should not be construable as being pejorative against the usage of reflective frameworks; rather, it should be clear what level of trust is being established without raising undue warning. > ? Applications should not need gratuitous amounts of declarations in their module(s) in order to utilize frameworks. > ? As previously established, it should not be possible for one declaration to reduce the scope of access of another declaration in a module definition. > ? Access to a module (for reflective purposes only) must not cause conflicts if multiple such modules which contain identical packages are accessible to a single consumer; in other words, reflection-only access into non-dependency modules is not bound by duplicate package restrictions as long as each package is unique per class loader, as per the current (Java 8) class loader rules. > > The above cover the useful access modes that we have identified. This is _nearly_ adequate to cover the use cases that we are currently concerned about; for example, I could export all packages for public reflection only to a specific framework, if only I know the module name of the implementation. > > Unfortunately, this does not work well in the case where a module may consume a framework whose specification is separate from the implementation. An application module may need to use (say) EJB and JPA; there is presently no clean way to do so without either (a) relying on a container environment to rewrite the descriptor or (b) opening up the module and defeating the security mechanism (e.g. "weak"). Without either of these workarounds, the application developer must have a good deal of knowledge about what modules provide what services within a framework-rich environment, possibly resulting in a very verbose (and error-prone) descriptor; none of these options is really satisfactory. > > Thus, apart from the option of redesigning (to an extent) the security mechanism (thereby eliminating the need to seal off access to public reflection, which is definitely still an attractive option for various reasons from our perspective, but which is also a very different discussion), we need some sort of mechanism which decouples the literal dependency system from access permission (much like uses/provides does). > > For example if I could declare that my module uses "javax.ejb", and, in so doing, automatically grants public and private reflective access to the module that provides that service, this would be a good outcome. A module which answers to that service name could be responsible for reflective access to the application module, providing that information privately to any other framework modules which require it. > > The migration story looks much better in this light: module descriptors still can be quite terse and specific. Applications which use reflective frameworks do not need gratuitous exports; in fact it's much more fluid for a user to say "I require these helper libraries; I use EJB; that's it" which means they don't have to worry about the details of whatever particular environment they run in. This also has the advantage of allowing new Java 9-generation specifications to stipulate standard service names for each specification (e.g. "javax.ejb", "javax.cdi", that sort of thing). > > While this doesn't cover 100% of our remaining issues with Jigsaw (of course; we'll all continue moving through the issues list as we have been to get us there), meeting these requirements would go a long way towards at least having a reflection story that is more practical for present-day frameworks to move forward with. So the last requirement would be: > > ? A module definition must be able to establish that an "indirect" dependency exists on an otherwise unknown module providing a capability, wherein that module may require public or public+private reflection access to some or all packages without compile/link access. This could possibly exist in conjunction with, or as an evolution of, the current services mechanism, however a complicating factor is that the current mechanism is based specifically on types, whereas a purely symbolic relationship might be better for this purpose (this is not a requirement though if it can be made to work as-is). Note that any symbolic relationship system would need some in-code discovery mechanism such that consumers of the capability are made available to the provider and/or vice-versa, in order to make practical use of the relationship. > > The following example syntax is meant to be unambiguous and illustrative; no specific attempt is made to reuse existing keywords (for example), or even to imply an endorsement of the current descriptor mechanism at all, but to clarify how this might look in practice and provide a practical application of the ideas herein. > > Example 1: A contrived provider of the fictional framework "javax.fictional.orm" illustrating provides/uses-based access granting > > module org.foo.orm.provider { > > // Require a module dependency, and give it private reflection access to everything > requires org.apache.commons.beanutils with private reflection on *; > > // Require a module dependency with no reflection > requires org.apache.commons.logging; > > // Provide the framework > provides javax.fictional.orm.ORM > using private reflection > with org.foo.orm.provider.ORMImpl1, > org.foo.orm.provider.ORMImpl2; > } > > Example 2: A contrived consumer of #1 > > module com.mycompany.application { > uses javax.fictional.orm.ORM; // automatically gives private reflection > } > > Example 3: Grant reflection access to a couple of packages to a named non-dependency module > > module com.mycompany.application { > grant public reflection on > com.mycompay.application.package1, > com.mycompay.application.package2 > to org.foo.framework; > } > > Example 4: Behave like Java 8 > > module com.mycompany.application { > grant private reflection on * to *; > } > > Example 5: Behave like Java 8, but restrict private access without requiring a security manager > > module com.mycompany.application { > grant public reflection on * to *; > } > > Example 6: An example of using CDI and EJB with symbolic capabilities > > module com.mycompany.application { > uses capability javax.ejb, javax.cdi > } > > Example 7: An example of providing EJB with symbolic capabilities > > module org.foo.ejb.provider { > [...] > provides capability javax.ejb using private reflection; > } > > > -- > - DML From Alan.Bateman at oracle.com Mon Sep 26 08:19:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 09:19:33 +0100 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> Message-ID: <2855a6fe-d758-ce22-eb2f-bf167d1b5986@oracle.com> On 26/09/2016 04:50, GREGG WONDERLY wrote: > I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count. I understand that the JDK itself is not deployed with a security manager impl in most cases, and thus there would be no access context for the security manager to be used against. What?s odd, is that you are still trying to block access to reflective access to the ?open JDK?. If it?s really open and it?s really something that the community contributes to, why do we need to block access, hide details and otherwise obfuscate access details? Modularization should just be about separating pieces not needed should it not? Why has this degenerated into such a huge bit of access restriction too? When you see "access control" in mails on this list then think the access control specified by the Java Language Specification and Java Virtual Machine Specification. It's nothing to do with the legacy security manager mechanism. As regards core reflection then keep in mind that it has always been specified to do the same access checks as the Java Language and VM. It should not be a surprise if you get IllegalAccessException when attempting to access something when the equivalent Java code does not compile or where the equivalent bytecode would fail with IllegalAccessError. > : > > For a long time, I have had conversations with a lot of different Sun, and now Oracle employees. I think that they all want to enable great things to happen with the Java platform. But the attempts at perfection and control involved in many of the JSRs (NIO2?s failure to provide a working, dependable filesystem observer for all platforms for example) I can't tell what you mean here but if you are looking to interpose on file system operations then that support has been there since Java SE 7. If you mean the Watcher API then there is a platform independent implementation in OpenJDK. In any case, the nio-dev list is the place for to being gripes in this area. > which have resulted in only partial improvements and in many cases reduced penetration (java.util.logging still doesn?t get improvements to align it?s apis better with varargs and more brief API designs) It's not clear to me that it's worth doing a lot of the j.u.logging API but keep in mind that there were updates to modernize it a bit in Java SE 8 (Logger has methods that take a message Supplier for example). Also with JEP 264 then you have a way to plugin in your preferred logging framework to consume logging from the platform. The core-libs-dev list is the place to bring gripes or issues on logging. -Alan From Alan.Bateman at oracle.com Mon Sep 26 08:25:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 09:25:46 +0100 Subject: Class names in java.lang.Module In-Reply-To: <8e3a4cd5-e3d7-b749-0bb5-e564a048ba62@redhat.com> References: <9F4B8C0F-B90E-462B-8309-D959BFAEC5BB@univ-mlv.fr> <8e3a4cd5-e3d7-b749-0bb5-e564a048ba62@redhat.com> Message-ID: <577a89fd-d798-d69d-ca47-50b998b0eb69@oracle.com> On 21/09/2016 12:45, Richard Opalka wrote: > +1 > > I'd also propose FindException -> ModuleNotFoundException Keep in mind that find/findAll throw FindException for a slew of reasons, the "not found" case is just one. -Alan. From njbartlett at gmail.com Mon Sep 26 09:25:44 2016 From: njbartlett at gmail.com (Neil Bartlett) Date: Mon, 26 Sep 2016 10:25:44 +0100 Subject: Class names in java.lang.Module In-Reply-To: References: Message-ID: <6F44DA21-9717-442A-AD64-DB9657B142EC@gmail.com> Module is already in the name: ?java.lang.module.Configuration?. Wouldn?t ?java.lang.module.ModuleConfiguration? look really odd? Neil > On 21 Sep 2016, at 16:18, Stephen Colebourne wrote: > > I had the same thought while watching the slides. Configuration is > certainly a class name that exists other places, and would benefit > from being ModuleConfiguration. Layer is less common, so not worried > so much. Exceptions with "Module" in the name like > ModuleNotFoundException would also be clearer. > Stephen > > On 21 September 2016 at 03:36, Kasper Nielsen wrote: >> Hi, >> >> I was wondering if there are any reasons for why these 3 classes in >> java.lang.Module >> >> Configuration >> FindException >> ResolutionException >> >> Does not include the name Module? >> I especially am not to fond of the very generic Configuration name in my >> source code would much prefer something like ModuleConfiguration. >> >> Best >> Kasper From adinn at redhat.com Mon Sep 26 09:28:54 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 26 Sep 2016 10:28:54 +0100 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: <2855a6fe-d758-ce22-eb2f-bf167d1b5986@oracle.com> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> <2855a6fe-d758-ce22-eb2f-bf167d1b5986@oracle.com> Message-ID: <3095e9ec-558e-d6ab-74d8-59c9048e9df7@redhat.com> On 26/09/16 09:19, Alan Bateman wrote: > On 26/09/2016 04:50, GREGG WONDERLY wrote: > >> I still, like others seem to, find it amazingly odd, that the security >> manager, existing basis for access control is not still what would >> count. I understand that the JDK itself is not deployed with a >> security manager impl in most cases, and thus there would be no access >> context for the security manager to be used against. What?s odd, is >> that you are still trying to block access to reflective access to the >> ?open JDK?. If it?s really open and it?s really something that the >> community contributes to, why do we need to block access, hide details >> and otherwise obfuscate access details? Modularization should just be >> about separating pieces not needed should it not? Why has this >> degenerated into such a huge bit of access restriction too? > When you see "access control" in mails on this list then think the > access control specified by the Java Language Specification and Java > Virtual Machine Specification. It's nothing to do with the legacy > security manager mechanism. I'm sorry, Alan ,but I think that is disingenuous. When we see "access control" on this list all of us really ought to bear in mind what have been the de facto access control mechanisms for many JDK releases and many more years. There are two such levels of control and one of them is the security manager. That's a historic fact. Your statement above reads very much like an attempt to hijack the discourse by hijacking terminology so it addresses the topic you want to talk about (there is no imputation of such a motive here -- I'm just reporting how it looks). Greg has asked you to talk about the wider controls and precisely why you don't want to consider security manager control. I am sure there are good reasons for that. Could you not explain them? > As regards core reflection then keep in mind that it has always been > specified to do the same access checks as the Java Language and VM. It > should not be a surprise if you get IllegalAccessException when > attempting to access something when the equivalent Java code does not > compile or where the equivalent bytecode would fail with > IllegalAccessError. Has this really been the specification? If so then many years of differing practice as regards the implementation have made that 'putative' specification worth less than the paper it is (probably no longer :-) printed on. In which case I don't think it is a legitimate gambit to dismiss the consequences of moving to enforce such a contract without fairly assessing the potential damage that such a move might wreak and squarely explaining the countervailing benefits that doing so would offer in compensation. Personally, I can see why a move to limit accessibility is attractive for a variety of purposes -- mostly to do with consequential opportunities in the way the JVM and JDK runtime can be developed for future-proofing the managed runtime that Java and other JVM languages, current or future, ought to profit from. Of course, I see those reasons because that's what I work on but even then I don't really know what the rest of the JVM devs think and I would be happy to hear other reasons. The problem is that no one on this list has really stated any broader reasons for limiting the current state of reflective access beyond pushing the line that restricting access is a self-evident good because it improves security and expresses programmer intentions more clearly. That position is clearly in complete opposition to the views of a large swathe of Java developers who feel that those presumed benefits are a sideshow to the much more important (in their eyes) need to retain the ability to dynamically wire up linkage. I don't doubt that this latter capability is /critical/ to a lot of long-term investment in Java that underpins most of the commercial use of the language. I don't blame those who made such an investment for i) wanting compelling reasons for accepting the restrictions you are proposing and ii) (with or without such compelling reasons) requiring that you either provide some means of retaining in part or in whole the status quo. If you don't address these points then I don't see that you can expect anything other than a wholesale rejection of Jigsaw. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From scolebourne at joda.org Mon Sep 26 10:11:58 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 26 Sep 2016 11:11:58 +0100 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> Message-ID: Having read this proposal a number of times, and considering how the talks explained things at JavaOne, I have come to the conclusion that this proposal is too complex. FWIW, I like the idea that a module should be able to declare that it needs reflective access from its users, however given that the proposal is what results from the idea, it doesn't seem as appealing as it should. The reason why I put forward the exports/exposes approach [1] is that it keeps the questions that must be asked when creating a module simple: - what do I depend on publicly (requires) - what do I publish publicly (exports) - what do I publish privately (exposes) >From a security point of view it also seems that it should be the responsibility of a module to allow the publishing of its private details, and simply depending on another module seems very minimal (and easy to miss) as a mechanism to allow that extra permission. Stephen [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009370.html On 21 September 2016 at 17:39, David M. Lloyd wrote: > In our internal discussion of the proposal for > #ReflectiveAccessToNonExportedTypes, we discussed the ins and outs of > various behaviors and have come up with a few ideas or starting points for > solutions that we think would be more workable in conjunction with existing > middleware (ours and others'). > > For reasons previously explained, we do not think that weak modules are a > good way forward; I won't go into that again here. But the logical > re-starting point is: If not weak modules, then what? > > I will boil it down to a few basic requirements that we have established. > This list is probably non-exhaustive but hopefully complete enough to go on > for now: > > ? A module definition must be able to establish that a dependent has (or all > modules have) access to one or more (or all) packages for public reflection > only. > ? A module definition must be able to establish that a dependent has (or all > modules have) access to one or more (or all) packages for public or private > reflection only. > ? A module definition must be able to establish that a dependent has (or all > modules have) access to one or more (or all) packages for public reflection > and compilation/linkage (i.e. it's an export by today's terminology). > ? A module definition must be able to establish that a dependent has (or all > modules have) access to one or more (or all) packages for public or private > reflection and compilation/linkage (i.e. it's a "private" export by today's > terminology). > ? As today, any packages not declared in one or more of the above categories > is inaccessible outside of the module in any way (note that as I showed > previously we have also concluded that it should continue to be impossible > to export a package for compilation/linkage without public reflection, as we > have not discovered any use for such a mode). > > More generally: > > ? The syntax for all of the above has no particular constraint (in fact I > will try to actively avoid touching what could be a very bikeshedding-rich > discussion), except that it should not be construable as being pejorative > against the usage of reflective frameworks; rather, it should be clear what > level of trust is being established without raising undue warning. > ? Applications should not need gratuitous amounts of declarations in their > module(s) in order to utilize frameworks. > ? As previously established, it should not be possible for one declaration > to reduce the scope of access of another declaration in a module definition. > ? Access to a module (for reflective purposes only) must not cause conflicts > if multiple such modules which contain identical packages are accessible to > a single consumer; in other words, reflection-only access into > non-dependency modules is not bound by duplicate package restrictions as > long as each package is unique per class loader, as per the current (Java 8) > class loader rules. > > The above cover the useful access modes that we have identified. This is > _nearly_ adequate to cover the use cases that we are currently concerned > about; for example, I could export all packages for public reflection only > to a specific framework, if only I know the module name of the > implementation. > > Unfortunately, this does not work well in the case where a module may > consume a framework whose specification is separate from the implementation. > An application module may need to use (say) EJB and JPA; there is presently > no clean way to do so without either (a) relying on a container environment > to rewrite the descriptor or (b) opening up the module and defeating the > security mechanism (e.g. "weak"). Without either of these workarounds, the > application developer must have a good deal of knowledge about what modules > provide what services within a framework-rich environment, possibly > resulting in a very verbose (and error-prone) descriptor; none of these > options is really satisfactory. > > Thus, apart from the option of redesigning (to an extent) the security > mechanism (thereby eliminating the need to seal off access to public > reflection, which is definitely still an attractive option for various > reasons from our perspective, but which is also a very different > discussion), we need some sort of mechanism which decouples the literal > dependency system from access permission (much like uses/provides does). > > For example if I could declare that my module uses "javax.ejb", and, in so > doing, automatically grants public and private reflective access to the > module that provides that service, this would be a good outcome. A module > which answers to that service name could be responsible for reflective > access to the application module, providing that information privately to > any other framework modules which require it. > > The migration story looks much better in this light: module descriptors > still can be quite terse and specific. Applications which use reflective > frameworks do not need gratuitous exports; in fact it's much more fluid for > a user to say "I require these helper libraries; I use EJB; that's it" which > means they don't have to worry about the details of whatever particular > environment they run in. This also has the advantage of allowing new Java > 9-generation specifications to stipulate standard service names for each > specification (e.g. "javax.ejb", "javax.cdi", that sort of thing). > > While this doesn't cover 100% of our remaining issues with Jigsaw (of > course; we'll all continue moving through the issues list as we have been to > get us there), meeting these requirements would go a long way towards at > least having a reflection story that is more practical for present-day > frameworks to move forward with. So the last requirement would be: > > ? A module definition must be able to establish that an "indirect" > dependency exists on an otherwise unknown module providing a capability, > wherein that module may require public or public+private reflection access > to some or all packages without compile/link access. This could possibly > exist in conjunction with, or as an evolution of, the current services > mechanism, however a complicating factor is that the current mechanism is > based specifically on types, whereas a purely symbolic relationship might be > better for this purpose (this is not a requirement though if it can be made > to work as-is). Note that any symbolic relationship system would need some > in-code discovery mechanism such that consumers of the capability are made > available to the provider and/or vice-versa, in order to make practical use > of the relationship. > > The following example syntax is meant to be unambiguous and illustrative; no > specific attempt is made to reuse existing keywords (for example), or even > to imply an endorsement of the current descriptor mechanism at all, but to > clarify how this might look in practice and provide a practical application > of the ideas herein. > > Example 1: A contrived provider of the fictional framework > "javax.fictional.orm" illustrating provides/uses-based access granting > > module org.foo.orm.provider { > > // Require a module dependency, and give it private reflection access > to everything > requires org.apache.commons.beanutils with private reflection on *; > > // Require a module dependency with no reflection > requires org.apache.commons.logging; > > // Provide the framework > provides javax.fictional.orm.ORM > using private reflection > with org.foo.orm.provider.ORMImpl1, > org.foo.orm.provider.ORMImpl2; > } > > Example 2: A contrived consumer of #1 > > module com.mycompany.application { > uses javax.fictional.orm.ORM; // automatically gives private > reflection > } > > Example 3: Grant reflection access to a couple of packages to a named > non-dependency module > > module com.mycompany.application { > grant public reflection on > com.mycompay.application.package1, > com.mycompay.application.package2 > to org.foo.framework; > } > > Example 4: Behave like Java 8 > > module com.mycompany.application { > grant private reflection on * to *; > } > > Example 5: Behave like Java 8, but restrict private access without requiring > a security manager > > module com.mycompany.application { > grant public reflection on * to *; > } > > Example 6: An example of using CDI and EJB with symbolic capabilities > > module com.mycompany.application { > uses capability javax.ejb, javax.cdi > } > > Example 7: An example of providing EJB with symbolic capabilities > > module org.foo.ejb.provider { > [...] > provides capability javax.ejb using private reflection; > } > > > -- > - DML From scolebourne at joda.org Mon Sep 26 10:19:32 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 26 Sep 2016 11:19:32 +0100 Subject: Class names in java.lang.Module In-Reply-To: <6F44DA21-9717-442A-AD64-DB9657B142EC@gmail.com> References: <6F44DA21-9717-442A-AD64-DB9657B142EC@gmail.com> Message-ID: Most coding only uses the simple name, not the fully qualified one, and Configuration does occur in other projects [1]. The original poster referred to the package, where Configuration is the only non-exception class that does not have "Module" in the name [2]. Stephen [1] https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/Configuration.html [2] http://download.java.net/java/jdk9/docs/api/java/lang/module/package-summary.html On 26 September 2016 at 10:25, Neil Bartlett wrote: > Module is already in the name: ?java.lang.module.Configuration?. Wouldn?t ?java.lang.module.ModuleConfiguration? look really odd? > > Neil > >> On 21 Sep 2016, at 16:18, Stephen Colebourne wrote: >> >> I had the same thought while watching the slides. Configuration is >> certainly a class name that exists other places, and would benefit >> from being ModuleConfiguration. Layer is less common, so not worried >> so much. Exceptions with "Module" in the name like >> ModuleNotFoundException would also be clearer. >> Stephen >> >> On 21 September 2016 at 03:36, Kasper Nielsen wrote: >>> Hi, >>> >>> I was wondering if there are any reasons for why these 3 classes in >>> java.lang.Module >>> >>> Configuration >>> FindException >>> ResolutionException >>> >>> Does not include the name Module? >>> I especially am not to fond of the very generic Configuration name in my >>> source code would much prefer something like ModuleConfiguration. >>> >>> Best >>> Kasper > From blackdrag at gmx.org Mon Sep 26 10:32:05 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 26 Sep 2016 12:32:05 +0200 Subject: Class names in java.lang.Module In-Reply-To: <6F44DA21-9717-442A-AD64-DB9657B142EC@gmail.com> References: <6F44DA21-9717-442A-AD64-DB9657B142EC@gmail.com> Message-ID: <57E8F925.6060703@gmx.org> On 26.09.2016 11:25, Neil Bartlett wrote: > Module is already in the name: ?java.lang.module.Configuration?. Wouldn?t ?java.lang.module.ModuleConfiguration? look really odd? ah, you mean like List is enough for java.util.List and java.awt.List? Configuration is a really common name in projects. bye Jochen From Alan.Bateman at oracle.com Mon Sep 26 11:11:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 12:11:18 +0100 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: <3095e9ec-558e-d6ab-74d8-59c9048e9df7@redhat.com> References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> <2855a6fe-d758-ce22-eb2f-bf167d1b5986@oracle.com> <3095e9ec-558e-d6ab-74d8-59c9048e9df7@redhat.com> Message-ID: On 26/09/2016 10:28, Andrew Dinn wrote: > : > I'm sorry, Alan ,but I think that is disingenuous. When we see "access > control" on this list all of us really ought to bear in mind what have > been the de facto access control mechanisms for many JDK releases and > many more years. There are two such levels of control and one of them is > the security manager. That's a historic fact. Your statement above reads > very much like an attempt to hijack the discourse by hijacking > terminology so it addresses the topic you want to talk about (there is > no imputation of such a motive here -- I'm just reporting how it looks). I was simply pointing out that when we are discussing access control here then we're talking about the access control that is enforced by the Java Language and VM. No new terminology. It is unfortunate that the legacy security manager mechanism also uses the term "access control" but it's completely different mechanism that is not relevant to anything we are doing here. > : > Has this really been the specification? If so then many years of > differing practice as regards the implementation have made that > 'putative' specification worth less than the paper it is (probably no > longer :-) printed on. The core reflection methods that do access checks (Method.invoke, Constructor.newInstance, Field.set, ...) have always specified IAE. Compliant implementations have always implemented these checks. So there is nothing really here. Core reflection has been loosened slightly so that it assumes readability but it is otherwise aligned with the Java Language and bytecode. -Alan From adinn at redhat.com Mon Sep 26 11:36:46 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 26 Sep 2016 12:36:46 +0100 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> <2855a6fe-d758-ce22-eb2f-bf167d1b5986@oracle.com> <3095e9ec-558e-d6ab-74d8-59c9048e9df7@redhat.com> Message-ID: On 26/09/16 12:11, Alan Bateman wrote: > On 26/09/2016 10:28, Andrew Dinn wrote: > >> : >> I'm sorry, Alan ,but I think that is disingenuous. When we see "access >> control" on this list all of us really ought to bear in mind what have >> been the de facto access control mechanisms for many JDK releases and >> many more years. There are two such levels of control and one of them is >> the security manager. That's a historic fact. Your statement above reads >> very much like an attempt to hijack the discourse by hijacking >> terminology so it addresses the topic you want to talk about (there is >> no imputation of such a motive here -- I'm just reporting how it looks). > I was simply pointing out that when we are discussing access control > here then we're talking about the access control that is enforced by the > Java Language and VM. No new terminology. > > It is unfortunate that the legacy security manager mechanism also uses > the term "access control" but it's completely different mechanism that > is not relevant to anything we are doing here. I addressed that in the text you snipped. The one point of relevance is that which the original poster asked about: -- Why do we need Jigsaw to constrain access control when we can do so using a security manager? Do you (or anyone else involved in defining and implementing Jigsaw) have an answer to that question? Also, you have used the phrase twice now so I have to ask. Where does the notion that the "legacy security manager mechanism" is actually a legacy mechanism come from? Is it to be retired? Or are you just saying that you think it ought to be legacy because you think Jigsaw makes it redundant? If the former then can you point out where the decision was consulted on and agreed by the OpenJDK community? If the latter then I would regard that as yet more of an imperative for you provide the original poster with an answer (I'd also advise that you stop using the term so definitively). >> Has this really been the specification? If so then many years of >> differing practice as regards the implementation have made that >> 'putative' specification worth less than the paper it is (probably no >> longer :-) printed on. > The core reflection methods that do access checks (Method.invoke, > Constructor.newInstance, Field.set, ...) have always specified IAE. > Compliant implementations have always implemented these checks. So there > is nothing really here. Core reflection has been loosened slightly so > that it assumes readability but it is otherwise aligned with the Java > Language and bytecode. I find your account of the specification to be very misleading then. Of course code employing reflection has to protect against IAE because the methods it uses include it as a checked exception. But the core reflection API is also specified to provide setAccessible and it has always been possible to rely on that method to ensure that IAE does not actually get thrown in a large and well-defined set of cases. To describe a severe reduction of that set of cases with the words "there is nothing really here" seems to be even more misleading than your partial account of the specified API. Given that this has been the topic of intense discussion and debate here for the last few months I find it hard to understand how you expect to wave it away with such light words. Perhaps it would be better if you provided those who are concerned by this change with a better account of why it really is needed -- or maybe even considered working towards some more limited change that attempt to meet both their needs and yours. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Mon Sep 26 13:19:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 14:19:44 +0100 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> <2855a6fe-d758-ce22-eb2f-bf167d1b5986@oracle.com> <3095e9ec-558e-d6ab-74d8-59c9048e9df7@redhat.com> Message-ID: On 26/09/2016 12:36, Andrew Dinn wrote: > : > I addressed that in the text you snipped. The one point of relevance is > that which the original poster asked about: > > -- Why do we need Jigsaw to constrain access control when we can do so > using a security manager? > > Do you (or anyone else involved in defining and implementing Jigsaw) > have an answer to that question? This project updates the Java Language to support modules. The access checks that we are talking about happen at compile time and run time. The access checks happen irrespective of whether there is a security manager or not (and of course there is no equivalent at compile time). I'm not sure that there is much more to say on this, the security manager is not really relevant to what we are doing here. > > Also, you have used the phrase twice now so I have to ask. Where does > the notion that the "legacy security manager mechanism" is actually a > legacy mechanism come from? Is it to be retired? Or are you just saying > that you think it ought to be legacy because you think Jigsaw makes it > redundant? Sandboxing with a security manager is legacy and has been highly problematic for a long time. It has not been retired although I think a good discussion for elsewhere on whether it should be deprecated. The only connection to modules is that strong encapsulation makes the platform more secure. Modules is not a replacement for the security manager. > : > I find your account of the specification to be very misleading then. Of > course code employing reflection has to protect against IAE because the > methods it uses include it as a checked exception. But the core > reflection API is also specified to provide setAccessible and it has > always been possible to rely on that method to ensure that IAE does not > actually get thrown in a large and well-defined set of cases. I was trying to point out that core reflection has always been specified to do the same access checks as the Java Language.. The setAccessible method is for suppressing Java Language access checks. As I've said elsewhere, then changing this to align with the proposal for #AwkwardStrongEncapsulation is a very disruptive change and there many issues to work through. > : > > To describe a severe reduction of that set of cases with the words > "there is nothing really here" seems to be even more misleading than > your partial account of the specified API. Given that this has been the > topic of intense discussion and debate here for the last few months I > find it hard to understand how you expect to wave it away with such > light words. Perhaps it would be better if you provided those who are > concerned by this change with a better account of why it really is > needed -- or maybe even considered working towards some more limited > change that attempt to meet both their needs and yours. > There is is nothing being waved away or taking lightly. This project has a stated goal to provide support for strong encapsulation. This has a lot of implications that we've trying to work through. We of course know that strong encapsulation isn't for all modules, hence the proposal on the JSR list to provide a simple means to get the benefits of reliable configuration without opting in to strong encapsulation. -Alan From forax at univ-mlv.fr Mon Sep 26 13:32:58 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Sep 2016 15:32:58 +0200 (CEST) Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> Message-ID: <783274949.332998.1474896778234.JavaMail.zimbra@u-pem.fr> +1 R?mi ----- Mail original ----- > De: "Stephen Colebourne" > ?: "jigsaw-dev" > Envoy?: Lundi 26 Septembre 2016 12:11:58 > Objet: Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / > #AwkwardStrongEncapsulation) > Having read this proposal a number of times, and considering how the > talks explained things at JavaOne, I have come to the conclusion that > this proposal is too complex. FWIW, I like the idea that a module > should be able to declare that it needs reflective access from its > users, however given that the proposal is what results from the idea, > it doesn't seem as appealing as it should. > > The reason why I put forward the exports/exposes approach [1] is that > it keeps the questions that must be asked when creating a module > simple: > - what do I depend on publicly (requires) > - what do I publish publicly (exports) > - what do I publish privately (exposes) > > From a security point of view it also seems that it should be the > responsibility of a module to allow the publishing of its private > details, and simply depending on another module seems very minimal > (and easy to miss) as a mechanism to allow that extra permission. > > Stephen > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009370.html > > > On 21 September 2016 at 17:39, David M. Lloyd wrote: >> In our internal discussion of the proposal for >> #ReflectiveAccessToNonExportedTypes, we discussed the ins and outs of >> various behaviors and have come up with a few ideas or starting points for >> solutions that we think would be more workable in conjunction with existing >> middleware (ours and others'). >> >> For reasons previously explained, we do not think that weak modules are a >> good way forward; I won't go into that again here. But the logical >> re-starting point is: If not weak modules, then what? >> >> I will boil it down to a few basic requirements that we have established. >> This list is probably non-exhaustive but hopefully complete enough to go on >> for now: >> >> ? A module definition must be able to establish that a dependent has (or all >> modules have) access to one or more (or all) packages for public reflection >> only. >> ? A module definition must be able to establish that a dependent has (or all >> modules have) access to one or more (or all) packages for public or private >> reflection only. >> ? A module definition must be able to establish that a dependent has (or all >> modules have) access to one or more (or all) packages for public reflection >> and compilation/linkage (i.e. it's an export by today's terminology). >> ? A module definition must be able to establish that a dependent has (or all >> modules have) access to one or more (or all) packages for public or private >> reflection and compilation/linkage (i.e. it's a "private" export by today's >> terminology). >> ? As today, any packages not declared in one or more of the above categories >> is inaccessible outside of the module in any way (note that as I showed >> previously we have also concluded that it should continue to be impossible >> to export a package for compilation/linkage without public reflection, as we >> have not discovered any use for such a mode). >> >> More generally: >> >> ? The syntax for all of the above has no particular constraint (in fact I >> will try to actively avoid touching what could be a very bikeshedding-rich >> discussion), except that it should not be construable as being pejorative >> against the usage of reflective frameworks; rather, it should be clear what >> level of trust is being established without raising undue warning. >> ? Applications should not need gratuitous amounts of declarations in their >> module(s) in order to utilize frameworks. >> ? As previously established, it should not be possible for one declaration >> to reduce the scope of access of another declaration in a module definition. >> ? Access to a module (for reflective purposes only) must not cause conflicts >> if multiple such modules which contain identical packages are accessible to >> a single consumer; in other words, reflection-only access into >> non-dependency modules is not bound by duplicate package restrictions as >> long as each package is unique per class loader, as per the current (Java 8) >> class loader rules. >> >> The above cover the useful access modes that we have identified. This is >> _nearly_ adequate to cover the use cases that we are currently concerned >> about; for example, I could export all packages for public reflection only >> to a specific framework, if only I know the module name of the >> implementation. >> >> Unfortunately, this does not work well in the case where a module may >> consume a framework whose specification is separate from the implementation. >> An application module may need to use (say) EJB and JPA; there is presently >> no clean way to do so without either (a) relying on a container environment >> to rewrite the descriptor or (b) opening up the module and defeating the >> security mechanism (e.g. "weak"). Without either of these workarounds, the >> application developer must have a good deal of knowledge about what modules >> provide what services within a framework-rich environment, possibly >> resulting in a very verbose (and error-prone) descriptor; none of these >> options is really satisfactory. >> >> Thus, apart from the option of redesigning (to an extent) the security >> mechanism (thereby eliminating the need to seal off access to public >> reflection, which is definitely still an attractive option for various >> reasons from our perspective, but which is also a very different >> discussion), we need some sort of mechanism which decouples the literal >> dependency system from access permission (much like uses/provides does). >> >> For example if I could declare that my module uses "javax.ejb", and, in so >> doing, automatically grants public and private reflective access to the >> module that provides that service, this would be a good outcome. A module >> which answers to that service name could be responsible for reflective >> access to the application module, providing that information privately to >> any other framework modules which require it. >> >> The migration story looks much better in this light: module descriptors >> still can be quite terse and specific. Applications which use reflective >> frameworks do not need gratuitous exports; in fact it's much more fluid for >> a user to say "I require these helper libraries; I use EJB; that's it" which >> means they don't have to worry about the details of whatever particular >> environment they run in. This also has the advantage of allowing new Java >> 9-generation specifications to stipulate standard service names for each >> specification (e.g. "javax.ejb", "javax.cdi", that sort of thing). >> >> While this doesn't cover 100% of our remaining issues with Jigsaw (of >> course; we'll all continue moving through the issues list as we have been to >> get us there), meeting these requirements would go a long way towards at >> least having a reflection story that is more practical for present-day >> frameworks to move forward with. So the last requirement would be: >> >> ? A module definition must be able to establish that an "indirect" >> dependency exists on an otherwise unknown module providing a capability, >> wherein that module may require public or public+private reflection access >> to some or all packages without compile/link access. This could possibly >> exist in conjunction with, or as an evolution of, the current services >> mechanism, however a complicating factor is that the current mechanism is >> based specifically on types, whereas a purely symbolic relationship might be >> better for this purpose (this is not a requirement though if it can be made >> to work as-is). Note that any symbolic relationship system would need some >> in-code discovery mechanism such that consumers of the capability are made >> available to the provider and/or vice-versa, in order to make practical use >> of the relationship. >> >> The following example syntax is meant to be unambiguous and illustrative; no >> specific attempt is made to reuse existing keywords (for example), or even >> to imply an endorsement of the current descriptor mechanism at all, but to >> clarify how this might look in practice and provide a practical application >> of the ideas herein. >> >> Example 1: A contrived provider of the fictional framework >> "javax.fictional.orm" illustrating provides/uses-based access granting >> >> module org.foo.orm.provider { >> >> // Require a module dependency, and give it private reflection access >> to everything >> requires org.apache.commons.beanutils with private reflection on *; >> >> // Require a module dependency with no reflection >> requires org.apache.commons.logging; >> >> // Provide the framework >> provides javax.fictional.orm.ORM >> using private reflection >> with org.foo.orm.provider.ORMImpl1, >> org.foo.orm.provider.ORMImpl2; >> } >> >> Example 2: A contrived consumer of #1 >> >> module com.mycompany.application { >> uses javax.fictional.orm.ORM; // automatically gives private >> reflection >> } >> >> Example 3: Grant reflection access to a couple of packages to a named >> non-dependency module >> >> module com.mycompany.application { >> grant public reflection on >> com.mycompay.application.package1, >> com.mycompay.application.package2 >> to org.foo.framework; >> } >> >> Example 4: Behave like Java 8 >> >> module com.mycompany.application { >> grant private reflection on * to *; >> } >> >> Example 5: Behave like Java 8, but restrict private access without requiring >> a security manager >> >> module com.mycompany.application { >> grant public reflection on * to *; >> } >> >> Example 6: An example of using CDI and EJB with symbolic capabilities >> >> module com.mycompany.application { >> uses capability javax.ejb, javax.cdi >> } >> >> Example 7: An example of providing EJB with symbolic capabilities >> >> module org.foo.ejb.provider { >> [...] >> provides capability javax.ejb using private reflection; >> } >> >> >> -- > > - DML From adinn at redhat.com Mon Sep 26 16:37:39 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 26 Sep 2016 17:37:39 +0100 Subject: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation) In-Reply-To: References: <20160912150801.AD8AECD07F@eggemoggin.niobe.net> <5b9b1929-eb92-09ab-2997-d7e2395a1d9d@redhat.com> <7EEC5883-AA2E-4EDF-90D1-CBD317300C7B@cox.net> <2855a6fe-d758-ce22-eb2f-bf167d1b5986@oracle.com> <3095e9ec-558e-d6ab-74d8-59c9048e9df7@redhat.com> Message-ID: On 26/09/16 14:19, Alan Bateman wrote: > On 26/09/2016 12:36, Andrew Dinn wrote: > >> : >> I addressed that in the text you snipped. The one point of relevance is >> that which the original poster asked about: >> >> -- Why do we need Jigsaw to constr