From mandy.chung at oracle.com Tue Nov 1 03:26:52 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 31 Oct 2016 20:26:52 -0700 Subject: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs In-Reply-To: <999B3AA4-F218-4866-A28B-DA5E2A4FA493@oracle.com> References: <8A189B47-213D-42D9-86F0-F46D580252B6@oracle.com> <22EEC3EC-ED41-4C61-B0F3-B48EC5A54DE1@oracle.com> <25FB0E59-E2CD-4D9A-A60B-15357E145A51@oracle.com> <94b878e9-8006-bcc7-9aaa-15e0b3ad181f@oracle.com> <714F96B8-5152-439B-A4DA-34E0FBEF4ADB@oracle.com> <56e8d3f7-070e-5e2e-4117-1d7879dbd668@oracle.com> <999B3AA4-F218-4866-A28B-DA5E2A4FA493@oracle.com> Message-ID: <960EB41A-0708-4C5B-9CC0-3C6FCB8965B0@oracle.com> > On Oct 27, 2016, at 5:22 PM, Steve Drach wrote: > > I?ve put out another webrev, http://cr.openjdk.java.net/~sdrach/8156499/webrev.05/, that addresses Mandy?s concerns. In particular I demonstrate that the resultant image is ?runnable? and that a Main class in the image can/cannot find the java.logging module when the module-info.class is changed to require java.logging in one case but not in the other. Looks okay in general. The jlink change looks correct. Thanks for updating the test. Mandy From mandy.chung at oracle.com Tue Nov 1 03:34:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 31 Oct 2016 20:34:35 -0700 Subject: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs In-Reply-To: <960EB41A-0708-4C5B-9CC0-3C6FCB8965B0@oracle.com> References: <8A189B47-213D-42D9-86F0-F46D580252B6@oracle.com> <22EEC3EC-ED41-4C61-B0F3-B48EC5A54DE1@oracle.com> <25FB0E59-E2CD-4D9A-A60B-15357E145A51@oracle.com> <94b878e9-8006-bcc7-9aaa-15e0b3ad181f@oracle.com> <714F96B8-5152-439B-A4DA-34E0FBEF4ADB@oracle.com> <56e8d3f7-070e-5e2e-4117-1d7879dbd668@oracle.com> <999B3AA4-F218-4866-A28B-DA5E2A4FA493@oracle.com> <960EB41A-0708-4C5B-9CC0-3C6FCB8965B0@oracle.com> Message-ID: <1563478E-5C73-4CA8-94E0-C1098B006058@oracle.com> > On Oct 31, 2016, at 8:26 PM, Mandy Chung wrote: > > >> On Oct 27, 2016, at 5:22 PM, Steve Drach wrote: >> >> I?ve put out another webrev, http://cr.openjdk.java.net/~sdrach/8156499/webrev.05/, that addresses Mandy?s concerns. In particular I demonstrate that the resultant image is ?runnable? and that a Main class in the image can/cannot find the java.logging module when the module-info.class is changed to require java.logging in one case but not in the other. > > Looks okay in general. The jlink change looks correct. Thanks for updating the test. In fact - does this test run on windows? 239 Path java = Paths.get(image, "bin", "java?); On windows, shouldn?t this need to be ?java.exe?? Mandy From alan.bateman at oracle.com Tue Nov 1 06:45:05 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 01 Nov 2016 06:45:05 +0000 Subject: hg: jigsaw/jake/jdk: pack200 tests failing Message-ID: <201611010645.uA16j6gh020390@aojmv0008.oracle.com> Changeset: 71fa9c880f90 Author: alanb Date: 2016-11-01 06:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/71fa9c880f90 pack200 tests failing ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From alan.bateman at oracle.com Tue Nov 1 06:49:22 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 01 Nov 2016 06:49:22 +0000 Subject: hg: jigsaw/jake/langtools: jdk/jshell/PipeInputStreamTest.java failing Message-ID: <201611010649.uA16nMmT021396@aojmv0008.oracle.com> Changeset: 8d34e5c09607 Author: alanb Date: 2016-11-01 06:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8d34e5c09607 jdk/jshell/PipeInputStreamTest.java failing ! test/jdk/jshell/PipeInputStreamTest.java From Alan.Bateman at oracle.com Tue Nov 1 09:40:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 09:40:35 +0000 Subject: Request Review: JDK-6479237 (cl) Add support for classloader names In-Reply-To: <4122A213-01F7-4CD8-8DBF-31D79C368D23@oracle.com> References: <2C30243B-71D2-49E2-A8B6-2C33B82DB104@oracle.com> <3E287445-89C5-463D-95E1-928514FDEA0C@oracle.com> <51ee4875-5aac-59e8-a9ce-4f4971e05dac@oracle.com> <4122A213-01F7-4CD8-8DBF-31D79C368D23@oracle.com> Message-ID: <5406563c-4931-3563-40fd-7b6c3617b602@oracle.com> On 31/10/2016 21:34, Mandy Chung wrote: >> On Oct 31, 2016, at 6:51 AM, Alan Bateman wrote: >>> if (VM.isModuleSystemInited() && !HashedModules.contains(m)) { >> Looks okay, an alternative would be to move that that check to L439. > > What do you think about this? > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.03/ > > This looks okay as we'll only have frames for java.base during early startup. -Alan From Alan.Bateman at oracle.com Tue Nov 1 10:23:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 10:23:17 +0000 Subject: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments. In-Reply-To: References: <94D737C6-A265-4657-B93E-4A2271617D27@oracle.com> <955f21c4-8d21-1186-f623-477356236a20@oracle.com> <3FCA900B-3A27-4E43-84C3-09789B25B813@oracle.com> <580936aa-3f94-1904-439e-5440cfc81e43@oracle.com> <383FAF53-1678-4685-9888-0F7A0A71BD4C@oracle.com> <1AC8A30B-B5B5-489E-97E5-FC1C3C1F70B4@oracle.com> Message-ID: <894b5aa6-100e-f819-8cfe-fce7096f6e84@oracle.com> On 31/10/2016 21:39, Alexandre (Shura) Iline wrote: > : > Which syntax would be better? > > 1. Requiring explicit ALL-UNNAMED > .addExports("java.base", ?jdk.internal.misc?, ALL_UNNAMED) > .addExports("java.base", "jdk.internal.reflect?, ALL_UNNAMED) > 2. Treating ALL-UNNAMED as a default > .addExports("java.base", ?jdk.internal.misc?) > .addExports("java.base", "jdk.internal.reflect?) > > Same for addReads(?) and, I assume, addOpens(?). > > With any of the two, I am in favor of removing addExports(String), addReads(String) and addOpens(String) methods. If a complete string parameter needs to be passed (such as for negative tests), it could be passed through the vmOptions(String ?) method. > > What do you think? > All very subjective and I'm sure others will have different opinions. For these three options then the value has two parts, `--add-reads =` for example, and the simplest is to just provide a method that takes two parameters, e.g. : .addReads("m1, "m2") .addExports("java.base", "jdk.internal.misc=ALL-UNNAMED") .addOpens("java.base", "jdk.internal.misc=m1,m2") .build(); The resulting tests should be very readable. Also it has the benefit that we can send bad values, important for many of these tests because they are probing behavior with bad modules, packages, ... For addModules then `String module, String... rest` should work nicely: .addModules("java.corba") .addModules("java.naming", "java.xml.bind") .addModules("jdk.attach,jdk.jdi") -Alan From Alan.Bateman at oracle.com Tue Nov 1 10:26:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 10:26:47 +0000 Subject: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments. In-Reply-To: <894b5aa6-100e-f819-8cfe-fce7096f6e84@oracle.com> References: <94D737C6-A265-4657-B93E-4A2271617D27@oracle.com> <955f21c4-8d21-1186-f623-477356236a20@oracle.com> <3FCA900B-3A27-4E43-84C3-09789B25B813@oracle.com> <580936aa-3f94-1904-439e-5440cfc81e43@oracle.com> <383FAF53-1678-4685-9888-0F7A0A71BD4C@oracle.com> <1AC8A30B-B5B5-489E-97E5-FC1C3C1F70B4@oracle.com> <894b5aa6-100e-f819-8cfe-fce7096f6e84@oracle.com> Message-ID: On 01/11/2016 10:23, Alan Bateman wrote: > : > > .addExports("java.base", "jdk.internal.misc=ALL-UNNAMED") > .addOpens("java.base", "jdk.internal.misc=m1,m2") Oops, a typo here, I meant this of course: .addExports("java.base/jdk.internal.misc", "ALL-UNNAMED") .addOpens("java.base/jdk.internal.misc", m1,m2") -Alan. From forax at univ-mlv.fr Tue Nov 1 12:12:10 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 Nov 2016 13:12:10 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> Message-ID: <60067889.273189.1478002330368.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Remi Forax" > ?: "Paul Bakker" > Cc: jigsaw-dev at openjdk.java.net > Envoy?: Mardi 1 Novembre 2016 00:57:47 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages > Hi Paul, > I think you can already sketch an implementation of the proposal now by using > either an annotation processor + a jlink plugin, or by a jlink plugin + a > bytecode processor tool. > I believe that you can push the information needed by the meta-framework to > fulfill requests by adding some method calls inside the static initializer of > the classes that are annotated. > The runtime part can be something along that line > > https://gist.github.com/forax/1511fae2273f04273ff9463c6fbbdfbc > > Instead of providing method handles as John suggests, i provide the lookup > object which is less secure. > And the Class object in the map are stored as strong ref instead of being an > ephemeron (the lambda used as value in the map has also a strong reference on > the class). After shower edit, i've updated the gist to use a ClassValue + a CAS so there is no strong ref to the classes now. > > R?mi R?mi > > ----- Mail original ----- >> De: "Paul Bakker" >> ?: jigsaw-dev at openjdk.java.net >> Envoy?: Lundi 31 Octobre 2016 18:06:27 >> Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & >> open packages > >> The proposal looks very good! Thanks for listening to the voiced concerns. >> When can we expect a new prototype containing the proposed features? >> >> Thanks, >> >> Paul >> >> On Fri, Oct 28, 2016 at 3:38 PM John Rose wrote: >> >>> On Oct 27, 2016, at 9:07 AM, mark.reinhold at oracle.com wrote: >>> > >>> > Further comments most welcome, as usual! >>> >>> >>> +100 for *qualified* opens; this puts an important limit on deep >>> reflection. >>> >>> My main concern with reflection is to avoid "falling off the encapsulation >>> cliff" >>> the first time a user module wishes to open itself up for deep reflection. >>> By such a "cliff" I mean that when deep reflection is allowed, potentially >>> any name in the module can be inspected. Even of only 0.01% of names >>> are actually inspected, tools for reorganizing code must assume that 100% >>> of the names *might* be inspected, at some point in the future, by the >>> allowed party. >>> >>> So qualified opens is a partial solution. And, I think it is exactly >>> right for >>> today, because it can be extended tomorrow. I.e., it is future-friendly. >>> I'll explain by sketching a concept called "moderate reflection", or "MR". >>> >>> A fuller solution would allow other tools to make conclusions about more >>> specific limitations on the actual extent of the deep reflection. Call >>> such >>> an extent-limited reflection moderate reflection, where "moderation" is >>> declared statically by some sort of flexible declarative rule set. In >>> this way >>> tools could make more detailed conclusions about the encapsulation of >>> particular names in the module. >>> >>> For future JDK releases we can consider layering of this qualified opens, >>> by creating a trusted, parameterized meta-framework ("Moderate Reflection") >>> to which a user module can be qualified-open. This meta-framework can >>> then perform deep reflection on behalf of self-describing "moderately >>> reflecting" >>> client frameworks. User modules would not directly open themselves to any >>> module other than MR. >>> >>> The advantage would come when the client frameworks explicitly declare >>> their >>> self-restraint ("moderation") in reflection. For example, the "Foo" >>> framework >>> might limit itself to names annotated with @FooFrameworkHook. >>> >>> An AOT compiler (or other jlink-time reorganization tool) would (1) note >>> that >>> some user module bar is qualified-open only to Moderate Reflection, and >>> has an export (maybe qualified) to a Foo framework. At runtime, (2) the >>> Foo framework would ask Moderate Reflection to reflect into bar. >>> Moderate Reflection would (3) check the self-limitation on Foo, and also >>> ensure that bar exports (though doesn't open) to Foo. MR would then >>> gain the requested access and delegate it back to Foo. Finally, (4) the >>> AOT compiler would free itself to omit metadata for unexported names >>> not visible to moderate reflection. >>> >>> (Method handles are a good way to grant access, since they can >>> be delegated from MR to Foo without re-authorizing Foo. Core >>> Reflection re-authorizes on every access, which awkwardly >>> requires deep reflection on usage, as well as initial lookup.) >>> >>> Moderate Reflection might also look at metadata on the bar module >>> (besides its module exports) to impose further limits on reflection. >>> Thus, MR-specific metadata might prevent MR from granting bar >>> access to normally-trusted frameworks that bar doesn't trust, if >>> bar can blacklist them for itself in a place that MR checks. >>> >>> And so on. None of this needs to be built into the module system. >>> To gain the benefit of it, basic parametric policies need to be >>> implemented, >>> adopted by client frameworks, and used by tools to perform optimizations. >>> >>> A typical optimization is "tree shaking", where a class or method that is >>> never used is dropped from the application. Or, if it is used in a way >>> that >>> can be inlined locally, the metadata can still be dropped. In either case, >>> making code go dead is an important ingredient to many optimizations. >>> > > > ? John From chris.hegarty at oracle.com Tue Nov 1 12:42:35 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 01 Nov 2016 12:42:35 +0000 Subject: hg: jigsaw/jake/jdk: Import of 8168980: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class, Constructor) Message-ID: <201611011242.uA1CgZSr006755@aojmv0008.oracle.com> Changeset: 7992a052c7fa Author: chegar Date: 2016-11-01 12:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7992a052c7fa Import of 8168980: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class,Constructor) Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java ! test/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java From david.lloyd at redhat.com Tue Nov 1 13:53:19 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 1 Nov 2016 08:53:19 -0500 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> Message-ID: <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> I just want to point out the two obvious (closely related) major problems with this approach which prevent it from being a practical replacement for setAcceptable, lest they are forgotten/ignored in the excitement around the new ideas: 1. It requires the target class to be initialized 2. It requires the target class to proactively donate MethodHandles or a Lookup to the lookup class Both of these are effectively pretty substantial usability regressions compared to the status quo. These problems are why I'd rather see some kind of static grant mechanism, and either a special static API to get an extra-privileged Lookup or the appropriate magic to allow a class's "normal" Lookup object to "see" everything that was granted to it; but really any idea which would solve both of these problems in any way should be put forward for consideration IMO. On 10/31/2016 06:57 PM, Remi Forax wrote: > Hi Paul, > I think you can already sketch an implementation of the proposal now by using either an annotation processor + a jlink plugin, or by a jlink plugin + a bytecode processor tool. > I believe that you can push the information needed by the meta-framework to fulfill requests by adding some method calls inside the static initializer of the classes that are annotated. > The runtime part can be something along that line > > https://gist.github.com/forax/1511fae2273f04273ff9463c6fbbdfbc > > Instead of providing method handles as John suggests, i provide the lookup object which is less secure. > And the Class object in the map are stored as strong ref instead of being an ephemeron (the lambda used as value in the map has also a strong reference on the class). > > R?mi > > ----- Mail original ----- >> De: "Paul Bakker" >> ?: jigsaw-dev at openjdk.java.net >> Envoy?: Lundi 31 Octobre 2016 18:06:27 >> Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages > >> The proposal looks very good! Thanks for listening to the voiced concerns. >> When can we expect a new prototype containing the proposed features? >> >> Thanks, >> >> Paul >> >> On Fri, Oct 28, 2016 at 3:38 PM John Rose wrote: >> >>> On Oct 27, 2016, at 9:07 AM, mark.reinhold at oracle.com wrote: >>>> >>>> Further comments most welcome, as usual! >>> >>> >>> +100 for *qualified* opens; this puts an important limit on deep >>> reflection. >>> >>> My main concern with reflection is to avoid "falling off the encapsulation >>> cliff" >>> the first time a user module wishes to open itself up for deep reflection. >>> By such a "cliff" I mean that when deep reflection is allowed, potentially >>> any name in the module can be inspected. Even of only 0.01% of names >>> are actually inspected, tools for reorganizing code must assume that 100% >>> of the names *might* be inspected, at some point in the future, by the >>> allowed party. >>> >>> So qualified opens is a partial solution. And, I think it is exactly >>> right for >>> today, because it can be extended tomorrow. I.e., it is future-friendly. >>> I'll explain by sketching a concept called "moderate reflection", or "MR". >>> >>> A fuller solution would allow other tools to make conclusions about more >>> specific limitations on the actual extent of the deep reflection. Call >>> such >>> an extent-limited reflection moderate reflection, where "moderation" is >>> declared statically by some sort of flexible declarative rule set. In >>> this way >>> tools could make more detailed conclusions about the encapsulation of >>> particular names in the module. >>> >>> For future JDK releases we can consider layering of this qualified opens, >>> by creating a trusted, parameterized meta-framework ("Moderate Reflection") >>> to which a user module can be qualified-open. This meta-framework can >>> then perform deep reflection on behalf of self-describing "moderately >>> reflecting" >>> client frameworks. User modules would not directly open themselves to any >>> module other than MR. >>> >>> The advantage would come when the client frameworks explicitly declare >>> their >>> self-restraint ("moderation") in reflection. For example, the "Foo" >>> framework >>> might limit itself to names annotated with @FooFrameworkHook. >>> >>> An AOT compiler (or other jlink-time reorganization tool) would (1) note >>> that >>> some user module bar is qualified-open only to Moderate Reflection, and >>> has an export (maybe qualified) to a Foo framework. At runtime, (2) the >>> Foo framework would ask Moderate Reflection to reflect into bar. >>> Moderate Reflection would (3) check the self-limitation on Foo, and also >>> ensure that bar exports (though doesn't open) to Foo. MR would then >>> gain the requested access and delegate it back to Foo. Finally, (4) the >>> AOT compiler would free itself to omit metadata for unexported names >>> not visible to moderate reflection. >>> >>> (Method handles are a good way to grant access, since they can >>> be delegated from MR to Foo without re-authorizing Foo. Core >>> Reflection re-authorizes on every access, which awkwardly >>> requires deep reflection on usage, as well as initial lookup.) >>> >>> Moderate Reflection might also look at metadata on the bar module >>> (besides its module exports) to impose further limits on reflection. >>> Thus, MR-specific metadata might prevent MR from granting bar >>> access to normally-trusted frameworks that bar doesn't trust, if >>> bar can blacklist them for itself in a place that MR checks. >>> >>> And so on. None of this needs to be built into the module system. >>> To gain the benefit of it, basic parametric policies need to be >>> implemented, >>> adopted by client frameworks, and used by tools to perform optimizations. >>> >>> A typical optimization is "tree shaking", where a class or method that is >>> never used is dropped from the application. Or, if it is used in a way >>> that >>> can be inlined locally, the metadata can still be dropped. In either case, >>> making code go dead is an important ingredient to many optimizations. >>> >>> ? John -- - DML From daniel.fuchs at oracle.com Tue Nov 1 14:04:25 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Nov 2016 14:04:25 +0000 Subject: Request Review: JDK-6479237 (cl) Add support for classloader names In-Reply-To: <931BF9A2-6F22-48FF-855E-287BAF10FDC0@oracle.com> References: <2C30243B-71D2-49E2-A8B6-2C33B82DB104@oracle.com> <5d494d3a-f8ec-0456-8d04-f8998d840fc7@oracle.com> <52E8F822-2D4E-4BD7-BE4E-748E47901625@oracle.com> <931BF9A2-6F22-48FF-855E-287BAF10FDC0@oracle.com> Message-ID: <237186f1-13b4-5a94-099d-cf1f07e7b120@oracle.com> Hi Mandy, I am sure I must be missing something: 322 if (s == null) { 323 // all elements will be included 324 s = ""; 325 if (classLoaderName != null && !classLoaderName.isEmpty()) { 326 s += classLoaderName + "/"; 327 } 328 if (moduleName != null && !moduleName.isEmpty()) { 329 s += moduleName; 330 } 331 if (moduleVersion != null && !moduleVersion.isEmpty()) { 332 s += "@" + moduleVersion; 333 } 334 s += declaringClass; 335 } but should line 334 instead be s = (s.isEmpty() ? declaringClass : s + "/" + declaringClass; Otherwise "/" will be missing after module at version.. Also should there be some asserts somewhere verifying that moduleVersion is null or empty when moduleName is null or empty? At the moment the constructor will blindly accept a version for an unnamed module, and I am assuming this is wrong - am I right? toLoaderModuleClassName will call ClassLoader.getName(). If a class loader overrides getName() then that might be a different name than what StackTraceElement.getClassLoaderName() returns. Is that an issue? Also I wonder whether you should be considering including a fix for https://bugs.openjdk.java.net/browse/JDK-8167099 as part of this change (though arguably the bug has been there since new fields were added to StackTraceElement in 9). best regards, -- daniel On 28/10/16 21:44, Mandy Chung wrote: > >> On Oct 28, 2016, at 11:11 AM, Brent Christian wrote: >> >> Should something be done for STEs returned from StackFrameInfo.toStackTraceElement() ? > > Good catch - I missed it. I added package-private static methods in StackTraceElement class for both Throwable and StackFrameInfo to get StackTraceElement(s). > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.02/ > > Mandy > From john.r.rose at oracle.com Tue Nov 1 14:04:33 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Nov 2016 10:04:33 -0400 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> Message-ID: <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> On Nov 1, 2016, at 9:53 AM, David M. Lloyd wrote: > > 1. It requires the target class to be initialized > 2. It requires the target class to proactively donate MethodHandles or a Lookup to the lookup class Both of these can be overcome, though only by privileged code. The privileged code would forge (uh, "mint") a legitimate Lookup to the not-yet-initialized class. A "Vault" meta-framework doesn't need to inject a Lookup donation statement into anybody's . Instead, it needs to do the super-user operation of making a trusted lookup. It must also fulfill the super-user *responsibility* of not leaking such lookups, just using them in a predictable, rule-based manner. ? John From blackdrag at gmx.org Tue Nov 1 14:22:07 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 1 Nov 2016 15:22:07 +0100 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> Message-ID: <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> On 01.11.2016 15:04, John Rose wrote: > On Nov 1, 2016, at 9:53 AM, David M. Lloyd wrote: >> >> 1. It requires the target class to be initialized >> 2. It requires the target class to proactively donate MethodHandles or a Lookup to the lookup class > > Both of these can be overcome, though only by privileged code. > The privileged code would forge (uh, "mint") a legitimate Lookup to the not-yet-initialized class. > A "Vault" meta-framework doesn't need to inject a Lookup donation statement into anybody's . > Instead, it needs to do the super-user operation of making a trusted lookup. > It must also fulfill the super-user *responsibility* of not leaking such lookups, just using them in a predictable, rule-based manner. Can we clarify "privileged code"? Privileged like in a SecurityManager in a PrivilegedAction for example, for privileged like only jdk internal code? Just to see it black on white ;) bye Jochen From john.r.rose at oracle.com Tue Nov 1 14:23:18 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Nov 2016 10:23:18 -0400 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> Message-ID: <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote: > > Can we clarify "privileged code"? Privileged like in a SecurityManager in a PrivilegedAction for example, for privileged like only jdk internal code? Just to see it black on white ;) Good question: I mean the basic JDK platform implementation. Something deep in java.base. Like Unsafe. From david.lloyd at redhat.com Tue Nov 1 14:39:01 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 1 Nov 2016 09:39:01 -0500 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> Message-ID: <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> On 11/01/2016 09:23 AM, John Rose wrote: > On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote: >> >> Can we clarify "privileged code"? Privileged like in a SecurityManager in a PrivilegedAction for example, for privileged like only jdk internal code? Just to see it black on white ;) > > Good question: I mean the basic JDK platform implementation. Something deep in java.base. Like Unsafe. I don't see why this can't be a "regular" API though, rather than a super-user sledgehammer every single time. If user code can be statically granted access, and that user code can deliberately acquire a narrowly-scoped object which can access those Lookups/*Handles, then isn't that better than using Unsafe, which not only represents unrestricted system-wide access, but can undermine even the JVM's integrity if leaked? -- - DML From adinn at redhat.com Tue Nov 1 14:57:45 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 1 Nov 2016 14:57:45 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> Message-ID: On 01/11/16 14:23, John Rose wrote: > On Nov 1, 2016, at 10:22 AM, Jochen Theodorou > wrote: >> >> Can we clarify "privileged code"? Privileged like in a >> SecurityManager in a PrivilegedAction for example, for privileged >> like only jdk internal code? Just to see it black on white ;) > > Good question: I mean the basic JDK platform implementation. > Something deep in java.base. Like Unsafe. Or indeed you might only require enough privilege to call the public MethodHandles.Lookup constructor -- n.b. although that constructor is public its package is not exported to the default module. Of course, you can always arrange for it to be exported to one of /your/ modules. Note that whatever mechanism is used to obtain Lookup instances this has several advantages. 1) Once a privileged module is able to create Lookups (with suitably constrained access) arranging for it to safely hand them over to your framework code (and to no other code) when needed and with no more access than is actually merited is relatively simple. Better still arrange to hand over the requisite MethodHandles and keep the Lookup instances secured. Whereas If you want to use reflection safely then you have to be able to call setAccessible from a module which is an export target for the package of the class whose member you want to access. In general you don't want to export all possible reflection targets to all your framework code (especially when it is in the default module). So, you end up having to set up some privileged module and arrange for it call setAccessible on behalf of your framework code (and no other code). Configuring all potential exports to a privileged module in advance on the command line will be tricky/verbose at best to and may well not even be possible. If you have an agent that is capable of editing exports lists then you can rewrite module exports to your privileged module on the fly but that is also a lot of work (I know because I have tried it). 2) A MethodHandle created by a Lookup is not opaque to the compiler. So this creates opportunities for the compiler to optimize the code that employs them. Accessible fields/methods/constructors are opaque to the compiler which makes it much less likely that optimization will be possible. regards, Andrew Dinn ----------- From weijun.wang at oracle.com Tue Nov 1 15:02:41 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 1 Nov 2016 23:02:41 +0800 Subject: How to check for an internal class in another module from java.base? Message-ID: <14804650-21DC-438A-A62A-A8D3C2225DA1@oracle.com> HTTP Negotiate uses Class.forName("sun.net.www.protocol.http.spnego.NegotiatorImpl", true, null); to check if the implementation in java.security.jgss module is provided. It looks like this call is throwing a ClassNotFoundException now. Shall I export the package to java.base or is there any other trick? I remember there used to be an addReads method but seems no one is using it now. Or I must use a service loader? Thanks Max From Alan.Bateman at oracle.com Tue Nov 1 15:10:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 15:10:45 +0000 Subject: How to check for an internal class in another module from java.base? In-Reply-To: <14804650-21DC-438A-A62A-A8D3C2225DA1@oracle.com> References: <14804650-21DC-438A-A62A-A8D3C2225DA1@oracle.com> Message-ID: <57ebb2f7-bb98-b831-e20f-b28b308a6528@oracle.com> On 01/11/2016 15:02, Wang Weijun wrote: > HTTP Negotiate uses > > Class.forName("sun.net.www.protocol.http.spnego.NegotiatorImpl", true, null); > > to check if the implementation in java.security.jgss module is provided. It looks like this call is throwing a ClassNotFoundException now. Shall I export the package to java.base or is there any other trick? I remember there used to be an addReads method but seems no one is using it now. > > Or I must use a service loader? > This is just visibility. The jdk.security.jgss module is defined to the platform class loader but but you have specified "null" (= bootstrap class loader) to Class.forName. There is an issue in JIRA to track change the HTTP protocol handler to use services for authentication mechanism, I don't think anyone has had time to work on that yet. -Alan. From adinn at redhat.com Tue Nov 1 15:09:59 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 1 Nov 2016 15:09:59 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> Message-ID: On 01/11/16 14:39, David M. Lloyd wrote: > On 11/01/2016 09:23 AM, John Rose wrote: >> On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote: >>> >>> Can we clarify "privileged code"? Privileged like in a >>> SecurityManager in a PrivilegedAction for example, for privileged >>> like only jdk internal code? Just to see it black on white ;) >> >> Good question: I mean the basic JDK platform implementation. >> Something deep in java.base. Like Unsafe. > > I don't see why this can't be a "regular" API though, rather than a > super-user sledgehammer every single time. If user code can be > statically granted access, and that user code can deliberately acquire a > narrowly-scoped object which can access those Lookups/*Handles, then > isn't that better than using Unsafe, which not only represents > unrestricted system-wide access, but can undermine even the JVM's > integrity if leaked? If making this a 'regular' API means allowing any code to use it then that clearly undermines /all/ the access restrictions provided by modules. The point is not to unlock all doors in the castle but to open doors for trusted code when needed (and only then). There is a very easy way to provide tightly controlled access to a framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. java.lang.reflect.MethodHandles to a nominated module provided by your framework then arrange for that module to hand out Lookups (or better MethodHandles) to framework code as and when they are needed via a private channel. You can do arrange that with a single addExports option on the command line and a very small amount of setup code to establish the private channel regards, Andrew Dinn ----------- From forax at univ-mlv.fr Tue Nov 1 15:11:50 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 Nov 2016 16:11:50 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> Message-ID: <1001794757.293532.1478013110349.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "David M. Lloyd" > Cc: jigsaw-dev at openjdk.java.net > Envoy?: Mardi 1 Novembre 2016 15:04:33 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages > On Nov 1, 2016, at 9:53 AM, David M. Lloyd wrote: >> >> 1. It requires the target class to be initialized >> 2. It requires the target class to proactively donate MethodHandles or a Lookup >> to the lookup class > > Both of these can be overcome, though only by privileged code. > The privileged code would forge (uh, "mint") a legitimate Lookup to the > not-yet-initialized class. > A "Vault" meta-framework doesn't need to inject a Lookup donation statement into > anybody's . > Instead, it needs to do the super-user operation of making a trusted lookup. > It must also fulfill the super-user *responsibility* of not leaking such > lookups, just using them in a predictable, rule-based manner. > ? John yes, being in java.lang.invoke is enough, https://gist.github.com/forax/cab12206323ca2e5866c9f8e20ee6d40 R?mi From daniel.fuchs at oracle.com Tue Nov 1 15:12:53 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Nov 2016 15:12:53 +0000 Subject: How to check for an internal class in another module from java.base? In-Reply-To: <57ebb2f7-bb98-b831-e20f-b28b308a6528@oracle.com> References: <14804650-21DC-438A-A62A-A8D3C2225DA1@oracle.com> <57ebb2f7-bb98-b831-e20f-b28b308a6528@oracle.com> Message-ID: On 01/11/16 15:10, Alan Bateman wrote: > There is an issue in JIRA to track change the HTTP protocol handler to > use services for authentication mechanism, I don't think anyone has had > time to work on that yet. This is https://bugs.openjdk.java.net/browse/JDK-8038079 -- daniel From adinn at redhat.com Tue Nov 1 15:14:17 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 1 Nov 2016 15:14:17 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> Message-ID: <324c7024-4ca1-4421-6049-def67dd04b59@redhat.com> Oops, wrong package! -- corrected inline On 01/11/16 15:09, Andrew Dinn wrote: > On 01/11/16 14:39, David M. Lloyd wrote: >> On 11/01/2016 09:23 AM, John Rose wrote: >>> On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote: >>>> >>>> Can we clarify "privileged code"? Privileged like in a >>>> SecurityManager in a PrivilegedAction for example, for privileged >>>> like only jdk internal code? Just to see it black on white ;) >>> >>> Good question: I mean the basic JDK platform implementation. >>> Something deep in java.base. Like Unsafe. >> >> I don't see why this can't be a "regular" API though, rather than a >> super-user sledgehammer every single time. If user code can be >> statically granted access, and that user code can deliberately acquire a >> narrowly-scoped object which can access those Lookups/*Handles, then >> isn't that better than using Unsafe, which not only represents >> unrestricted system-wide access, but can undermine even the JVM's >> integrity if leaked? > > If making this a 'regular' API means allowing any code to use it then > that clearly undermines /all/ the access restrictions provided by > modules. The point is not to unlock all doors in the castle but to open > doors for trusted code when needed (and only then). > > There is a very easy way to provide tightly controlled access to a > framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. > java.lang.reflect.MethodHandles to a nominated module provided by your ^ +--java.lang.invoke.MethodHandles > framework then arrange for that module to hand out Lookups (or better > MethodHandles) to framework code as and when they are needed via a > private channel. You can do arrange that with a single addExports option > on the command line and a very small amount of setup code to establish > the private channel > > regards, > > > Andrew Dinn > ----------- > > -- 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 forax at univ-mlv.fr Tue Nov 1 15:17:05 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 Nov 2016 16:17:05 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> Message-ID: <156662487.293903.1478013425974.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David M. Lloyd" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Mardi 1 Novembre 2016 15:39:01 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages > On 11/01/2016 09:23 AM, John Rose wrote: >> On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote: >>> >>> Can we clarify "privileged code"? Privileged like in a SecurityManager in a >>> PrivilegedAction for example, for privileged like only jdk internal code? Just >>> to see it black on white ;) >> >> Good question: I mean the basic JDK platform implementation. Something deep in >> java.base. Like Unsafe. > > I don't see why this can't be a "regular" API though, rather than a > super-user sledgehammer every single time. If user code can be > statically granted access, and that user code can deliberately acquire a > narrowly-scoped object which can access those Lookups/*Handles, then > isn't that better than using Unsafe, which not only represents > unrestricted system-wide access, but can undermine even the JVM's > integrity if leaked? > It's better than Unsafe because as a user you have to grant access by using by example an annotation, and you can specifies friends and/or what you want to export (only private/only package private, etc). But if the API returns a Lookup object and a client code with granted access exposes that lookup, all bets are off. > -- > - DML R?mi From weijun.wang at oracle.com Tue Nov 1 15:18:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 1 Nov 2016 23:18:45 +0800 Subject: How to check for an internal class in another module from java.base? In-Reply-To: <57ebb2f7-bb98-b831-e20f-b28b308a6528@oracle.com> References: <14804650-21DC-438A-A62A-A8D3C2225DA1@oracle.com> <57ebb2f7-bb98-b831-e20f-b28b308a6528@oracle.com> Message-ID: > On Nov 1, 2016, at 11:10 PM, Alan Bateman wrote: > > > > On 01/11/2016 15:02, Wang Weijun wrote: >> HTTP Negotiate uses >> >> Class.forName("sun.net.www.protocol.http.spnego.NegotiatorImpl", true, null); >> >> to check if the implementation in java.security.jgss module is provided. It looks like this call is throwing a ClassNotFoundException now. Shall I export the package to java.base or is there any other trick? I remember there used to be an addReads method but seems no one is using it now. >> >> Or I must use a service loader? >> > This is just visibility. The jdk.security.jgss module is defined to the platform class loader but but you have specified "null" (= bootstrap class loader) to Class.forName. Wow. I changed it to ClassLoaders.platformClassLoader() and it runs. > > There is an issue in JIRA to track change the HTTP protocol handler to use services for authentication mechanism, I don't think anyone has had time to work on that yet. So before making this big change, do you think I can make the small change above to make them at least start working? Thanks Max > > -Alan. From weijun.wang at oracle.com Tue Nov 1 15:29:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 1 Nov 2016 23:29:28 +0800 Subject: How to check for an internal class in another module from java.base? In-Reply-To: References: <14804650-21DC-438A-A62A-A8D3C2225DA1@oracle.com> <57ebb2f7-bb98-b831-e20f-b28b308a6528@oracle.com> Message-ID: <57453630-B3CF-4CC4-B429-3A59286F8ACB@oracle.com> > On Nov 1, 2016, at 11:18 PM, Wang Weijun wrote: > > >> On Nov 1, 2016, at 11:10 PM, Alan Bateman wrote: >> >> >> >> On 01/11/2016 15:02, Wang Weijun wrote: >>> HTTP Negotiate uses >>> >>> Class.forName("sun.net.www.protocol.http.spnego.NegotiatorImpl", true, null); >>> >>> to check if the implementation in java.security.jgss module is provided. It looks like this call is throwing a ClassNotFoundException now. Shall I export the package to java.base or is there any other trick? I remember there used to be an addReads method but seems no one is using it now. >>> >>> Or I must use a service loader? >>> >> This is just visibility. The jdk.security.jgss module is defined to the platform class loader but but you have specified "null" (= bootstrap class loader) to Class.forName. > > Wow. I changed it to ClassLoaders.platformClassLoader() and it runs. > >> >> There is an issue in JIRA to track change the HTTP protocol handler to use services for authentication mechanism, I don't think anyone has had time to work on that yet. > > So before making this big change, do you think I can make the small change above to make them at least start working? i forgot i also exported the internal package to java.base. that is ugly. thanks max p.s. have to use only hand so the other hand can grab my daughter. > > Thanks > Max > >> >> -Alan. > From blackdrag at gmx.org Tue Nov 1 15:32:41 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 1 Nov 2016 16:32:41 +0100 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <156662487.293903.1478013425974.JavaMail.zimbra@u-pem.fr> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <156662487.293903.1478013425974.JavaMail.zimbra@u-pem.fr> Message-ID: <39493277-b503-ff1d-687a-794f757cb9ef@gmx.org> I must say I am partially to the whole story. My main problem is code I do not have under control, but suddenly need "extended" rights for. If this comes from a another module I will have by default no chance of doing this anymore because of #AwkwardStrongEncapsulation. This proposal shows a way around it, but only if I instrument or otherwise transform the bytecode to add the annotation. If I have that level of control I can do all sorts of things. My simple problem here is, that this may work for a framework you program against, but not for a library that happens to have to process the class without the class knowing anything about that library. And normally you do not want to have a bytecode/class transformer, just to use the library properly. Not to mention, that the point of time in which you get a hold on the object, it might be much too late to do any modifications to the class.... Well... it makes me ask the question: Does #AwkwardStrongEncapsulation impose additional limitations for the redefinition of already loaded classes? bye Jochen From david.lloyd at redhat.com Tue Nov 1 15:35:42 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 1 Nov 2016 10:35:42 -0500 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> Message-ID: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> On 11/01/2016 10:09 AM, Andrew Dinn wrote: > On 01/11/16 14:39, David M. Lloyd wrote: >> On 11/01/2016 09:23 AM, John Rose wrote: >>> On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote: >>>> >>>> Can we clarify "privileged code"? Privileged like in a >>>> SecurityManager in a PrivilegedAction for example, for privileged >>>> like only jdk internal code? Just to see it black on white ;) >>> >>> Good question: I mean the basic JDK platform implementation. >>> Something deep in java.base. Like Unsafe. >> >> I don't see why this can't be a "regular" API though, rather than a >> super-user sledgehammer every single time. If user code can be >> statically granted access, and that user code can deliberately acquire a >> narrowly-scoped object which can access those Lookups/*Handles, then >> isn't that better than using Unsafe, which not only represents >> unrestricted system-wide access, but can undermine even the JVM's >> integrity if leaked? > > If making this a 'regular' API means allowing any code to use it then > that clearly undermines /all/ the access restrictions provided by > modules. The point is not to unlock all doors in the castle but to open > doors for trusted code when needed (and only then). Maybe I wasn't clear; I was suggesting that any code be able to use the API, but only to access things which were explicitly granted. I'm suggesting *less* access, not *more*. Saying "suitably privileged" and "Unsafe" seems sufficient until you realize that many many frameworks will need this API, which means they will need Unsafe, which means they will *get* Unsafe (one way or another), which is certainly a far more dangerous thing to have floating around than (say) a Lookup that has access to a few specific private members. > There is a very easy way to provide tightly controlled access to a > framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. > java.lang.[invoke].MethodHandles to a nominated module provided by your > framework then arrange for that module to hand out Lookups (or better > MethodHandles) to framework code as and when they are needed via a > private channel. You can do arrange that with a single addExports option > on the command line and a very small amount of setup code to establish > the private channel I don't see how this is safer though. You're proposing to hand all the keys (or none) to modules which don't need all the keys, whereas I propose that a module should only gain incremental additional access on a grant basis. At least R?mi's approach requires a specific grant and non-Unsafe vector, though as I said the weaknesses (of his first approach) are that the grant must come from the target class (programmatically) instead of being a static declaration ("opens" is a natural fit for this if I understand the proposal correctly). The other weakness is that it requires class init, but that's purely a consequence of requiring a programmatic grant as far as I understand. R?mi's newest Gist uses an annotation, which is closer but not quite on the target IMO. An annotation cannot be module-deployment-agnostic in the way that I outlined previously (hence #IndirectQualifiedReflectiveAccess); ultimately accessibility information ought to come from the module configuration itself. -- - DML From Alan.Bateman at oracle.com Tue Nov 1 15:44:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 15:44:31 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <39493277-b503-ff1d-687a-794f757cb9ef@gmx.org> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <156662487.293903.1478013425974.JavaMail.zimbra@u-pem.fr> <39493277-b503-ff1d-687a-794f757cb9ef@gmx.org> Message-ID: <3c096e6c-2b7d-1e62-f194-2b940c105ab8@oracle.com> On 01/11/2016 15:32, Jochen Theodorou wrote: > : > > Well... it makes me ask the question: Does #AwkwardStrongEncapsulation > impose additional limitations for the redefinition of already loaded > classes? No but if the methods in the new class redefinition are doing setAccessible then it's same checks as would happen if the original class bytes did the same thing. -Alan From Alan.Bateman at oracle.com Tue Nov 1 15:46:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 15:46:45 +0000 Subject: How to check for an internal class in another module from java.base? In-Reply-To: <57453630-B3CF-4CC4-B429-3A59286F8ACB@oracle.com> References: <14804650-21DC-438A-A62A-A8D3C2225DA1@oracle.com> <57ebb2f7-bb98-b831-e20f-b28b308a6528@oracle.com> <57453630-B3CF-4CC4-B429-3A59286F8ACB@oracle.com> Message-ID: <6db90456-755f-29e9-da2b-5f9389b749e8@oracle.com> On 01/11/2016 15:29, Wang Weijun wrote: > : >>> There is an issue in JIRA to track change the HTTP protocol handler to use services for authentication mechanism, I don't think anyone has had time to work on that yet. >> So before making this big change, do you think I can make the small change above to make them at least start working? > i forgot i also exported the internal package to java.base. that is ugly. > > If this code is changed to use services then the qualified export would not be needed. -Alan. From blackdrag at gmx.org Tue Nov 1 15:55:38 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 1 Nov 2016 16:55:38 +0100 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <3c096e6c-2b7d-1e62-f194-2b940c105ab8@oracle.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <156662487.293903.1478013425974.JavaMail.zimbra@u-pem.fr> <39493277-b503-ff1d-687a-794f757cb9ef@gmx.org> <3c096e6c-2b7d-1e62-f194-2b940c105ab8@oracle.com> Message-ID: <93290119-0fe8-a33c-6363-f00b4796c2e0@gmx.org> On 01.11.2016 16:44, Alan Bateman wrote: > > > On 01/11/2016 15:32, Jochen Theodorou wrote: >> : >> >> Well... it makes me ask the question: Does #AwkwardStrongEncapsulation >> impose additional limitations for the redefinition of already loaded >> classes? > No but if the methods in the new class redefinition are doing > setAccessible then it's same checks as would happen if the original > class bytes did the same thing. If I got Remi's proposal right, I would "only" have to add the annotation on the class by instrumentation to gain access, no need for setAccessible bye Jochen From adinn at redhat.com Tue Nov 1 16:02:37 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 1 Nov 2016 16:02:37 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> Message-ID: <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> On 01/11/16 15:35, David M. Lloyd wrote: > On 11/01/2016 10:09 AM, Andrew Dinn wrote: >> There is a very easy way to provide tightly controlled access to a >> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. >> java.lang.[invoke].MethodHandles to a nominated module provided by your >> framework then arrange for that module to hand out Lookups (or better >> MethodHandles) to framework code as and when they are needed via a >> private channel. You can do arrange that with a single addExports option >> on the command line and a very small amount of setup code to establish >> the private channel > > I don't see how this is safer though. You're proposing to hand all the > keys (or none) to modules which don't need all the keys, whereas I > propose that a module should only gain incremental additional access on > a grant basis. No, I'm suggesting handing the keys to a single module provided by your framework -- which module will then use a key to open a room on demand for your code and your code only. That means the privilege can be granted using one command line switch with use of that privilege controlled by a runtime mechanism of your choosing. > At least R?mi's approach requires a specific grant and non-Unsafe > vector, though as I said the weaknesses (of his first approach) are that > the grant must come from the target class (programmatically) instead of > being a static declaration ("opens" is a natural fit for this if I > understand the proposal correctly). The other weakness is that it > requires class init, but that's purely a consequence of requiring a > programmatic grant as far as I understand. I did actually suggest a way of avoiding the use of Unsafe. You give your nominated module full reflective access to java.lang.invoke allowing it to create Lookup instances (it can actually just create a single all privileges lookup and use this to clone others). You don't need to insert a class into java.lang.invoke to do this. You simply add one exports directive on the command line. > R?mi's newest Gist uses an annotation, which is closer but not quite on > the target IMO. An annotation cannot be module-deployment-agnostic in > the way that I outlined previously (hence > #IndirectQualifiedReflectiveAccess); ultimately accessibility > information ought to come from the module configuration itself. If you implement a module with the ability to hand out Lookup instances you can use whatever control model you like. For example, you might park an instance which hands out Lookups in a location only available to your framework or ensure that any caller asking for a Lookup belongs in a package implemented by your framework or whatever you want. the point is that once you have granted a class in our code the ability to create Lookups you can implement whatever runtime access control you want. Clearly,as John said, you need to do that responsibly. 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 steve.drach at oracle.com Tue Nov 1 16:16:55 2016 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 1 Nov 2016 09:16:55 -0700 Subject: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs In-Reply-To: <1563478E-5C73-4CA8-94E0-C1098B006058@oracle.com> References: <8A189B47-213D-42D9-86F0-F46D580252B6@oracle.com> <22EEC3EC-ED41-4C61-B0F3-B48EC5A54DE1@oracle.com> <25FB0E59-E2CD-4D9A-A60B-15357E145A51@oracle.com> <94b878e9-8006-bcc7-9aaa-15e0b3ad181f@oracle.com> <714F96B8-5152-439B-A4DA-34E0FBEF4ADB@oracle.com> <56e8d3f7-070e-5e2e-4117-1d7879dbd668@oracle.com> <999B3AA4-F218-4866-A28B-DA5E2A4FA493@oracle.com> <960EB41A-0708-4C5B-9CC0-3C6FCB8965B0@oracle.com> <1563478E-5C73-4CA8-94E0-C1098B006058@oracle.com> Message-ID: >>> I?ve put out another webrev, http://cr.openjdk.java.net/~sdrach/8156499/webrev.05/, that addresses Mandy?s concerns. In particular I demonstrate that the resultant image is ?runnable? and that a Main class in the image can/cannot find the java.logging module when the module-info.class is changed to require java.logging in one case but not in the other. >> >> Looks okay in general. The jlink change looks correct. Thanks for updating the test. > > In fact - does this test run on windows? > > 239 Path java = Paths.get(image, "bin", "java?); > > On windows, shouldn?t this need to be ?java.exe?? I haven?t run it on jprt yet, but I?ll note that tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest does the same thing (finds java, not java.exe) and has apparently been run on windows many times. If jprt turns up an error here, I?ll fix it. From alexandre.iline at oracle.com Tue Nov 1 17:31:57 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 1 Nov 2016 10:31:57 -0700 Subject: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments. In-Reply-To: References: <94D737C6-A265-4657-B93E-4A2271617D27@oracle.com> <955f21c4-8d21-1186-f623-477356236a20@oracle.com> <3FCA900B-3A27-4E43-84C3-09789B25B813@oracle.com> <580936aa-3f94-1904-439e-5440cfc81e43@oracle.com> <383FAF53-1678-4685-9888-0F7A0A71BD4C@oracle.com> <1AC8A30B-B5B5-489E-97E5-FC1C3C1F70B4@oracle.com> <894b5aa6-100e-f819-8cfe-fce7096f6e84@oracle.com> Message-ID: Alan, For me, having module and package parameters separate makes it a lot easier: public JavaTask addExports(String module, String package, String? targetModules) Consider this: .addExports(JAVA_BASE, JDK_MISC, ALL_UNNAMED) where, needless to say, JAVA_BASE and JDK_MISC are constants defined in the test, or, perhaps, library class and presumably used in other cases. To me, this is better for obvious reasons, such as code completion in IDE and compile-time control over the mistakes. I also will be able to avoid concatenation all over the code: .addExports(JAVA_BASE + ?/? + JDK_MISC, ALL_UNNAMED) Similarly, for the same reasons, I prefer .addExports(JAVA_BASE, JDK_MISC, M1, M2) What do others think? To get everybody on the same page, we are discussing this webrev, which is introducing new task builder API to the JDK test library: http://cr.openjdk.java.net/~shurailine/8159523/webrev.04 This is the review request: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009627.html Shura > On Nov 1, 2016, at 3:26 AM, Alan Bateman wrote: > > > > On 01/11/2016 10:23, Alan Bateman wrote: >> : >> >> .addExports("java.base", "jdk.internal.misc=ALL-UNNAMED") >> .addOpens("java.base", "jdk.internal.misc=m1,m2") > Oops, a typo here, I meant this of course: > > .addExports("java.base/jdk.internal.misc", "ALL-UNNAMED") > .addOpens("java.base/jdk.internal.misc", m1,m2") > > -Alan. From Alan.Bateman at oracle.com Tue Nov 1 19:52:50 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 19:52:50 +0000 Subject: JDK 9 Early Access with Project Jigsaw, build 142 on 10-31-2016 (#5670) Message-ID: <684e5e5a-23c7-3deb-2690-6192845de0c3@oracle.com> Just a quick mail to say that the EA download [1] has been refreshed. The latest download has the initial implementation of open modules and open packages as detailed in the recent proposal for #ReflectiveAccessToNonExportedTypes [2]. -Alan [1] https://jdk9.java.net/jigsaw/ [2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html From david.lloyd at redhat.com Tue Nov 1 20:00:35 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 1 Nov 2016 15:00:35 -0500 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> Message-ID: <90901a80-6876-e2bd-24e3-52cf39b06838@redhat.com> On 11/01/2016 11:02 AM, Andrew Dinn wrote: > On 01/11/16 15:35, David M. Lloyd wrote: >> On 11/01/2016 10:09 AM, Andrew Dinn wrote: >>> There is a very easy way to provide tightly controlled access to a >>> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. >>> java.lang.[invoke].MethodHandles to a nominated module provided by your >>> framework then arrange for that module to hand out Lookups (or better >>> MethodHandles) to framework code as and when they are needed via a >>> private channel. You can do arrange that with a single addExports option >>> on the command line and a very small amount of setup code to establish >>> the private channel >> >> I don't see how this is safer though. You're proposing to hand all the >> keys (or none) to modules which don't need all the keys, whereas I >> propose that a module should only gain incremental additional access on >> a grant basis. > > No, I'm suggesting handing the keys to a single module provided by your > framework -- which module will then use a key to open a room on demand > for your code and your code only. That means the privilege can be > granted using one command line switch with use of that privilege > controlled by a runtime mechanism of your choosing. Yes, however that means that I'm on the hook to make sure that the keys aren't mislaid. And given the fact of open modules - which already semantically grants me privileges - requiring a special command line switch (which is itself undesirable) and custom code to enable those privileges in the *preferred* manner (i.e. MethodHandles) seems backwards when open modules would already grant me the ability to utilize a much finer instrument albeit with the legacy approach (i.e. reflection). It seems quite logical to extend this mechanism to the preferred MethodHandle approach instead, and forget about Unsafe and anything like it, which I think is in everyone's best interests in the long term. >> At least R?mi's approach requires a specific grant and non-Unsafe >> vector, though as I said the weaknesses (of his first approach) are that >> the grant must come from the target class (programmatically) instead of >> being a static declaration ("opens" is a natural fit for this if I >> understand the proposal correctly). The other weakness is that it >> requires class init, but that's purely a consequence of requiring a >> programmatic grant as far as I understand. > > I did actually suggest a way of avoiding the use of Unsafe. You give > your nominated module full reflective access to java.lang.invoke > allowing it to create Lookup instances (it can actually just create a > single all privileges lookup and use this to clone others). You don't > need to insert a class into java.lang.invoke to do this. You simply add > one exports directive on the command line. That is marginally better, of course, but I think the rest of my objections still stand against this argument. >> R?mi's newest Gist uses an annotation, which is closer but not quite on >> the target IMO. An annotation cannot be module-deployment-agnostic in >> the way that I outlined previously (hence >> #IndirectQualifiedReflectiveAccess); ultimately accessibility >> information ought to come from the module configuration itself. > > If you implement a module with the ability to hand out Lookup instances > you can use whatever control model you like. For example, you might park > an instance which hands out Lookups in a location only available to your > framework or ensure that any caller asking for a Lookup belongs in a > package implemented by your framework or whatever you want. the point is > that once you have granted a class in our code the ability to create > Lookups you can implement whatever runtime access control you want. > Clearly,as John said, you need to do that responsibly. > > 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 > -- - DML From steve.drach at oracle.com Tue Nov 1 21:44:58 2016 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 1 Nov 2016 14:44:58 -0700 Subject: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs In-Reply-To: <1563478E-5C73-4CA8-94E0-C1098B006058@oracle.com> References: <8A189B47-213D-42D9-86F0-F46D580252B6@oracle.com> <22EEC3EC-ED41-4C61-B0F3-B48EC5A54DE1@oracle.com> <25FB0E59-E2CD-4D9A-A60B-15357E145A51@oracle.com> <94b878e9-8006-bcc7-9aaa-15e0b3ad181f@oracle.com> <714F96B8-5152-439B-A4DA-34E0FBEF4ADB@oracle.com> <56e8d3f7-070e-5e2e-4117-1d7879dbd668@oracle.com> <999B3AA4-F218-4866-A28B-DA5E2A4FA493@oracle.com> <960EB41A-0708-4C5B-9CC0-3C6FCB8965B0@oracle.com> <1563478E-5C73-4CA8-94E0-C1098B006058@oracle.com> Message-ID: >>> I?ve put out another webrev, http://cr.openjdk.java.net/~sdrach/8156499/webrev.05/, that addresses Mandy?s concerns. In particular I demonstrate that the resultant image is ?runnable? and that a Main class in the image can/cannot find the java.logging module when the module-info.class is changed to require java.logging in one case but not in the other. >> >> Looks okay in general. The jlink change looks correct. Thanks for updating the test. > > In fact - does this test run on windows? > > 239 Path java = Paths.get(image, "bin", "java?); > > On windows, shouldn?t this need to be ?java.exe?? It turns out it runs just fine on the jprt windows test. From mandy.chung at oracle.com Tue Nov 1 21:48:25 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 1 Nov 2016 14:48:25 -0700 Subject: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs In-Reply-To: References: <8A189B47-213D-42D9-86F0-F46D580252B6@oracle.com> <22EEC3EC-ED41-4C61-B0F3-B48EC5A54DE1@oracle.com> <25FB0E59-E2CD-4D9A-A60B-15357E145A51@oracle.com> <94b878e9-8006-bcc7-9aaa-15e0b3ad181f@oracle.com> <714F96B8-5152-439B-A4DA-34E0FBEF4ADB@oracle.com> <56e8d3f7-070e-5e2e-4117-1d7879dbd668@oracle.com> <999B3AA4-F218-4866-A28B-DA5E2A4FA493@oracle.com> <960EB41A-0708-4C5B-9CC0-3C6FCB8965B0@oracle.com> <1563478E-5C73-4CA8-94E0-C1098B006058@oracle.com> Message-ID: <810A100C-753D-49A7-8CA4-69DA2FE3F72E@oracle.com> > On Nov 1, 2016, at 2:44 PM, Steve Drach wrote: > > >>>> I?ve put out another webrev, http://cr.openjdk.java.net/~sdrach/8156499/webrev.05/, that addresses Mandy?s concerns. In particular I demonstrate that the resultant image is ?runnable? and that a Main class in the image can/cannot find the java.logging module when the module-info.class is changed to require java.logging in one case but not in the other. >>> >>> Looks okay in general. The jlink change looks correct. Thanks for updating the test. >> >> In fact - does this test run on windows? >> >> 239 Path java = Paths.get(image, "bin", "java?); >> >> On windows, shouldn?t this need to be ?java.exe?? > > It turns out it runs just fine on the jprt windows test. Thanks. So good to go. Mandy From forax at univ-mlv.fr Tue Nov 1 22:59:01 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 Nov 2016 23:59:01 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <90901a80-6876-e2bd-24e3-52cf39b06838@redhat.com> References: <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <90901a80-6876-e2bd-24e3-52cf39b06838@redhat.com> Message-ID: <797580037.386017.1478041141107.JavaMail.zimbra@u-pem.fr> Iteration 3, https://gist.github.com/forax/c08ce0a8dc88705bce97b17b63e7e2d5 GrantAccess can now be put on a class, on a package or on a module, and give access to several frameworks by their names. Getting access to the lookup of a class is now a 2 steps process, first claim a framework name to get an AccessFacade and then through the AccessFacade, a framework have access to all classes annotated (directly or indirectly) by GrantAccess and allowing the framework. The facade corresponding to a framework name can only be requested once so how to store the FacadeAccess is let to the framework implementation and if a code try to sneak in and use a framework name it will be detected. R?mi ----- Mail original ----- > De: "David M. Lloyd" > ?: "Andrew Dinn" , jigsaw-dev at openjdk.java.net > Envoy?: Mardi 1 Novembre 2016 21:00:35 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages > On 11/01/2016 11:02 AM, Andrew Dinn wrote: >> On 01/11/16 15:35, David M. Lloyd wrote: >>> On 11/01/2016 10:09 AM, Andrew Dinn wrote: >>>> There is a very easy way to provide tightly controlled access to a >>>> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. >>>> java.lang.[invoke].MethodHandles to a nominated module provided by your >>>> framework then arrange for that module to hand out Lookups (or better >>>> MethodHandles) to framework code as and when they are needed via a >>>> private channel. You can do arrange that with a single addExports option >>>> on the command line and a very small amount of setup code to establish >>>> the private channel >>> >>> I don't see how this is safer though. You're proposing to hand all the >>> keys (or none) to modules which don't need all the keys, whereas I >>> propose that a module should only gain incremental additional access on >>> a grant basis. >> >> No, I'm suggesting handing the keys to a single module provided by your >> framework -- which module will then use a key to open a room on demand >> for your code and your code only. That means the privilege can be >> granted using one command line switch with use of that privilege >> controlled by a runtime mechanism of your choosing. > > Yes, however that means that I'm on the hook to make sure that the keys > aren't mislaid. And given the fact of open modules - which already > semantically grants me privileges - requiring a special command line > switch (which is itself undesirable) and custom code to enable those > privileges in the *preferred* manner (i.e. MethodHandles) seems > backwards when open modules would already grant me the ability to > utilize a much finer instrument albeit with the legacy approach (i.e. > reflection). It seems quite logical to extend this mechanism to the > preferred MethodHandle approach instead, and forget about Unsafe and > anything like it, which I think is in everyone's best interests in the > long term. > >>> At least R?mi's approach requires a specific grant and non-Unsafe >>> vector, though as I said the weaknesses (of his first approach) are that >>> the grant must come from the target class (programmatically) instead of >>> being a static declaration ("opens" is a natural fit for this if I >>> understand the proposal correctly). The other weakness is that it >>> requires class init, but that's purely a consequence of requiring a >>> programmatic grant as far as I understand. >> >> I did actually suggest a way of avoiding the use of Unsafe. You give >> your nominated module full reflective access to java.lang.invoke >> allowing it to create Lookup instances (it can actually just create a >> single all privileges lookup and use this to clone others). You don't >> need to insert a class into java.lang.invoke to do this. You simply add >> one exports directive on the command line. > > That is marginally better, of course, but I think the rest of my > objections still stand against this argument. > >>> R?mi's newest Gist uses an annotation, which is closer but not quite on >>> the target IMO. An annotation cannot be module-deployment-agnostic in >>> the way that I outlined previously (hence >>> #IndirectQualifiedReflectiveAccess); ultimately accessibility >>> information ought to come from the module configuration itself. >> >> If you implement a module with the ability to hand out Lookup instances >> you can use whatever control model you like. For example, you might park >> an instance which hands out Lookups in a location only available to your >> framework or ensure that any caller asking for a Lookup belongs in a >> package implemented by your framework or whatever you want. the point is >> that once you have granted a class in our code the ability to create >> Lookups you can implement whatever runtime access control you want. >> Clearly,as John said, you need to do that responsibly. >> >> 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 >> > > -- > - DML From mandy.chung at oracle.com Tue Nov 1 23:42:18 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 1 Nov 2016 16:42:18 -0700 Subject: Request Review: JDK-6479237 (cl) Add support for classloader names In-Reply-To: <237186f1-13b4-5a94-099d-cf1f07e7b120@oracle.com> References: <2C30243B-71D2-49E2-A8B6-2C33B82DB104@oracle.com> <5d494d3a-f8ec-0456-8d04-f8998d840fc7@oracle.com> <52E8F822-2D4E-4BD7-BE4E-748E47901625@oracle.com> <931BF9A2-6F22-48FF-855E-287BAF10FDC0@oracle.com> <237186f1-13b4-5a94-099d-cf1f07e7b120@oracle.com> Message-ID: <82595580-6100-4F6C-905C-3061D3AE43C6@oracle.com> Hi Daniel, Here is the updated webrev incorporating your feedback: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.03 > On Nov 1, 2016, at 7:04 AM, Daniel Fuchs wrote: > > : > 334 s += declaringClass; > > > but should line 334 instead be > > s = (s.isEmpty() ? declaringClass : s + "/" + declaringClass; > > Otherwise "/" will be missing after module at version.. > Good catch. I added a test for this. > Also should there be some asserts somewhere verifying that moduleVersion > is null or empty when moduleName is null or empty? At the moment the > constructor will blindly accept a version for an unnamed module, > and I am assuming this is wrong - am I right? > Good point. The constructor should throw IAE if module name/version and class loader name is an empty string. > toLoaderModuleClassName will call ClassLoader.getName(). > If a class loader overrides getName() then that might be a different > name than what StackTraceElement.getClassLoaderName() returns. > > Is that an issue? > I added a test to verify StackTraceElement that uses the ClassLoader's name field. I also added @apiNote in ClassLoader::getName. > Also I wonder whether you should be considering including a fix > for https://bugs.openjdk.java.net/browse/JDK-8167099 as part > of this change (though arguably the bug has been there since > new fields were added to StackTraceElement in 9). > It is related but it?s better to separate it from this issue. Do you have cycle to help write a test case? I can help fix JDK-8167099 later. Mandy From john.r.rose at oracle.com Wed Nov 2 01:58:08 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Nov 2016 21:58:08 -0400 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> Message-ID: On Nov 1, 2016, at 12:02 PM, Andrew Dinn wrote: > > I did actually suggest a way of avoiding the use of Unsafe. You give > your nominated module full reflective access to java.lang.invoke > allowing it to create Lookup instances (it can actually just create a > single all privileges lookup and use this to clone others). You don't > need to insert a class into java.lang.invoke to do this. You simply add > one exports directive on the command line. The weak link in this otherwise robust scheme is the use of a command line option to break into the jli package. Breaking in by the back door is awkward and might not deliver the desired Lookup if jli code changes. And it probably will, over time. Using the break-in is a good Proof of concept but the finished product needs to use a real API provided by the JDK, and using a wormhole Lookup actually provided by a cooperating jli. I look forward to such a thing in a future JDK. Perhaps the right surface shape for moderate reflection is Maurizios "reflection manifesto" API, which is completely interface driven. This means a meta-CE with full deep access could mock up a "reflection manifesto" implementation which would expose exactly the right moderate surface area, as negotiated with the target module. Just an idea? ? John From peter.levart at gmail.com Wed Nov 2 10:31:04 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 2 Nov 2016 11:31:04 +0100 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <797580037.386017.1478041141107.JavaMail.zimbra@u-pem.fr> References: <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <90901a80-6876-e2bd-24e3-52cf39b06838@redhat.com> <797580037.386017.1478041141107.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, On 11/01/2016 11:59 PM, Remi Forax wrote: > Iteration 3, > https://gist.github.com/forax/c08ce0a8dc88705bce97b17b63e7e2d5 > > GrantAccess can now be put on a class, on a package or on a module, and give access to several frameworks by their names. Getting access to the lookup of a class is now a 2 steps process, first claim a framework name to get an AccessFacade and then through the AccessFacade, a framework have access to all classes annotated (directly or indirectly) by GrantAccess and allowing the framework. The facade corresponding to a framework name can only be requested once so how to store the FacadeAccess is let to the framework implementation and if a code try to sneak in and use a framework name it will be detected. > > R?mi Hm, this variant requires the real framework code to race against its impostor(s) for the access facade granted to a particular name. What if an impostor gets it first? In addition, I see a similarity of this approach to simply "opening" the required packages of the "granting" module to a chosen "granted" module (i.e. the "hibernate") in the granting module declaration. At least the module name is harder to "spoof" as it is embedded in the module search path layout. But I get the point. Instead of "hibernate", the granting module could declare that it gives access to a "jpa" framework, which is a more general name that several implementations could claim. But I think that they should not simply claim the name and get it on a first-comes basis. What about introducing a general registry of: (module name -> access name) mappings controlled by privileged code or some policy? The problem I see is a problem of choosing the names in general as they get to be hard-coded in the code or declaration of the granting module. Who chooses that "jpa" is the name of the JPA framework? Module names are chosen by their authors. There has to be a module 1st and then one can "require" it. OTOH there has to be a general agreement on the "access name" among several authors of the modules that claim that name. And this requires a central name registry like IANA. And that's not something jigsaw is going to dive into. I tried to tackle the issue from another perspective. If you ask yourself what is common to all JPA framework implementations, for example, then the answer is: they all implement the same API (in the form of interface(s) or abstract classes). This API will usually be a module by itself. 1st there has to be an API module with the agreed-upon API and then the authors can produce implementation modules (hibernate, eclipse-link, ...). So I thought that the name of the API module could be used as the "access name" of the grant and every implementation module that could prove it contains the implementation of this API would inherit the grant. Ideally, but not necessarily, services and providers could be leveraged in the implementation. The mechanism could be "secured" on a service-by-service basis using SecurityManager permission(s) like it is done today (the security check is put into the constructor(s) of the abstract service class) so that impostor(s) are kept back. Regards, Peter > ----- Mail original ----- >> De: "David M. Lloyd" >> ?: "Andrew Dinn" , jigsaw-dev at openjdk.java.net >> Envoy?: Mardi 1 Novembre 2016 21:00:35 >> Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages >> On 11/01/2016 11:02 AM, Andrew Dinn wrote: >>> On 01/11/16 15:35, David M. Lloyd wrote: >>>> On 11/01/2016 10:09 AM, Andrew Dinn wrote: >>>>> There is a very easy way to provide tightly controlled access to a >>>>> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. >>>>> java.lang.[invoke].MethodHandles to a nominated module provided by your >>>>> framework then arrange for that module to hand out Lookups (or better >>>>> MethodHandles) to framework code as and when they are needed via a >>>>> private channel. You can do arrange that with a single addExports option >>>>> on the command line and a very small amount of setup code to establish >>>>> the private channel >>>> I don't see how this is safer though. You're proposing to hand all the >>>> keys (or none) to modules which don't need all the keys, whereas I >>>> propose that a module should only gain incremental additional access on >>>> a grant basis. >>> No, I'm suggesting handing the keys to a single module provided by your >>> framework -- which module will then use a key to open a room on demand >>> for your code and your code only. That means the privilege can be >>> granted using one command line switch with use of that privilege >>> controlled by a runtime mechanism of your choosing. >> Yes, however that means that I'm on the hook to make sure that the keys >> aren't mislaid. And given the fact of open modules - which already >> semantically grants me privileges - requiring a special command line >> switch (which is itself undesirable) and custom code to enable those >> privileges in the *preferred* manner (i.e. MethodHandles) seems >> backwards when open modules would already grant me the ability to >> utilize a much finer instrument albeit with the legacy approach (i.e. >> reflection). It seems quite logical to extend this mechanism to the >> preferred MethodHandle approach instead, and forget about Unsafe and >> anything like it, which I think is in everyone's best interests in the >> long term. >> >>>> At least R?mi's approach requires a specific grant and non-Unsafe >>>> vector, though as I said the weaknesses (of his first approach) are that >>>> the grant must come from the target class (programmatically) instead of >>>> being a static declaration ("opens" is a natural fit for this if I >>>> understand the proposal correctly). The other weakness is that it >>>> requires class init, but that's purely a consequence of requiring a >>>> programmatic grant as far as I understand. >>> I did actually suggest a way of avoiding the use of Unsafe. You give >>> your nominated module full reflective access to java.lang.invoke >>> allowing it to create Lookup instances (it can actually just create a >>> single all privileges lookup and use this to clone others). You don't >>> need to insert a class into java.lang.invoke to do this. You simply add >>> one exports directive on the command line. >> That is marginally better, of course, but I think the rest of my >> objections still stand against this argument. >> >>>> R?mi's newest Gist uses an annotation, which is closer but not quite on >>>> the target IMO. An annotation cannot be module-deployment-agnostic in >>>> the way that I outlined previously (hence >>>> #IndirectQualifiedReflectiveAccess); ultimately accessibility >>>> information ought to come from the module configuration itself. >>> If you implement a module with the ability to hand out Lookup instances >>> you can use whatever control model you like. For example, you might park >>> an instance which hands out Lookups in a location only available to your >>> framework or ensure that any caller asking for a Lookup belongs in a >>> package implemented by your framework or whatever you want. the point is >>> that once you have granted a class in our code the ability to create >>> Lookups you can implement whatever runtime access control you want. >>> Clearly,as John said, you need to do that responsibly. >>> >>> 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 >>> >> -- >> - DML From daniel.fuchs at oracle.com Wed Nov 2 11:29:30 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Nov 2016 11:29:30 +0000 Subject: Request Review: JDK-6479237 (cl) Add support for classloader names In-Reply-To: <82595580-6100-4F6C-905C-3061D3AE43C6@oracle.com> References: <2C30243B-71D2-49E2-A8B6-2C33B82DB104@oracle.com> <5d494d3a-f8ec-0456-8d04-f8998d840fc7@oracle.com> <52E8F822-2D4E-4BD7-BE4E-748E47901625@oracle.com> <931BF9A2-6F22-48FF-855E-287BAF10FDC0@oracle.com> <237186f1-13b4-5a94-099d-cf1f07e7b120@oracle.com> <82595580-6100-4F6C-905C-3061D3AE43C6@oracle.com> Message-ID: <2392ca27-b110-ce1c-0cc7-38447e575756@oracle.com> Hi Mandy, On 01/11/16 23:42, Mandy Chung wrote: > Hi Daniel, > > Here is the updated webrev incorporating your feedback: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.03 ClassLoader.java: 345 if (name != null && name.isEmpty()) { 346 throw new IllegalArgumentException("name must be non-empty or null"); 347 } I'd suggest passing 'name' to 'checkCreateClassLoader()' and do this check in checkCreateClassLoader instead - in order to do the checks before 'this' is created. [...] >> Also should there be some asserts somewhere verifying that moduleVersion >> is null or empty when moduleName is null or empty? At the moment the >> constructor will blindly accept a version for an unnamed module, >> and I am assuming this is wrong - am I right? >> > > Good point. The constructor should throw IAE if module name/version and class loader name is an empty string. That's not exactly what I had in mind. I don't have any particular feeling for whether "" should be allowed or not. Maybe it would be simpler to just allow "" to mean the same thing as 'null'. What I meant was: Can moduleVersion be non null (and non empty) if moduleName is null (or empty)? In other words can an unnamed module have a version? Also if you add some validation to the constructor then you will need to add a readObject to duplicate the validation checks. And if you disallow "" then checking for isEmpty() in toString() is not needed. But I have the feeling that simply allowing "" and null to mean the same thing would be more robust. It's just the question of having a moduleVersion for an unnamed module that bothers me. >> toLoaderModuleClassName will call ClassLoader.getName(). >> If a class loader overrides getName() then that might be a different >> name than what StackTraceElement.getClassLoaderName() returns. >> >> Is that an issue? >> > > I added a test to verify StackTraceElement that uses the ClassLoader's name field. I also added @apiNote in ClassLoader::getName. Ok - the @apiNote should cover that. >> Also I wonder whether you should be considering including a fix >> for https://bugs.openjdk.java.net/browse/JDK-8167099 as part >> of this change (though arguably the bug has been there since >> new fields were added to StackTraceElement in 9). >> > > It is related but it?s better to separate it from this issue. Do you have cycle to help write a test case? I can help fix JDK-8167099 later. Right - no problem with that. I haven't given any thought to a test case for JDK-8167099. I believe it will prevent to connect a JDK 9 jvisualvm to a JDK 8 process if not fixed though. Maybe serializing a ThreadInfo composite data containing some MonitorInfo in JDK 8, and then deserializing that in JDK 9 and trying to convert it back to ThreadInfo in 9 would show the issue. best regards, -- daniel > > Mandy > From forax at univ-mlv.fr Wed Nov 2 13:06:35 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 2 Nov 2016 14:06:35 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <90901a80-6876-e2bd-24e3-52cf39b06838@redhat.com> <797580037.386017.1478041141107.JavaMail.zimbra@u-pem.fr> Message-ID: <332266716.630085.1478091995831.JavaMail.zimbra@u-pem.fr> > De: "Peter Levart" > ?: "Remi Forax" , "David M. Lloyd" > Cc: jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 2 Novembre 2016 11:31:04 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & > open packages > Hi Remi, > On 11/01/2016 11:59 PM, Remi Forax wrote: >> Iteration 3, https://gist.github.com/forax/c08ce0a8dc88705bce97b17b63e7e2d5 >> GrantAccess can now be put on a class, on a package or on a module, and give >> access to several frameworks by their names. Getting access to the lookup of a >> class is now a 2 steps process, first claim a framework name to get an >> AccessFacade and then through the AccessFacade, a framework have access to all >> classes annotated (directly or indirectly) by GrantAccess and allowing the >> framework. The facade corresponding to a framework name can only be requested >> once so how to store the FacadeAccess is let to the framework implementation >> and if a code try to sneak in and use a framework name it will be detected. >> R?mi > Hm, this variant requires the real framework code to race against its > impostor(s) for the access facade granted to a particular name. What if an > impostor gets it first? The idea was if the impostor wins, you will get an exception when the legit framework will try to request the access, and obviously, this is the weak point of this variant. > In addition, I see a similarity of this approach to simply "opening" the > required packages of the "granting" module to a chosen "granted" module (i.e. > the "hibernate") in the granting module declaration. At least the module name > is harder to "spoof" as it is embedded in the module search path layout. But I > get the point. Instead of "hibernate", the granting module could declare that > it gives access to a "jpa" framework, which is a more general name that several > implementations could claim. But I think that they should not simply claim the > name and get it on a first-comes basis. What about introducing a general > registry of: (module name -> access name) mappings controlled by privileged > code or some policy? The problem I see is a problem of choosing the names in > general as they get to be hard-coded in the code or declaration of the granting > module. Who chooses that "jpa" is the name of the JPA framework? Module names > are chosen by their authors. There has to be a module 1st and then one can > "require" it. OTOH there has to be a general agreement on the "access name" > among several authors of the modules that claim that name. And this requires a > central name registry like IANA. And that's not something jigsaw is going to > dive into. > I tried to tackle the issue from another perspective. If you ask yourself what > is common to all JPA framework implementations, for example, then the answer > is: they all implement the same API (in the form of interface(s) or abstract > classes). This API will usually be a module by itself. 1st there has to be an > API module with the agreed-upon API and then the authors can produce > implementation modules (hibernate, eclipse-link, ...). So I thought that the > name of the API module could be used as the "access name" of the grant and > every implementation module that could prove it contains the implementation of > this API would inherit the grant. A nice idea, so iteration 4, you have to provide a lookup of a class inside a module that provide an implementation to the interface used when granting the access https://github.com/forax/access-broker So a code of application using a framework will use @GrantAccess (i've put the annotation on the module of the app just for fun) https://github.com/forax/access-broker/blob/master/src/my.jpa.app/my/jpa/app/Bean.java https://github.com/forax/access-broker/blob/master/src/my.jpa.app/module-info.java and the implementation of the framework will use the AccessBroken to get access to private members of the application code https://github.com/forax/access-broker/blob/master/src/org.hibernate.jpa/org/hibernate/jpa/EntityManagerImpl.java In that case the AccessBroker is the same as the previous iteration but uses Class instead of String to allow a framework and check that the class that requires a privileged access is in a module that implement the interface of the spec https://github.com/forax/access-broker/blob/master/src/java.base/java/lang/invoke/AccessBroker.java > Ideally, but not necessarily, services and providers could be leveraged in the > implementation. The mechanism could be "secured" on a service-by-service basis > using SecurityManager permission(s) like it is done today (the security check > is put into the constructor(s) of the abstract service class) so that > impostor(s) are kept back. > Regards, Peter regards, R?mi >> ----- Mail original ----- >>> De: "David M. Lloyd" ?: "Andrew Dinn" >>> , jigsaw-dev at openjdk.java.net Envoy?: Mardi 1 Novembre 2016 >>> 21:00:35 >>> Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & >>> open packages >>> On 11/01/2016 11:02 AM, Andrew Dinn wrote: >>>> On 01/11/16 15:35, David M. Lloyd wrote: >>>>> On 11/01/2016 10:09 AM, Andrew Dinn wrote: >>>>>> There is a very easy way to provide tightly controlled access to a >>>>>> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. >>>>>> java.lang.[invoke].MethodHandles to a nominated module provided by your >>>>>> framework then arrange for that module to hand out Lookups (or better >>>>>> MethodHandles) to framework code as and when they are needed via a >>>>>> private channel. You can do arrange that with a single addExports option >>>>>> on the command line and a very small amount of setup code to establish >>>>>> the private channel >>>>> I don't see how this is safer though. You're proposing to hand all the >>>>> keys (or none) to modules which don't need all the keys, whereas I >>>>> propose that a module should only gain incremental additional access on >>>>> a grant basis. >>>> No, I'm suggesting handing the keys to a single module provided by your >>>> framework -- which module will then use a key to open a room on demand >>>> for your code and your code only. That means the privilege can be >>>> granted using one command line switch with use of that privilege >>>> controlled by a runtime mechanism of your choosing. >>> Yes, however that means that I'm on the hook to make sure that the keys >>> aren't mislaid. And given the fact of open modules - which already >>> semantically grants me privileges - requiring a special command line >>> switch (which is itself undesirable) and custom code to enable those >>> privileges in the *preferred* manner (i.e. MethodHandles) seems >>> backwards when open modules would already grant me the ability to >>> utilize a much finer instrument albeit with the legacy approach (i.e. >>> reflection). It seems quite logical to extend this mechanism to the >>> preferred MethodHandle approach instead, and forget about Unsafe and >>> anything like it, which I think is in everyone's best interests in the >>> long term. >>>>> At least R?mi's approach requires a specific grant and non-Unsafe >>>>> vector, though as I said the weaknesses (of his first approach) are that >>>>> the grant must come from the target class (programmatically) instead of >>>>> being a static declaration ("opens" is a natural fit for this if I >>>>> understand the proposal correctly). The other weakness is that it >>>>> requires class init, but that's purely a consequence of requiring a >>>>> programmatic grant as far as I understand. >>>> I did actually suggest a way of avoiding the use of Unsafe. You give >>>> your nominated module full reflective access to java.lang.invoke >>>> allowing it to create Lookup instances (it can actually just create a >>>> single all privileges lookup and use this to clone others). You don't >>>> need to insert a class into java.lang.invoke to do this. You simply add >>>> one exports directive on the command line. >>> That is marginally better, of course, but I think the rest of my >>> objections still stand against this argument. >>>>> R?mi's newest Gist uses an annotation, which is closer but not quite on >>>>> the target IMO. An annotation cannot be module-deployment-agnostic in >>>>> the way that I outlined previously (hence >>>>> #IndirectQualifiedReflectiveAccess); ultimately accessibility >>>>> information ought to come from the module configuration itself. >>>> If you implement a module with the ability to hand out Lookup instances >>>> you can use whatever control model you like. For example, you might park >>>> an instance which hands out Lookups in a location only available to your >>>> framework or ensure that any caller asking for a Lookup belongs in a >>>> package implemented by your framework or whatever you want. the point is >>>> that once you have granted a class in our code the ability to create >>>> Lookups you can implement whatever runtime access control you want. >>>> Clearly,as John said, you need to do that responsibly. >>>> 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 >>> -- >>> - DML From adinn at redhat.com Wed Nov 2 13:25:01 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 2 Nov 2016 13:25:01 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> Message-ID: <4d4ebd9d-7150-425e-4cd4-06281d2b9bcd@redhat.com> On 02/11/16 01:58, John Rose wrote: > On Nov 1, 2016, at 12:02 PM, Andrew Dinn wrote: >> >> I did actually suggest a way of avoiding the use of Unsafe. You >> give your nominated module full reflective access to >> java.lang.invoke allowing it to create Lookup instances (it can >> actually just create a single all privileges lookup and use this to >> clone others). You don't need to insert a class into >> java.lang.invoke to do this. You simply add one exports directive >> on the command line. > > The weak link in this otherwise robust scheme is the use of a command > line option to break into the jli package. Breaking in by the back > door is awkward and might not deliver the desired Lookup if jli code > changes. And it probably will, over time. Using the break-in is a > good Proof of concept but the finished product needs to use a real > API provided by the JDK, and using a wormhole Lookup actually > provided by a cooperating jli. I look forward to such a thing in a > future JDK. Me too! But for now it's burglary or bust :-) > Perhaps the right surface shape for moderate reflection is Maurizios > "reflection manifesto" API, which is completely interface driven. > This means a meta-CE with full deep access could mock up a > "reflection manifesto" implementation which would expose exactly the > right moderate surface area, as negotiated with the target module. > Just an idea? Hmm, I have not seen said manifesto. Is it available somewhere public? 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 forax at univ-mlv.fr Wed Nov 2 14:14:56 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Nov 2016 15:14:56 +0100 (CET) Subject: javac --module-source-path and --patch-module do not work together Message-ID: <1463075159.669919.1478096096557.JavaMail.zimbra@u-pem.fr> Hi Jon, hi all, When i try to compile a module with --module-source-path that uses a patched class (with --patch-module), it fails. With: javac --module-source-path src \ -d output/modules/ \ --patch-module java.base=output/classes \ --module-path output/modules \ $(find src/org.hibernate.jpa/ -name "*.java") it seems that javac tries to find the source of the patched module (here java.base) in the module-source-path, so it get this error error: cannot find module: java.base 1 error I believe this is a bug. Step to reproduce it: git clone git at github.com:forax/access-broker.git and uncomment the lines that uses --module-source-path and --patch-module java.base=output/classes in the build.sh. regards, R?mi From forax at univ-mlv.fr Wed Nov 2 14:20:27 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Nov 2016 15:20:27 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <4d4ebd9d-7150-425e-4cd4-06281d2b9bcd@redhat.com> References: <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <4d4ebd9d-7150-425e-4cd4-06281d2b9bcd@redhat.com> Message-ID: <1736827515.673737.1478096427206.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Andrew Dinn" > ?: "John Rose" > Cc: jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 2 Novembre 2016 14:25:01 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages > On 02/11/16 01:58, John Rose wrote: >> On Nov 1, 2016, at 12:02 PM, Andrew Dinn wrote: >>> >>> I did actually suggest a way of avoiding the use of Unsafe. You >>> give your nominated module full reflective access to >>> java.lang.invoke allowing it to create Lookup instances (it can >>> actually just create a single all privileges lookup and use this to >>> clone others). You don't need to insert a class into >>> java.lang.invoke to do this. You simply add one exports directive >>> on the command line. >> >> The weak link in this otherwise robust scheme is the use of a command >> line option to break into the jli package. Breaking in by the back >> door is awkward and might not deliver the desired Lookup if jli code >> changes. And it probably will, over time. Using the break-in is a >> good Proof of concept but the finished product needs to use a real >> API provided by the JDK, and using a wormhole Lookup actually >> provided by a cooperating jli. I look forward to such a thing in a >> future JDK. > > Me too! But for now it's burglary or bust :-) > >> Perhaps the right surface shape for moderate reflection is Maurizios >> "reflection manifesto" API, which is completely interface driven. >> This means a meta-CE with full deep access could mock up a >> "reflection manifesto" implementation which would expose exactly the >> right moderate surface area, as negotiated with the target module. >> Just an idea? > > Hmm, I have not seen said manifesto. Is it available somewhere public? Maurizio talk about it at last JVM Language Summit https://encrypted.google.com/search?hl=en&q=youtube%20Valhalla%20Reflection The manifesto is here http://cr.openjdk.java.net/~mcimadamore/reflection-manifesto.html > > regards, > > > Andrew Dinn R?mi > ----------- > 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 Wed Nov 2 14:38:55 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Nov 2016 14:38:55 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611021438.uA2Ect6p028489@aojmv0008.oracle.com> Changeset: b189339d80d9 Author: alanb Date: 2016-11-02 13:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b189339d80d9 Experimental support for multi-parent configurations ! src/java.base/share/classes/java/lang/module/Configuration.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/java/lang/reflect/Module.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/loader/LoaderPool.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/nio/channels/Selector/TemporarySelector.java ! test/java/util/ServiceLoader/modules/Basic.java Changeset: 32edb2772fb8 Author: alanb Date: 2016-11-02 14:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32edb2772fb8 getResourceXXX slow when locating resources not in packages ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java From jonathan.gibbons at oracle.com Wed Nov 2 15:15:38 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 2 Nov 2016 08:15:38 -0700 Subject: javac --module-source-path and --patch-module do not work together In-Reply-To: <1463075159.669919.1478096096557.JavaMail.zimbra@u-pem.fr> References: <1463075159.669919.1478096096557.JavaMail.zimbra@u-pem.fr> Message-ID: <5d94c7fa-dd93-e00e-afaa-9be426e09878@oracle.com> Remi, Your command line is questionable for putting output/modules on both -d and --module-path. You don't need it on --module-path. When compiling modules, javac will automatically look in the output directory for classes for the module(s) being compiled. Does your module source path contain source code for java.base? If so, it will only use that definition of java.base, and not anything in the paths given with --patch-module. -- Jon On 11/2/16 7:14 AM, Remi Forax wrote: > Hi Jon, hi all, > > When i try to compile a module with --module-source-path that uses a patched class (with --patch-module), > it fails. > > With: > javac --module-source-path src \ > -d output/modules/ \ > --patch-module java.base=output/classes \ > --module-path output/modules \ > $(find src/org.hibernate.jpa/ -name "*.java") > > it seems that javac tries to find the source of the patched module (here java.base) in the module-source-path, > so it get this error > > error: cannot find module: java.base > 1 error > > I believe this is a bug. > > Step to reproduce it: > git clone git at github.com:forax/access-broker.git > and uncomment the lines that uses --module-source-path and --patch-module java.base=output/classes in the build.sh. > > regards, > R?mi From forax at univ-mlv.fr Wed Nov 2 16:49:49 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Nov 2016 17:49:49 +0100 (CET) Subject: javac --module-source-path and --patch-module do not work together In-Reply-To: <5d94c7fa-dd93-e00e-afaa-9be426e09878@oracle.com> References: <1463075159.669919.1478096096557.JavaMail.zimbra@u-pem.fr> <5d94c7fa-dd93-e00e-afaa-9be426e09878@oracle.com> Message-ID: <2144174895.757553.1478105389686.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Jonathan Gibbons" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 2 Novembre 2016 16:15:38 > Objet: Re: javac --module-source-path and --patch-module do not work together > Remi, > > Your command line is questionable for putting output/modules on both -d > and --module-path. You don't need it on --module-path. When compiling > modules, javac will automatically look in the output directory for > classes for the module(s) being compiled. You're right i would not have to use --module-path if i was able to compile several modules at once (using --module-source-path). I use it here, because i compile the different modules with different calls to javac (in the right order because luckily there is no cycle in my example). > > Does your module source path contain source code for java.base? If so, > it will only use that definition of java.base, and not anything in the > paths given with --patch-module. I agree that if there is a folder java.base in the module-source-path, it should be used but this is not the case. Here, i want to add files to an existing modules (java.base) and those files are in output/classes not in src. > > -- Jon R?mi > > > On 11/2/16 7:14 AM, Remi Forax wrote: >> Hi Jon, hi all, >> >> When i try to compile a module with --module-source-path that uses a patched >> class (with --patch-module), >> it fails. >> >> With: >> javac --module-source-path src \ >> -d output/modules/ \ >> --patch-module java.base=output/classes \ >> --module-path output/modules \ >> $(find src/org.hibernate.jpa/ -name "*.java") >> >> it seems that javac tries to find the source of the patched module (here >> java.base) in the module-source-path, >> so it get this error >> >> error: cannot find module: java.base >> 1 error >> >> I believe this is a bug. >> >> Step to reproduce it: >> git clone git at github.com:forax/access-broker.git >> and uncomment the lines that uses --module-source-path and --patch-module >> java.base=output/classes in the build.sh. >> >> regards, > > R?mi From jonathan.gibbons at oracle.com Wed Nov 2 16:57:58 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 02 Nov 2016 09:57:58 -0700 Subject: javac --module-source-path and --patch-module do not work together In-Reply-To: <2144174895.757553.1478105389686.JavaMail.zimbra@u-pem.fr> References: <1463075159.669919.1478096096557.JavaMail.zimbra@u-pem.fr> <5d94c7fa-dd93-e00e-afaa-9be426e09878@oracle.com> <2144174895.757553.1478105389686.JavaMail.zimbra@u-pem.fr> Message-ID: <581A1B16.5030502@oracle.com> On 11/02/2016 09:49 AM, Remi Forax wrote: > I agree that if there is a folder java.base in the module-source-path, it should be used but this is not the case. > Here, i want to add files to an existing modules (java.base) and those files are in output/classes not in src. You currently can't add files with --patch-module to a module found with --module-source-path. -- Jon From forax at univ-mlv.fr Wed Nov 2 17:11:47 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Nov 2016 18:11:47 +0100 (CET) Subject: javac --module-source-path and --patch-module do not work together In-Reply-To: <581A1B16.5030502@oracle.com> References: <1463075159.669919.1478096096557.JavaMail.zimbra@u-pem.fr> <5d94c7fa-dd93-e00e-afaa-9be426e09878@oracle.com> <2144174895.757553.1478105389686.JavaMail.zimbra@u-pem.fr> <581A1B16.5030502@oracle.com> Message-ID: <652339668.764089.1478106707237.JavaMail.zimbra@u-pem.fr> I agree with that, but that's not my use case. I want to add/override files to java.base (an existing module) with --patch-module when i compile several other modules with --module-source-path, i think this should be allowed, otherwise it will be hard to patch the JDK and see the effect on several modules. R?mi ----- Mail original ----- > Envoy?: Mercredi 2 Novembre 2016 17:57:58 > Objet: Re: javac --module-source-path and --patch-module do not work together > On 11/02/2016 09:49 AM, Remi Forax wrote: >> I agree that if there is a folder java.base in the module-source-path, it should >> be used but this is not the case. >> Here, i want to add files to an existing modules (java.base) and those files are >> in output/classes not in src. > > You currently can't add files with --patch-module to a module found with > --module-source-path. > > -- Jon From mandy.chung at oracle.com Wed Nov 2 17:34:07 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Nov 2016 17:34:07 +0000 Subject: hg: jigsaw/jake/langtools: jdeps support to generate module-info for open module Message-ID: <201611021734.uA2HY76D012175@aojmv0008.oracle.com> Changeset: dce235fc8345 Author: mchung Date: 2016-11-02 10:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dce235fc8345 jdeps support to generate module-info for open module ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties + test/tools/jdeps/modules/GenOpenModule.java - test/tools/jdeps/modules/GenWeakModule.java From mandy.chung at oracle.com Wed Nov 2 17:40:13 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Nov 2016 17:40:13 +0000 Subject: hg: jigsaw/jake/jdk: jar --print-module-descriptor missed to close the jar file Message-ID: <201611021740.uA2HeDCd013752@aojmv0008.oracle.com> Changeset: 2d63ca46f6db Author: mchung Date: 2016-11-02 10:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2d63ca46f6db jar --print-module-descriptor missed to close the jar file ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! test/tools/jar/mmrjar/ConcealedPackage.java From jonathan.gibbons at oracle.com Wed Nov 2 17:40:26 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 02 Nov 2016 10:40:26 -0700 Subject: javac --module-source-path and --patch-module do not work together In-Reply-To: <652339668.764089.1478106707237.JavaMail.zimbra@u-pem.fr> References: <1463075159.669919.1478096096557.JavaMail.zimbra@u-pem.fr> <5d94c7fa-dd93-e00e-afaa-9be426e09878@oracle.com> <2144174895.757553.1478105389686.JavaMail.zimbra@u-pem.fr> <581A1B16.5030502@oracle.com> <652339668.764089.1478106707237.JavaMail.zimbra@u-pem.fr> Message-ID: <581A250A.6020508@oracle.com> A variant of this problem is under consideration, which may address your use case. In the meantime, the workaround is to make sure there is no evidence of java.base on the module source path. -- Jon On 11/02/2016 10:11 AM, Remi Forax wrote: > I agree with that, but that's not my use case. > I want to add/override files to java.base (an existing module) with --patch-module when i compile several other modules with --module-source-path, i think this should be allowed, otherwise it will be hard to patch the JDK and see the effect on several modules. > > R?mi > > ----- Mail original ----- >> Envoy?: Mercredi 2 Novembre 2016 17:57:58 >> Objet: Re: javac --module-source-path and --patch-module do not work together >> On 11/02/2016 09:49 AM, Remi Forax wrote: >>> I agree that if there is a folder java.base in the module-source-path, it should >>> be used but this is not the case. >>> Here, i want to add files to an existing modules (java.base) and those files are >>> in output/classes not in src. >> You currently can't add files with --patch-module to a module found with >> --module-source-path. >> >> -- Jon From jonathan.gibbons at oracle.com Wed Nov 2 18:20:14 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 02 Nov 2016 18:20:14 +0000 Subject: hg: jigsaw/jake/langtools: add no-op --add-opens option to javac Message-ID: <201611021820.uA2IKFs9026746@aojmv0008.oracle.com> Changeset: 6f99c4e110f1 Author: jjg Date: 2016-11-02 11:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6f99c4e110f1 add no-op --add-opens option to javac ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.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 From mandy.chung at oracle.com Wed Nov 2 19:11:19 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Nov 2016 12:11:19 -0700 Subject: Request Review: JDK-6479237 (cl) Add support for classloader names In-Reply-To: <2392ca27-b110-ce1c-0cc7-38447e575756@oracle.com> References: <2C30243B-71D2-49E2-A8B6-2C33B82DB104@oracle.com> <5d494d3a-f8ec-0456-8d04-f8998d840fc7@oracle.com> <52E8F822-2D4E-4BD7-BE4E-748E47901625@oracle.com> <931BF9A2-6F22-48FF-855E-287BAF10FDC0@oracle.com> <237186f1-13b4-5a94-099d-cf1f07e7b120@oracle.com> <82595580-6100-4F6C-905C-3061D3AE43C6@oracle.com> <2392ca27-b110-ce1c-0cc7-38447e575756@oracle.com> Message-ID: > On Nov 2, 2016, at 4:29 AM, Daniel Fuchs wrote: > > I'd suggest passing 'name' to 'checkCreateClassLoader()' and do > this check in checkCreateClassLoader instead - in order to do > the checks before 'this' is created. > Fixed. > That's not exactly what I had in mind. I don't have > any particular feeling for whether "" should be allowed > or not. Maybe it would be simpler to just allow "" to mean the > same thing as 'null'. What I meant was: > Can moduleVersion be non null (and non empty) if moduleName is null > (or empty)? In other words can an unnamed module have a version? > > Also if you add some validation to the constructor then > you will need to add a readObject to duplicate the validation > checks. And if you disallow "" then checking for isEmpty() in > toString() is not needed. But I have the feeling that simply > allowing "" and null to mean the same thing would be more > robust. It's just the question of having a moduleVersion > for an unnamed module that bothers me. > Having a second thought - it can?t do much validation with these strings e.g. whether the class loader name is the one loading the class or the module where this class is in. I think it?s better to keep it simple and allow empty string and StackTraceElement::toString should not print module version for unnamed module (I fixed a bug there. It was intended to do that anyway). Would that address your concern? > > Right - no problem with that. > I haven't given any thought to a test case for JDK-8167099. > I believe it will prevent to connect a JDK 9 jvisualvm to a > JDK 8 process if not fixed though. Maybe serializing a ThreadInfo > composite data containing some MonitorInfo in JDK 8, and > then deserializing that in JDK 9 and trying to convert it > back to ThreadInfo in 9 would show the issue. We should fix that. Updated version: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.04/ Mandy From daniel.fuchs at oracle.com Wed Nov 2 19:57:49 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Nov 2016 19:57:49 +0000 Subject: Request Review: JDK-6479237 (cl) Add support for classloader names In-Reply-To: References: <2C30243B-71D2-49E2-A8B6-2C33B82DB104@oracle.com> <5d494d3a-f8ec-0456-8d04-f8998d840fc7@oracle.com> <52E8F822-2D4E-4BD7-BE4E-748E47901625@oracle.com> <931BF9A2-6F22-48FF-855E-287BAF10FDC0@oracle.com> <237186f1-13b4-5a94-099d-cf1f07e7b120@oracle.com> <82595580-6100-4F6C-905C-3061D3AE43C6@oracle.com> <2392ca27-b110-ce1c-0cc7-38447e575756@oracle.com> Message-ID: On 02/11/16 19:11, Mandy Chung wrote: > Updated version: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.04/ +1. I like that toString() is now consitent with toLoaderModuleClassName() in the way both methods handle module name and version. best regards, -- daniel From jonathan.gibbons at oracle.com Wed Nov 2 21:24:08 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 02 Nov 2016 21:24:08 +0000 Subject: hg: jigsaw/jake/langtools: 4 new changesets Message-ID: <201611022124.uA2LO86g010260@aojmv0008.oracle.com> Changeset: 1bb329a71382 Author: jjg Date: 2016-11-02 13:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1bb329a71382 fix tests that use normal and deep reflective access ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/modules/PatchModulesTest.java ! test/tools/javac/platform/PlatformProviderTest.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: aaeff93be80e Author: jjg Date: 2016-11-02 13:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/aaeff93be80e remove support for old provides table ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Changeset: 52c488a16f7a Author: jjg Date: 2016-11-02 13:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/52c488a16f7a add warning and example for use of --add-opens ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java + test/tools/javac/diags/examples/AddOpensIgnored.java Changeset: 9f45830b5fae Author: jjg Date: 2016-11-02 14:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f45830b5fae fix JShell test using compile-time and reflective access ! test/jdk/jshell/HistoryTest.java From mandy.chung at oracle.com Wed Nov 2 21:44:33 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Nov 2016 21:44:33 +0000 Subject: hg: jigsaw/jake/jdk: Fix tests that use normal and deep reflective access Message-ID: <201611022144.uA2LiYG9015241@aojmv0008.oracle.com> Changeset: 9ec1c05aaa68 Author: mchung Date: 2016-11-02 14:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ec1c05aaa68 Fix tests that use normal and deep reflective access ! test/com/sun/corba/serialization/ObjectStreamTest.java ! test/com/sun/crypto/provider/Cipher/PBE/CheckPBEKeySize.java ! test/com/sun/jdi/ConstantPoolInfoGC.java ! test/com/sun/jndi/dns/Parser.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerAPIsTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.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/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/javax/net/ssl/DTLS/TEST.properties ! test/javax/net/ssl/DTLSv10/TEST.properties ! test/javax/net/ssl/TLS/TEST.properties ! test/javax/net/ssl/TLSv1/TEST.properties ! test/javax/net/ssl/TLSv11/TEST.properties ! test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java ! test/jdk/internal/jline/console/StripAnsiTest.java ! test/sun/net/idn/TestStringPrep.java ! test/sun/net/www/http/HttpClient/IsAvailable.java ! test/sun/security/jgss/spnego/NotPreferredMech.java ! test/sun/security/krb5/RFC396xTest.java ! test/sun/security/krb5/auto/Renew.java ! test/sun/security/krb5/auto/TEST.properties ! test/sun/security/krb5/config/DefUdpLimit.java ! test/sun/security/krb5/config/DnsFallback.java ! test/sun/security/krb5/config/SCDynamicConfigTest.java ! test/sun/security/provider/SecureRandom/CommonSeeder.java ! test/sun/security/provider/SecureRandom/DRBGS11n.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/util/DerInputBuffer/DerInputBufferEqualsHashCode.java ! test/sun/util/calendar/zi/TestZoneInfo310.java From jonathan.gibbons at oracle.com Wed Nov 2 21:50:04 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 02 Nov 2016 21:50:04 +0000 Subject: hg: jigsaw/jake/langtools: fix remaining uses of :private Message-ID: <201611022150.uA2Lo4IW016791@aojmv0008.oracle.com> Changeset: 8154a3ab3a1f Author: jjg Date: 2016-11-02 14:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8154a3ab3a1f fix remaining uses of :private ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/ComputeFQNsTest.java ! test/jdk/jshell/PipeInputStreamTest.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/options/release/ReleaseOptionClashes.java From aguibert at us.ibm.com Wed Nov 2 23:22:56 2016 From: aguibert at us.ibm.com (Andrew Guibert) Date: Wed, 2 Nov 2016 17:22:56 -0600 Subject: Proposal for JSE API representing java.specification.version Message-ID: Hello all, Many Java frameworks and applications require knowledge of the Java version they are running on. Currently the only way to check the Java version is by doing: String javaVersion = System.getProperty("java.specification.version"); This of course returns a String, which is very awkward to work with when it comes to comparisons. For example, if I want to check if my code is running at least on Java 8, I have to do the following: if (Pattern.matches("1\\.[0-7]", javaVersion)) // at java 7 or earlier else // at java 8 or later It would be nice if the JDK had a built-in enum, similar to what is provided by org.apache.commons [1], so that Java version comparisons are less awkward. I'm not familiar with the process is for getting new APIs into the JDK, but if it is a simple matter of making a pull request I can certainly do so. Regards, Andy [1] https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/JavaVersion.html From forax at univ-mlv.fr Wed Nov 2 23:33:56 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 3 Nov 2016 00:33:56 +0100 (CET) Subject: Proposal for JSE API representing java.specification.version In-Reply-To: References: Message-ID: <182097275.824245.1478129636926.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Andrew Guibert" > ?: "jigsaw-dev" > Envoy?: Jeudi 3 Novembre 2016 00:22:56 > Objet: Proposal for JSE API representing java.specification.version > Hello all, > > Many Java frameworks and applications require knowledge of the Java version > they are running on. Currently the only way to check the Java version is > by doing: > > String javaVersion = System.getProperty("java.specification.version"); > > This of course returns a String, which is very awkward to work with when it > comes to comparisons. For example, if I want to check if my code is > running at least on Java 8, I have to do the following: > > if (Pattern.matches("1\\.[0-7]", javaVersion)) > // at java 7 or earlier > else > // at java 8 or later > > It would be nice if the JDK had a built-in enum, similar to what is > provided by org.apache.commons [1], so that Java version comparisons are > less awkward. > > I'm not familiar with the process is for getting new APIs into the JDK, but > if it is a simple matter of making a pull request I can certainly do so. Hi Andrew, are you aware of Runtime.Version (introduced in 9): http://download.java.net/java/jdk9/docs/api/java/lang/Runtime.Version.html > > Regards, Andy > > [1] > https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/JavaVersion.html cheers, R?mi From alex.buckley at oracle.com Wed Nov 2 23:34:48 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 02 Nov 2016 16:34:48 -0700 Subject: Proposal for JSE API representing java.specification.version In-Reply-To: References: Message-ID: <581A7818.5090406@oracle.com> Andy, Java SE 9 has java.lang.Runtime.Version for manipulating the version strings returned as system properties. It was introduced by JEP 223 -- see http://openjdk.java.net/jeps/223. Best to follow up on verona-dev. Alex On 11/2/2016 4:22 PM, Andrew Guibert wrote: > Hello all, > > Many Java frameworks and applications require knowledge of the Java version > they are running on. Currently the only way to check the Java version is > by doing: > > String javaVersion = System.getProperty("java.specification.version"); > > This of course returns a String, which is very awkward to work with when it > comes to comparisons. For example, if I want to check if my code is > running at least on Java 8, I have to do the following: > > if (Pattern.matches("1\\.[0-7]", javaVersion)) > // at java 7 or earlier > else > // at java 8 or later > > It would be nice if the JDK had a built-in enum, similar to what is > provided by org.apache.commons [1], so that Java version comparisons are > less awkward. > > I'm not familiar with the process is for getting new APIs into the JDK, but > if it is a simple matter of making a pull request I can certainly do so. > > Regards, Andy > > [1] > https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/JavaVersion.html > From mandy.chung at oracle.com Thu Nov 3 00:15:51 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Nov 2016 00:15:51 +0000 Subject: hg: jigsaw/jake/langtools: Generate one provides clause for each service interface with one or more providers Message-ID: <201611030015.uA30FpnH020742@aojmv0008.oracle.com> Changeset: a8962f60d7d0 Author: mchung Date: 2016-11-02 17:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a8962f60d7d0 Generate one provides clause for each service interface with one or more providers ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! test/tools/jdeps/modules/GenModuleInfo.java ! test/tools/jdeps/modules/GenOpenModule.java + test/tools/jdeps/modules/src/provider/META-INF/services/java.util.spi.ToolProvider + test/tools/jdeps/modules/src/provider/META-INF/services/p.Service$I$J + test/tools/jdeps/modules/src/provider/module-info.java + test/tools/jdeps/modules/src/provider/p/Provider.java + test/tools/jdeps/modules/src/provider/p/Service.java + test/tools/jdeps/modules/src/provider/q/ProviderImpl1.java + test/tools/jdeps/modules/src/provider/q/ProviderImpl2.java + test/tools/jdeps/modules/src/provider/q/ProviderImpl3.java From mandy.chung at oracle.com Thu Nov 3 00:17:19 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Nov 2016 00:17:19 +0000 Subject: hg: jigsaw/jake/jdk: Update build-time generated module-info.java for opens and provides directive Message-ID: <201611030017.uA30HJh4021108@aojmv0008.oracle.com> Changeset: c32a29f4613f Author: mchung Date: 2016-11-02 17:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c32a29f4613f Update build-time generated module-info.java for opens and provides directive ! make/src/classes/build/tools/module/GenModuleInfoSource.java From mandy.chung at oracle.com Thu Nov 3 00:17:26 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Nov 2016 00:17:26 +0000 Subject: hg: jigsaw/jake: Update build-time generated module-info.java for opens and provides directive Message-ID: <201611030017.uA30HQ4D021158@aojmv0008.oracle.com> Changeset: cffb6ba86fb4 Author: mchung Date: 2016-11-02 17:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cffb6ba86fb4 Update build-time generated module-info.java for opens and provides directive ! make/GensrcModuleInfo.gmk From mandy.chung at oracle.com Thu Nov 3 02:41:35 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Nov 2016 02:41:35 +0000 Subject: hg: jigsaw/jake/jdk: fix tests for deep reflection access Message-ID: <201611030241.uA32fZt6028598@aojmv0008.oracle.com> Changeset: 484681b43b87 Author: mchung Date: 2016-11-02 19:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/484681b43b87 fix tests for deep reflection access ! 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/jndi/ldap/SimpleClientIdHashCode.java ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java ! 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/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/beans/Introspector/6380849/TestBeanInfo.java ! test/java/beans/XMLEncoder/java_awt_CardLayout.java ! test/java/beans/XMLEncoder/java_awt_GridBagLayout.java ! test/java/io/FilePermission/Correctness.java ! test/java/io/ObjectInputStream/PeekInputStreamTest.java ! test/java/lang/Character/UnicodeBlock/OptimalMapSize.java ! test/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java ! test/java/lang/ClassLoader/LibraryPathProperty.java ! test/java/lang/ProcessBuilder/Basic.java ! 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/String/CompactString/VMOptionsTest.java ! test/java/lang/System/LoggerFinder/internal/backend/LoggerFinderBackendTest.java ! test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java ! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java ! test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java ! test/java/lang/invoke/LambdaFormTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/ref/FinalizerHistogramTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/net/InterfaceAddress/Equals.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/file/etc/Exceptions.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/Currency/CurrencyTest.java ! test/java/util/Currency/ValidateISO4217.java ! 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/ResourceBundle/ReferencesTest.java ! test/java/util/concurrent/ArrayBlockingQueue/IteratorConsistency.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/atomic/VMSupportsCS8.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/management/ObjectName/CompressedStorageTest.java ! test/javax/management/loading/MLetInternalsTest.java ! test/javax/management/openmbean/TabularDataOrderTest.java ! test/javax/management/remote/mandatory/connection/ObjectInputStreamWithLoaderNullCheckTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorInternalMapTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorNullSubjectConnTest.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 ! test/javax/xml/jaxp/PrecisionDecimalDV/XPrecisionDecimalToString.java ! test/sun/security/krb5/ccache/TimeInCCache.java ! test/sun/security/krb5/tools/KtabZero.java ! test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java ! test/sun/security/ssl/ExtensionType/OptimalListSize.java From mandy.chung at oracle.com Thu Nov 3 05:03:12 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Nov 2016 05:03:12 +0000 Subject: hg: jigsaw/jake/jdk: use new jtreg :+open for normal and deep reflection access Message-ID: <201611030503.uA353C1C028763@aojmv0008.oracle.com> Changeset: 96556085b81d Author: mchung Date: 2016-11-02 22:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96556085b81d use new jtreg :+open for normal and deep reflection access ! test/com/sun/corba/serialization/ObjectStreamTest.java ! test/com/sun/crypto/provider/Cipher/PBE/CheckPBEKeySize.java ! test/com/sun/jdi/ConstantPoolInfoGC.java ! test/com/sun/jndi/dns/Parser.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerAPIsTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.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/javax/management/remote/mandatory/notif/DeadListenerTest.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/DTLS/TEST.properties ! 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/DTLSv10/TEST.properties ! test/javax/net/ssl/TLS/TEST.properties ! 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/TEST.properties ! 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/TEST.properties ! 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/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java ! test/jdk/internal/jline/console/StripAnsiTest.java ! test/sun/net/idn/TestStringPrep.java ! test/sun/net/www/http/HttpClient/IsAvailable.java ! test/sun/security/jgss/spnego/NotPreferredMech.java ! test/sun/security/krb5/RFC396xTest.java ! test/sun/security/krb5/auto/Renew.java ! test/sun/security/krb5/auto/TEST.properties ! test/sun/security/krb5/config/DefUdpLimit.java ! test/sun/security/krb5/config/DnsFallback.java ! test/sun/security/krb5/config/SCDynamicConfigTest.java ! test/sun/security/provider/SecureRandom/CommonSeeder.java ! test/sun/security/provider/SecureRandom/DRBGS11n.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/util/DerInputBuffer/DerInputBufferEqualsHashCode.java ! test/sun/util/calendar/zi/TestZoneInfo310.java From alan.bateman at oracle.com Thu Nov 3 06:57:43 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 03 Nov 2016 06:57:43 +0000 Subject: hg: jigsaw/jake/jdk: Remove CORBA tests from exclude list, get more tests running Message-ID: <201611030657.uA36vhrk022155@aojmv0008.oracle.com> Changeset: d370ea60c627 Author: alanb Date: 2016-11-03 06:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d370ea60c627 Remove CORBA tests from exclude list, get more tests running ! test/ProblemList.txt ! test/java/security/testlibrary/Proc.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java From alan.bateman at oracle.com Thu Nov 3 07:27:58 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 03 Nov 2016 07:27:58 +0000 Subject: hg: jigsaw/jake/hotspot: Small clarification to JVM TI AddModuleExports/AddModuleOpens Message-ID: <201611030727.uA37Rx2F029163@aojmv0008.oracle.com> Changeset: f2dcbf337bc4 Author: alanb Date: 2016-11-03 07:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2dcbf337bc4 Small clarification to JVM TI AddModuleExports/AddModuleOpens ! src/share/vm/prims/jvmti.xml From denis.kononenko at oracle.com Thu Nov 3 13:29:36 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Thu, 3 Nov 2016 16:29:36 +0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> References: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> Message-ID: <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> Hi, I've done some rework accordingly to Alan's and Shura's comments: 1) removed overlapped tests from JImageToolTest.java; 2) added new tests JImageVerifyTest.java for jimage verify; 3) reorganized jtreg's tags; The new WEBREV can be found here: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ Thank you, Denis. On 06.10.2016 19:37, Denis Kononenko wrote: > Hi, > > Could someone please review these new tests for jimage utility. > > There're 5 new files containing tests to cover use cases for 'info', > 'list', 'extract' and other options. No new tests for 'verify'. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > > > Thank you, > Denis. From james.laskey at oracle.com Thu Nov 3 13:34:58 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 3 Nov 2016 10:34:58 -0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> References: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> Message-ID: Nice work. +1 > On Nov 3, 2016, at 10:29 AM, Denis Kononenko wrote: > > Hi, > > I've done some rework accordingly to Alan's and Shura's comments: > > 1) removed overlapped tests from JImageToolTest.java; > > 2) added new tests JImageVerifyTest.java for jimage verify; > > 3) reorganized jtreg's tags; > > The new WEBREV can be found here: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > Thank you, > Denis. > > On 06.10.2016 19:37, Denis Kononenko wrote: >> Hi, >> >> Could someone please review these new tests for jimage utility. >> >> There're 5 new files containing tests to cover use cases for 'info', 'list', 'extract' and other options. No new tests for 'verify'. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >> >> >> Thank you, >> Denis. > From alexandre.iline at oracle.com Thu Nov 3 18:47:01 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 3 Nov 2016 11:47:01 -0700 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> References: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> Message-ID: <2130E34C-1373-4E69-BDC7-AEB478237DE0@oracle.com> Denis, I can see that you have switched to the top level test library with this change. With that you are getting more module dependencies than just java.base. First of all, it would probably make sense to build only the classes you needed (which would be jdk.test.lib.process.ProcessTools, I assume), but even if you only build that, jdk.test.lib.process.ProcessTools has dependencies outside java.base module. You either have to declare @modules in your test or go back to the jdk/test/lib/testlibrary. Then, of course, unneeded module dependencies are questionable. Shura > On Nov 3, 2016, at 6:29 AM, Denis Kononenko wrote: > > Hi, > > I've done some rework accordingly to Alan's and Shura's comments: > > 1) removed overlapped tests from JImageToolTest.java; > > 2) added new tests JImageVerifyTest.java for jimage verify; > > 3) reorganized jtreg's tags; > > The new WEBREV can be found here: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > Thank you, > Denis. > > On 06.10.2016 19:37, Denis Kononenko wrote: >> Hi, >> >> Could someone please review these new tests for jimage utility. >> >> There're 5 new files containing tests to cover use cases for 'info', 'list', 'extract' and other options. No new tests for 'verify'. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >> >> >> Thank you, >> Denis. > From jonathan.gibbons at oracle.com Thu Nov 3 20:37:56 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 03 Nov 2016 20:37:56 +0000 Subject: hg: jigsaw/jake/langtools: 3 new changesets Message-ID: <201611032037.uA3Kbupk024577@aojmv0008.oracle.com> Changeset: 3286b60836a5 Author: jjg Date: 2016-11-03 13:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3286b60836a5 temporary fix to merge multiple provides for a service ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Changeset: 03cece156818 Author: jjg Date: 2016-11-03 13:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/03cece156818 update remaining tests to use :open as needed ! test/jdk/jshell/HistoryTest.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/modules/PatchModulesTest.java ! test/tools/javac/platform/PlatformProviderTest.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: 8f326cd2eac5 Author: jjg Date: 2016-11-03 13:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8f326cd2eac5 Merge From jonathan.gibbons at oracle.com Fri Nov 4 01:32:15 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 04 Nov 2016 01:32:15 +0000 Subject: hg: jigsaw/jake/langtools: javadoc should change "requires public" to "requires transitive" Message-ID: <201611040132.uA41WGZ3027675@aojmv0008.oracle.com> Changeset: 2b552c8cff2b Author: jjg Date: 2016-11-03 18:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2b552c8cff2b javadoc should change "requires public" to "requires transitive" ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/package-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/jdk/javadoc/tool/modules/Modules.java From blackdrag at gmx.org Fri Nov 4 08:05:54 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 09:05:54 +0100 Subject: Unsafe and AwkwardStrongEncapsulation In-Reply-To: <20161103163252.220277226> References: <20161027155336.DBCE7DA329@eggemoggin.niobe.net> <1C97C371-66E1-4770-9307-FEE6CB912B81@paremus.com> <20161103163252.220277226> Message-ID: <581C4162.3080407@gmx.org> On 04.11.2016 00:32, mark.reinhold at oracle.com wrote: > 2016/11/1 14:17:43 -0700, neil.bartlett at paremus.com: >> ... > In scenarios where a module's author > can't foresee the need for such access (e.g., intrusive serialization > frameworks) then the framework's author must take more drastic measures > (e.g., use the legacy unsupported unsafe API). This balance is intended > to help maintain the integrity of a module as expressed by its author. Since Unsafe was mentioned here... All the ways I did know to get to Unsafe required reflection on private members. Afaik #AwkwardStrongEncapsulation will block that. So how can I still use Unsafe in the future or did it get some "proper" public way to get hold of an Unsafe by now and I missed that? bye Jochen From blackdrag at gmx.org Fri Nov 4 08:11:51 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 09:11:51 +0100 Subject: The split package problem Message-ID: <581C42C7.1010409@gmx.org> Hi all, I do often read about this "split package problem", but I never did see a proper explanation about why it matters to jigsaw so much that we do not allow it. Can somebody enlighten me? bye Jochen From Alan.Bateman at oracle.com Fri Nov 4 08:12:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 08:12:01 +0000 Subject: Unsafe and AwkwardStrongEncapsulation In-Reply-To: <581C4162.3080407@gmx.org> References: <20161027155336.DBCE7DA329@eggemoggin.niobe.net> <1C97C371-66E1-4770-9307-FEE6CB912B81@paremus.com> <20161103163252.220277226> <581C4162.3080407@gmx.org> Message-ID: <84bc1345-bae9-a2c0-6113-10bc9c8be0b5@oracle.com> On 04/11/2016 08:05, Jochen Theodorou wrote: > Since Unsafe was mentioned here... All the ways I did know to get to > Unsafe required reflection on private members. Afaik > #AwkwardStrongEncapsulation will block that. So how can I still use > Unsafe in the future or did it get some "proper" public way to get > hold of an Unsafe by now and I missed that? I think you are looking for JEP 260 [1]. The critical internal APIs where it lists the "critical internal APIs" that are not encapsulated in JDK 9. If you are using the Jigsaw EA builds then look at `java --list-modules jdk.unsupported` where you'll see that sun.misc (and sun.reflect) are both exported and open. -Alan [1] http://openjdk.java.net/jeps/260 From forax at univ-mlv.fr Fri Nov 4 08:17:57 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 4 Nov 2016 09:17:57 +0100 (CET) Subject: Unsafe and AwkwardStrongEncapsulation In-Reply-To: <581C4162.3080407@gmx.org> References: <20161027155336.DBCE7DA329@eggemoggin.niobe.net> <1C97C371-66E1-4770-9307-FEE6CB912B81@paremus.com> <20161103163252.220277226> <581C4162.3080407@gmx.org> Message-ID: <719024322.1495989.1478247477990.JavaMail.zimbra@u-pem.fr> Hi Jochen, the package sun.misc in the module jdk.unsupported is declared open, do you can use deep reflection on it. $ javap -m jdk.unsupported module-info Warning: Binary file module-info contains jdk.unsupported.module-info Compiled from "module-info.java" module jdk.unsupported { requires java.base; exports sun.misc; exports com.sun.nio.file; exports sun.reflect; opens sun.misc; opens sun.reflect; } cheers, R?mi ----- Mail original ----- > De: "Jochen Theodorou" > ?: "jigsaw-dev" > Envoy?: Vendredi 4 Novembre 2016 09:05:54 > Objet: Unsafe and AwkwardStrongEncapsulation > On 04.11.2016 00:32, mark.reinhold at oracle.com wrote: >> 2016/11/1 14:17:43 -0700, neil.bartlett at paremus.com: >>> ... >> In scenarios where a module's author >> can't foresee the need for such access (e.g., intrusive serialization >> frameworks) then the framework's author must take more drastic measures >> (e.g., use the legacy unsupported unsafe API). This balance is intended >> to help maintain the integrity of a module as expressed by its author. > > Since Unsafe was mentioned here... All the ways I did know to get to > Unsafe required reflection on private members. Afaik > #AwkwardStrongEncapsulation will block that. So how can I still use > Unsafe in the future or did it get some "proper" public way to get hold > of an Unsafe by now and I missed that? > > bye Jochen From forax at univ-mlv.fr Fri Nov 4 08:25:06 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 4 Nov 2016 09:25:06 +0100 (CET) Subject: The split package problem In-Reply-To: <581C42C7.1010409@gmx.org> References: <581C42C7.1010409@gmx.org> Message-ID: <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> There are two issues with split packages, - if you have the same class in each part of the package, the behavior of your problem depend on the order in the classpath, i've experienced this kind of bugs with two different libraries requiring different version of ASM, at runtime, a class of the older version was calling a class of the newer version :( - security, if you allow split packages, you allow anybody to insert any classes in any packages. regards, R?mi ----- Mail original ----- > De: "Jochen Theodorou" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Vendredi 4 Novembre 2016 09:11:51 > Objet: The split package problem > Hi all, > > I do often read about this "split package problem", but I never did see > a proper explanation about why it matters to jigsaw so much that we do > not allow it. Can somebody enlighten me? > > bye Jochen From blackdrag at gmx.org Fri Nov 4 08:57:14 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 09:57:14 +0100 Subject: Unsafe and AwkwardStrongEncapsulation In-Reply-To: <84bc1345-bae9-a2c0-6113-10bc9c8be0b5@oracle.com> References: <20161027155336.DBCE7DA329@eggemoggin.niobe.net> <1C97C371-66E1-4770-9307-FEE6CB912B81@paremus.com> <20161103163252.220277226> <581C4162.3080407@gmx.org> <84bc1345-bae9-a2c0-6113-10bc9c8be0b5@oracle.com> Message-ID: <581C4D6A.1000509@gmx.org> On 04.11.2016 09:12, Alan Bateman wrote: > On 04/11/2016 08:05, Jochen Theodorou wrote: > >> Since Unsafe was mentioned here... All the ways I did know to get to >> Unsafe required reflection on private members. Afaik >> #AwkwardStrongEncapsulation will block that. So how can I still use >> Unsafe in the future or did it get some "proper" public way to get >> hold of an Unsafe by now and I missed that? > I think you are looking for JEP 260 [1]. The critical internal APIs > where it lists the "critical internal APIs" that are not encapsulated in > JDK 9. If you are using the Jigsaw EA builds then look at `java > --list-modules jdk.unsupported` where you'll see that sun.misc (and > sun.reflect) are both exported and open. > > -Alan > > [1] http://openjdk.java.net/jeps/260 I see > module jdk.unsupported { > > exports sun.misc; > > exports sun.reflect; > > exports com.sun.nio.file; > > } That won?t get me access to private fields and constructors in Unsafe with AwkwardStrongEncapsulation, right? So I see exported, but I don?t know what you mean with "open" here. I thought we do not have open modules yet... if we have, I missed the way to declare them and what they now actually do. bye Jochen From Alan.Bateman at oracle.com Fri Nov 4 09:09:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 09:09:43 +0000 Subject: Unsafe and AwkwardStrongEncapsulation In-Reply-To: <581C4D6A.1000509@gmx.org> References: <20161027155336.DBCE7DA329@eggemoggin.niobe.net> <1C97C371-66E1-4770-9307-FEE6CB912B81@paremus.com> <20161103163252.220277226> <581C4162.3080407@gmx.org> <84bc1345-bae9-a2c0-6113-10bc9c8be0b5@oracle.com> <581C4D6A.1000509@gmx.org> Message-ID: On 04/11/2016 08:57, Jochen Theodorou wrote: > > That won?t get me access to private fields and constructors in Unsafe > with AwkwardStrongEncapsulation, right? So I see exported, but I don?t > know what you mean with "open" here. I thought we do not have open > modules yet... if we have, I missed the way to declare them and what > they now actually do. Unsafe is at the level of peeking and poking at fields in objects, there is no access control. The proposal for open modules (and open packages) was sent to jpms-spec-experts last week [1]. -Alan [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html From blackdrag at gmx.org Fri Nov 4 09:22:21 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 10:22:21 +0100 Subject: The split package problem In-Reply-To: <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> Message-ID: <581C534D.9050408@gmx.org> On 04.11.2016 09:25, Remi Forax wrote: > There are two issues with split packages, > - if you have the same class in each part of the package, the behavior of your problem depend on the order in the classpath, > i've experienced this kind of bugs with two different libraries requiring different version of ASM, at runtime, a class of the older version was calling a class of the newer version :( > - security, if you allow split packages, you allow anybody to insert any classes in any packages. ok, not sure if I agree that these are reason enough for the annoyance, but at least I know the proper reason now ;) bye Jochen From Alan.Bateman at oracle.com Fri Nov 4 09:33:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 09:33:24 +0000 Subject: The split package problem In-Reply-To: <581C534D.9050408@gmx.org> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> Message-ID: <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> On 04/11/2016 09:22, Jochen Theodorou wrote: > On 04.11.2016 09:25, Remi Forax wrote: >> There are two issues with split packages, >> - if you have the same class in each part of the package, the >> behavior of your problem depend on the order in the classpath, >> i've experienced this kind of bugs with two different libraries >> requiring different version of ASM, at runtime, a class of the older >> version was calling a class of the newer version :( >> - security, if you allow split packages, you allow anybody to insert >> any classes in any packages. > > ok, not sure if I agree that these are reason enough for the > annoyance, but at least I know the proper reason now ;) This is all part of reliable configuration where you can prove correctness by construction. Alex's "Under the Hood" session from JavaOne 2016 [1] is a great resource for understanding the science. -Alan [1] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016 From alessiostalla at gmail.com Fri Nov 4 09:33:36 2016 From: alessiostalla at gmail.com (Alessio Stalla) Date: Fri, 4 Nov 2016 10:33:36 +0100 Subject: The split package problem In-Reply-To: <581C534D.9050408@gmx.org> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> Message-ID: Also, I think there is a problem related to how class loading works. In the vanilla world of Java apps with a single classloader, if you load classes in the same (source) package from different sources, the end up in the same (runtime) package. But if you have different classloaders at play, and load a class p.C1 from classloader 1 and p.C2 from classloader 2, even if they share the same (source) package, p, they end up in different (runtime) packages, let's call them p(1) and p(2). Therefore, C2 cannot access the protected members of C1. That can be confusing. On 4 November 2016 at 10:22, Jochen Theodorou wrote: > On 04.11.2016 09:25, Remi Forax wrote: > >> There are two issues with split packages, >> - if you have the same class in each part of the package, the behavior of >> your problem depend on the order in the classpath, >> i've experienced this kind of bugs with two different libraries >> requiring different version of ASM, at runtime, a class of the older >> version was calling a class of the newer version :( >> - security, if you allow split packages, you allow anybody to insert any >> classes in any packages. >> > > ok, not sure if I agree that these are reason enough for the annoyance, > but at least I know the proper reason now ;) > > bye Jochen > From blackdrag at gmx.org Fri Nov 4 10:04:01 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 11:04:01 +0100 Subject: The split package problem In-Reply-To: <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> Message-ID: <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> On 04.11.2016 10:33, Alan Bateman wrote: [...] > This is all part of reliable configuration where you can prove > correctness by construction. Alex's "Under the Hood" session from > JavaOne 2016 [1] is a great resource for understanding the science. > > -Alan > > [1] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016 I could now go into lengths as of why I do not believe in proven correctness by construction, but that is probably too offtopic here ;) What I see mostly is that all the problems you have now on a per class level, you later have on a per module level again... for example needing two versions of the same library being active at the same time... and the movement away from the static module descriptor to a dynamic module loading system with layers and all kinds of shenanigans that will bypass these efforts in the end again bye JCoehn From Alan.Bateman at oracle.com Fri Nov 4 10:21:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 10:21:28 +0000 Subject: The split package problem In-Reply-To: <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> Message-ID: <7df339b3-c17b-bf5e-ae39-5f9f71d26b3f@oracle.com> On 04/11/2016 10:04, Jochen Theodorou wrote: > : > > What I see mostly is that all the problems you have now on a per class > level, you later have on a per module level again... for example > needing two versions of the same library being active at the same > time... and the movement away from the static module descriptor to a > dynamic module loading system with layers and all kinds of shenanigans > that will bypass these efforts in the end again I'm not sure what you mean here but reliable configuration extends to layers of modules too. When creating the configuration for a layer then you can't have a module M that reads two other modules (irrespective of which layer they are in) that export the same package to M. So what is the background to this thread, are you running into a split package issue when trying to migrate something to modules? -Alan From sundararajan.athijegannathan at oracle.com Fri Nov 4 10:36:13 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 04 Nov 2016 16:06:13 +0530 Subject: RFR 8166286: jmod fails on symlink to directory Message-ID: <581C649D.5020902@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8166286 Thanks, -Sundar From Alan.Bateman at oracle.com Fri Nov 4 10:40:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 10:40:28 +0000 Subject: RFR 8166286: jmod fails on symlink to directory In-Reply-To: <581C649D.5020902@oracle.com> References: <581C649D.5020902@oracle.com> Message-ID: <707e60ec-6a61-57a2-d60e-f191f22b8b60@oracle.com> On 04/11/2016 10:36, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8166286 This is probably okay, if only to be consistent with the other tools. Can you fix the overly long time in JmodTask.java, otherwise future side-by-side diffs will require a lot of horizontal scrolling. For the test then the other jlink tests are using module names like m1, m2, ... would be good to try to keep that consistent if you can. Also the @bug is in the wrong place. -Alan From adinn at redhat.com Fri Nov 4 10:50:13 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 4 Nov 2016 10:50:13 +0000 Subject: The split package problem In-Reply-To: <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> Message-ID: On 04/11/16 10:04, Jochen Theodorou wrote: > What I see mostly is that all the problems you have now on a per class > level, you later have on a per module level again... for example needing > two versions of the same library being active at the same time... and > the movement away from the static module descriptor to a dynamic module > loading system with layers and all kinds of shenanigans that will bypass > these efforts in the end again Whatever complexity might be involved in managing module layers I think it's an overstatement to say that the situation will return to the status quo: - Modules stop you providing two versions of a package in the same layer, a problem for classpath deployment which, as Remi noted, can easily lead to you mixing classes from two different versions of a library. - You can indeed use a dynamic module loading system based on layers to introduce versions of the same classes in different layers. However, the unique package ownership requirements means that those layers cannot partake in an ancestor relationship again with the result that duplicate classes cannot then be conflated in the way Remi described. So, it seems from the above that layers are indeed a structured way to avoid one of the major causes of 'classloader hell' precisely because they detect and reject deployments which introduce these ambiguities in resolution. Are you suggesting that modules will not provide this specific benefit or that some other problem will render it of no importance? If the former can you explain why? If the latter can you explain what that other problem is? 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 adinn at redhat.com Fri Nov 4 10:55:32 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 4 Nov 2016 10:55:32 +0000 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> Message-ID: On 04/11/16 09:33, Alessio Stalla wrote: > Also, I think there is a problem related to how class loading works. In the > vanilla world of Java apps with a single classloader, if you load classes > in the same (source) package from different sources, the end up in the same > (runtime) package. But if you have different classloaders at play, and load > a class p.C1 from classloader 1 and p.C2 from classloader 2, even if they > share the same (source) package, p, they end up in different (runtime) > packages, let's call them p(1) and p(2). Therefore, C2 cannot access the > protected members of C1. That can be confusing. Modules are not going to stop you having two different runtime versions of a class. You can do that by loading the same module in two unrelated module layers. However, what is guaranteed is that those two versions cannot be conflated thanks to resolution-time ambiguity. n.b. the above only applies ot code in named modules; classpath deployment still allows split packages and hence is still susceptible to resolution-time ambiguity. regards, Andrew Dinn ----------- From cedric.champeau at gmail.com Fri Nov 4 11:06:38 2016 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Fri, 4 Nov 2016 12:06:38 +0100 Subject: The split package problem In-Reply-To: <7df339b3-c17b-bf5e-ae39-5f9f71d26b3f@oracle.com> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <7df339b3-c17b-bf5e-ae39-5f9f71d26b3f@oracle.com> Message-ID: > > > > So what is the background to this thread, are you running into a split > package issue when trying to migrate something to modules? > > -Alan > I cannot speak for Jochen but at least this is something we have been discussing for a long time on the Groovy MLs since we know Jigsaw will prevent split packages. Basically our problem is binary backwards compatibility. Groovy has a long history, so before Groovy 2.0, everything was found in a single jar. We provided several versions of Groovy (we still do), but that is more a dependency management issue. The real problem is more that after Groovy 2 we started splitting Groovy into different jars. But for backwards compatibility we didn't change the packages. So you can find classes in package groovy.util in both the `groovy-core` jar and the `groovy-xml` jar. Those jars would be obvious candidates for modules but as split packages are not allowed this is not possible. This doesn't give us many options. I was in favor of breaking everything, since Jigsaw is a long journey in any case, and leverage that to have Groovy 3 use different packages. Of course not everybody is happy with this, because it's a huge issue for all existing libraries that rely on "old" packages. We would basically break every Groovy program out there. Both at the source and binary level. It's a very big issue, typically all Gradle plugins written in Groovy would break. Gradle itself would break. There are things to mitigate that, like rewriting classes at load time, or an easier solution which is to have a single Groovy module for all (and come back to the monolith era, sigh...). We haven't made any decision yet. Not something we can take easy. From james.laskey at oracle.com Fri Nov 4 11:26:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 4 Nov 2016 08:26:12 -0300 Subject: RFR 8166286: jmod fails on symlink to directory In-Reply-To: <581C649D.5020902@oracle.com> References: <581C649D.5020902@oracle.com> Message-ID: <3BAF326F-89E6-40EF-841D-ADA67A35E1A0@oracle.com> +1 > On Nov 4, 2016, at 7:36 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8166286 > > Thanks, > -Sundar From Alan.Bateman at oracle.com Fri Nov 4 11:34:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 11:34:14 +0000 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <7df339b3-c17b-bf5e-ae39-5f9f71d26b3f@oracle.com> Message-ID: <6a5edc18-0560-1ef2-82cf-21f7175ebf3e@oracle.com> On 04/11/2016 11:06, C?dric Champeau wrote: > : > > We haven't made any decision yet. Not something we can take easy. Understood, and not for me to say, but I would assume the priority has to be to get Groovy working with JDK 9 first, maybe this is what Jochen's other thread about Unsafe is about. -Alan From sundararajan.athijegannathan at oracle.com Fri Nov 4 11:34:25 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 4 Nov 2016 17:04:25 +0530 Subject: RFR 8166286: jmod fails on symlink to directory In-Reply-To: <707e60ec-6a61-57a2-d60e-f191f22b8b60@oracle.com> References: <581C649D.5020902@oracle.com> <707e60ec-6a61-57a2-d60e-f191f22b8b60@oracle.com> Message-ID: <7ed89cb6-a55a-059b-ca4d-d141f4afdc14@oracle.com> Hi, Thanks for the review. Please find the updated webrev: http://cr.openjdk.java.net/~sundar/8166286/webrev.01/ * Reduced line length in JmodTask.java * Removed @bug comment - earlier I attempted a separate test file for this - comment carried over from that step. Using ordinary comment now * On module names: This jmod test file uses names like "foo" (unlike jlink tests). Hope the module name is fine. Thanks. -Sundar On 11/4/2016 4:10 PM, Alan Bateman wrote: > > > On 04/11/2016 10:36, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8166286 > This is probably okay, if only to be consistent with the other tools. > Can you fix the overly long time in JmodTask.java, otherwise future > side-by-side diffs will require a lot of horizontal scrolling. > > For the test then the other jlink tests are using module names like > m1, m2, ... would be good to try to keep that consistent if you can. > Also the @bug is in the wrong place. > > -Alan From sander.mak at luminis.eu Fri Nov 4 11:36:49 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Fri, 4 Nov 2016 11:36:49 +0000 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <7df339b3-c17b-bf5e-ae39-5f9f71d26b3f@oracle.com> Message-ID: > On 04 Nov 2016, at 12:06, C?dric Champeau wrote: > > It's a very big issue, typically all Gradle plugins written in Groovy would > break. Gradle itself would break. There are things to mitigate that, like > rewriting classes at load time, or an easier solution which is to have a > single Groovy module for all (and come back to the monolith era, sigh...). Wouldn't a better solution be to provide a groovy-all module that 'requires transitive' the other actual groovy modules. That leaves you, as a library designer, the freedom to modularise freely behind the scenes (probably moving the split packages back together in a module), while not burdening users who just want to grab groovy and run with it. People who do know they actually only use parts are free to require just the modules they need, without using groovy-all. That does admittedly not solve the problem of breaking backward compatibility for non-Java 9 users. Sander From blackdrag at gmx.org Fri Nov 4 13:19:56 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 14:19:56 +0100 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <7df339b3-c17b-bf5e-ae39-5f9f71d26b3f@oracle.com> Message-ID: On 04.11.2016 12:36, Sander Mak wrote: > >> On 04 Nov 2016, at 12:06, C?dric Champeau wrote: >> >> It's a very big issue, typically all Gradle plugins written in Groovy would >> break. Gradle itself would break. There are things to mitigate that, like >> rewriting classes at load time, or an easier solution which is to have a >> single Groovy module for all (and come back to the monolith era, sigh...). > > > Wouldn't a better solution be to provide a groovy-all module that 'requires transitive' the other actual groovy modules. I agree in that we should have done this... but > (probably moving the split packages back together in a module) that is exactly the problem. if you move them back, you get half of the dependencies along, which makes the modules itself kind of obsolete. bye Jochen From blackdrag at gmx.org Fri Nov 4 13:22:05 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 14:22:05 +0100 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> Message-ID: On 04.11.2016 11:50, Andrew Dinn wrote: [...] > - Modules stop you providing two versions of a package in the same > layer, a problem for classpath deployment which, as Remi noted, can > easily lead to you mixing classes from two different versions of a library. but sometimes you have to do something similar to that. Usually you then start with classloader magic and have to find your way around "duplicated classes". What is targeted with modules is that this is done by accident. And frankly, my experience was that those accidental cases have been resolved pretty fast. > - You can indeed use a dynamic module loading system based on layers to > introduce versions of the same classes in different layers. However, the > unique package ownership requirements means that those layers cannot > partake in an ancestor relationship again with the result that duplicate > classes cannot then be conflated in the way Remi described. sure, nobody really needs that on the classpath... except for a poor mans patching. > So, it seems from the above that layers are indeed a structured way to > avoid one of the major causes of 'classloader hell' precisely because > they detect and reject deployments which introduce these ambiguities in > resolution. "classloader hell" goes far beyond the classpath. The problem is rarely caused by a classloader that loads two versions of the same library with different classes. But happens then more easily if your classloaders suddenly have to become forests. Frankly I do not see how modules will avoid that. > Are you suggesting that modules will not provide this specific benefit > or that some other problem will render it of no importance? If the > former can you explain why? If the latter can you explain what that > other problem is? well... assume you have an application and it requires the library A, which transitively requires B-1. the application also requires library C, which transitively requires B-2. B-1 and B-2 are not compatible. library A and D leak instances of classes of B-1 and B-2 to the application. Problem number 1, how to start this if application, A, D, B-1 and B-2 are modules? You don't care that the module system does not allow for this, you have to run it in that configuration and you have to have a way around this. Which means you will have to load modules dynamically in different layers. At this point the benefit already become a burden and is nullified as benefit. Problem number 2... the layers in which B-1 and B-2 reside in still have their own versions of classes, which are by name equal in B-1 and B-2. If application is actually using classes directly from B-1 or B-2 you get the classloader hell problem, just the same as you would without the module system beyond considering the classpath. bye Jochen From Alan.Bateman at oracle.com Fri Nov 4 14:29:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 14:29:42 +0000 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> Message-ID: On 04/11/2016 13:22, Jochen Theodorou wrote: > : > > well... assume you have an application and it requires the library A, > which transitively requires B-1. the application also requires library > C, which transitively requires B-2. B-1 and B-2 are not compatible. > library A and D leak instances of classes of B-1 and B-2 to the > application. Assuming B-1 and B-2 export the same packages, A `requires transitive B-1` (because a method in A's API returns a B type), C `requires transitive B-2` (because a method in C's API returns a B type) then you will get an exception when attempting to create the configuration. The exception will tell you that the application module reads two modules (B-2 and B-2) that export the same package to the application. Attempting to do this with multiple configuration + layers isn't going to help, it's just not safe, and you'll get the same exception. You can of course go off-piste and use the reflective API to have the application read both B-1 and B-2, and if it its your own class loaders then you can go crazy with split delegation, but that is not something that you get out of the box. -Alan From adinn at redhat.com Fri Nov 4 14:54:45 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 4 Nov 2016 14:54:45 +0000 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> Message-ID: <88dd139b-6344-1f52-fc15-9e5df363922a@redhat.com> On 04/11/16 13:22, Jochen Theodorou wrote: > "classloader hell" goes far beyond the classpath. The problem is rarely > caused by a classloader that loads two versions of the same library with > different classes. But happens then more easily if your classloaders > suddenly have to become forests. Frankly I do not see how modules will > avoid that. Yes, indeed, "classloader hell" goes far beyond the classpath. Jigsaw provides a structured way of dealing with the specific aspect of the classloader problem Remi mentioned viz detecting and rejecting resolve-time ambiguities. That doesn't avoid the possibility of runtime ambiguity i.e. you can still pass an instance of Foo as loaded by layer A to code which has its own version of Foo as loaded by layer B and get an error. I don't think I claimed Jigsaw was Dr Quack's Patent Snake Oil Remedy and Cure-All rather that it would be of some help :-) > well... assume you have an application and it requires the library A, > which transitively requires B-1. the application also requires library > C, which transitively requires B-2. B-1 and B-2 are not compatible. > library A and D leak instances of classes of B-1 and B-2 to the > application. > > Problem number 1, how to start this if application, A, D, B-1 and B-2 > are modules? You don't care that the module system does not allow for > this, you have to run it in that configuration and you have to have a > way around this. Which means you will have to load modules dynamically > in different layers. At this point the benefit already become a burden > and is nullified as benefit. Is this any more of a burden than 1) having to have arrange a tree of classloaders to ensure that A sees B1 and D sees B2 and 2) then ensuring that instances of B1 and B2 leaked from A and D don't get conflated by the app? Would that not by the same token nullify the benefits of having a classpath? > Problem number 2... the layers in which B-1 and B-2 reside in still have > their own versions of classes, which are by name equal in B-1 and B-2. > If application is actually using classes directly from B-1 or B-2 you > get the classloader hell problem, just the same as you would without the > module system beyond considering the classpath. Yes, fixing resolve-time ambiguity doesn't fix runtime ambiguity. So, if your problem is runtime ambiguity then you'll still have to fix that. But not being able to fix one mess doesn't mean Jigsaw is of no help for another mess. 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 Fri Nov 4 15:48:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 15:48:40 +0000 Subject: RFR 8166286: jmod fails on symlink to directory In-Reply-To: <7ed89cb6-a55a-059b-ca4d-d141f4afdc14@oracle.com> References: <581C649D.5020902@oracle.com> <707e60ec-6a61-57a2-d60e-f191f22b8b60@oracle.com> <7ed89cb6-a55a-059b-ca4d-d141f4afdc14@oracle.com> Message-ID: On 04/11/2016 11:34, Sundararajan Athijegannathan wrote: > Hi, > > Thanks for the review. Please find the updated webrev: > http://cr.openjdk.java.net/~sundar/8166286/webrev.01/ > > * Reduced line length in JmodTask.java > * Removed @bug comment - earlier I attempted a separate test file for > this - comment carried over from that step. > Using ordinary comment now > * On module names: This jmod test file uses names like "foo" (unlike > jlink tests). Hope the module name is fine. > This looks okay although I think it would be better to have a @bug in the test description with 8142968, then add to it as needed when there are bug fixes. -Alan From alan.bateman at oracle.com Fri Nov 4 16:32:37 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 04 Nov 2016 16:32:37 +0000 Subject: hg: jigsaw/jake/jaxp: More clean-up of Provides Message-ID: <201611041632.uA4GWbtZ013191@aojmv0008.oracle.com> Changeset: 92b89631b7b2 Author: alanb Date: 2016-11-04 15:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/92b89631b7b2 More clean-up of Provides ! test/javax/xml/jaxp/module/ServiceProviderTest/src/unnamed/Main.java From alan.bateman at oracle.com Fri Nov 4 16:32:55 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 04 Nov 2016 16:32:55 +0000 Subject: hg: jigsaw/jake/langtools: More clean-up of Provides Message-ID: <201611041632.uA4GWt4c013304@aojmv0008.oracle.com> Changeset: 258783abd899 Author: alanb Date: 2016-11-04 15:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/258783abd899 More clean-up of Provides ! 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/ModuleInfoBuilder.java From alan.bateman at oracle.com Fri Nov 4 16:33:13 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 04 Nov 2016 16:33:13 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611041633.uA4GXDPn013405@aojmv0008.oracle.com> Changeset: 92473a4168e5 Author: alanb Date: 2016-11-04 14:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92473a4168e5 Improve getResourceXXX to avoid scanning all resources in all modules ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java Changeset: 4660af97ecb4 Author: alanb Date: 2016-11-04 15:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4660af97ecb4 More clean-up of Provides ! 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/Module.java ! src/java.base/share/classes/java/util/ServiceLoader.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/ServicesCatalog.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/AutomaticModulesTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/jdk/modules/scenarios/automaticmodules/src/sptest/test/Main.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/JLinkTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java From blackdrag at gmx.org Fri Nov 4 16:50:36 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 17:50:36 +0100 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> Message-ID: <581CBC5C.4040000@gmx.org> On 04.11.2016 15:29, Alan Bateman wrote: > On 04/11/2016 13:22, Jochen Theodorou wrote: > >> : >> >> well... assume you have an application and it requires the library A, >> which transitively requires B-1. the application also requires library >> C, which transitively requires B-2. B-1 and B-2 are not compatible. >> library A and D leak instances of classes of B-1 and B-2 to the >> application. > > Assuming B-1 and B-2 export the same packages, A `requires transitive > B-1` (because a method in A's API returns a B type), C `requires > transitive B-2` (because a method in C's API returns a B type) then you > will get an exception when attempting to create the configuration. The > exception will tell you that the application module reads two modules > (B-2 and B-2) that export the same package to the application. I can compile the application if there is only B-1 or B-2 available at that time, regardless of if that is actually the wrong version for A or C. jigsaw does after all not care about the versions. This would mean the application cannot be run with only B-1 or B-2 of course. And it means I cannot run the application normally either. > Attempting to do this with multiple configuration + layers isn't going > to help, it's just not safe, and you'll get the same exception. One layer with B-1 and C and another with B-2 and D and my application "reading" from those layers... is that something that cannot be done? So far I had the impression I can > You can of course go off-piste and use the reflective API to have the > application read both B-1 and B-2, and if it its your own class loaders > then you can go crazy with split delegation, but that is not something > that you get out of the box. you rarely get the classloader hell problem out of the box either. And configurations like the ones above are not all that rare for me... just so far that had been with classloaders only, now it would be with classloader and modules and layers bye Jochen From blackdrag at gmx.org Fri Nov 4 16:53:57 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 4 Nov 2016 17:53:57 +0100 Subject: The split package problem In-Reply-To: <88dd139b-6344-1f52-fc15-9e5df363922a@redhat.com> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <88dd139b-6344-1f52-fc15-9e5df363922a@redhat.com> Message-ID: <581CBD25.5000903@gmx.org> On 04.11.2016 15:54, Andrew Dinn wrote: [...] >> Problem number 1, how to start this if application, A, D, B-1 and B-2 >> are modules? You don't care that the module system does not allow for >> this, you have to run it in that configuration and you have to have a >> way around this. Which means you will have to load modules dynamically >> in different layers. At this point the benefit already become a burden >> and is nullified as benefit. > > Is this any more of a burden than 1) having to have arrange a tree of > classloaders to ensure that A sees B1 and D sees B2 and 2) then ensuring > that instances of B1 and B2 leaked from A and D don't get conflated by > the app? Would that not by the same token nullify the benefits of having > a classpath? the classpath is not there to solve this. >> Problem number 2... the layers in which B-1 and B-2 reside in still have >> their own versions of classes, which are by name equal in B-1 and B-2. >> If application is actually using classes directly from B-1 or B-2 you >> get the classloader hell problem, just the same as you would without the >> module system beyond considering the classpath. > > Yes, fixing resolve-time ambiguity doesn't fix runtime ambiguity. So, if > your problem is runtime ambiguity then you'll still have to fix that. > But not being able to fix one mess doesn't mean Jigsaw is of no help for > another mess. for the other mess I usually use gradle bye Jochen From Alan.Bateman at oracle.com Sat Nov 5 07:39:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 5 Nov 2016 07:39:28 +0000 Subject: The split package problem In-Reply-To: <581CBC5C.4040000@gmx.org> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <581CBC5C.4040000@gmx.org> Message-ID: On 04/11/2016 16:50, Jochen Theodorou wrote: > : > >> Attempting to do this with multiple configuration + layers isn't going >> to help, it's just not safe, and you'll get the same exception. > > One layer with B-1 and C and another with B-2 and D and my application > "reading" from those layers... is that something that cannot be done? > So far I had the impression I can The application module reads other modules rather than layers, in this case it results in the application module reading C, B-1, D, and B-2 (assuming that the application modules `requires C` and `requires D` and both of these modules `requires transitive B`). This will fail because the application reads B-1 and B-2, both of which export the same packages to the application module. -Alan From blackdrag at gmx.org Sat Nov 5 10:29:55 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 5 Nov 2016 11:29:55 +0100 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <581CBC5C.4040000@gmx.org> Message-ID: <581DB4A3.3080209@gmx.org> On 05.11.2016 08:39, Alan Bateman wrote: > On 04/11/2016 16:50, Jochen Theodorou wrote: > >> : >> >>> Attempting to do this with multiple configuration + layers isn't going >>> to help, it's just not safe, and you'll get the same exception. >> >> One layer with B-1 and C and another with B-2 and D and my application >> "reading" from those layers... is that something that cannot be done? >> So far I had the impression I can > The application module reads other modules rather than layers, in this > case it results in the application module reading C, B-1, D, and B-2 > (assuming that the application modules `requires C` and `requires D` and > both of these modules `requires transitive B`). This will fail because > the application reads B-1 and B-2, both of which export the same > packages to the application module. And if that is done at runtime ti still fails? bye Jochen From Alan.Bateman at oracle.com Sat Nov 5 12:56:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 5 Nov 2016 12:56:09 +0000 Subject: The split package problem In-Reply-To: <581DB4A3.3080209@gmx.org> References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <581CBC5C.4040000@gmx.org> <581DB4A3.3080209@gmx.org> Message-ID: On 05/11/2016 10:29, Jochen Theodorou wrote: > On 05.11.2016 08:39, Alan Bateman wrote: >> >> The application module reads other modules rather than layers, in this >> case it results in the application module reading C, B-1, D, and B-2 >> (assuming that the application modules `requires C` and `requires D` and >> both of these modules `requires transitive B`). This will fail because >> the application reads B-1 and B-2, both of which export the same >> packages to the application module. > > And if that is done at runtime ti still fails? The exception will be thrown when you attempt to create the configuration containing the application module. So yes, it's run time, there is no equivalent at compile or link time because this is dynamically created configurations + layers. -Alan From blackdrag at gmx.org Sat Nov 5 15:03:25 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 5 Nov 2016 16:03:25 +0100 Subject: The split package problem In-Reply-To: References: <581C42C7.1010409@gmx.org> <432208134.1501363.1478247906349.JavaMail.zimbra@u-pem.fr> <581C534D.9050408@gmx.org> <46c9dd5a-3d00-23fd-88b5-94a657054495@oracle.com> <82e94cbc-1e94-a9c2-59c9-aedf6e3c16e5@gmx.org> <581CBC5C.4040000@gmx.org> <581DB4A3.3080209@gmx.org> Message-ID: <581DF4BD.8040500@gmx.org> On 05.11.2016 13:56, Alan Bateman wrote: > > > On 05/11/2016 10:29, Jochen Theodorou wrote: >> On 05.11.2016 08:39, Alan Bateman wrote: >>> >>> The application module reads other modules rather than layers, in this >>> case it results in the application module reading C, B-1, D, and B-2 >>> (assuming that the application modules `requires C` and `requires D` and >>> both of these modules `requires transitive B`). This will fail because >>> the application reads B-1 and B-2, both of which export the same >>> packages to the application module. >> >> And if that is done at runtime ti still fails? > The exception will be thrown when you attempt to create the > configuration containing the application module. So yes, it's run time, > there is no equivalent at compile or link time because this is > dynamically created configurations + layers. so it is possible at runtime. Still I don?t get why it should fail at compile time. if the application requires C and D and they require each B...ahh, the misunderstanding is probably that B-1 and B-2 are two versions of the module B. Of course I would not compile my application with B-1 and B-2 being there at the same time. But I can compile using either of them as B. Since there is only one of them, there will be no compile time failure... unless application uses something from B-1, that does not exist in B-2 and something from B-2 that does not exist in B-1. But that would not work out at runtime either. bye Jochen From mandy.chung at oracle.com Sat Nov 5 19:03:45 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 05 Nov 2016 19:03:45 +0000 Subject: hg: jigsaw/jake: 19 new changesets Message-ID: <201611051903.uA5J3jTS021549@aojmv0008.oracle.com> Changeset: f5994f5d5041 Author: simonis Date: 2016-10-06 13:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f5994f5d5041 8166800: [s390] Top-level build changes required for Linux/s390x Reviewed-by: erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 9c672c28d79e Author: amurillo Date: 2016-10-13 08:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9c672c28d79e Merge ! common/autoconf/generated-configure.sh Changeset: b48a9b312524 Author: ctornqvi Date: 2016-10-18 06:14 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b48a9b312524 8166738: Enable concurrency in Hotspot jtreg testing Reviewed-by: gtriantafill, erikj, sspitsyn ! test/Makefile Changeset: 808cae9bfff0 Author: amurillo Date: 2016-10-20 16:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/808cae9bfff0 Merge Changeset: 530dbcad379e Author: amurillo Date: 2016-10-25 12:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/530dbcad379e Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: f37e46c2e8f6 Author: ihse Date: 2016-10-26 09:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f37e46c2e8f6 8168636: More detailed information about native libraries in build log Reviewed-by: erikj ! make/common/NativeCompilation.gmk Changeset: db49e4e492e0 Author: ihse Date: 2016-10-26 16:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/db49e4e492e0 8168772: Convert javadoc generation to build-infra standards Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/Javadoc.gmk ! make/Main.gmk ! make/MainSupport.gmk Changeset: 598f26abc418 Author: prr Date: 2016-10-18 13:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/598f26abc418 8167126: Create a module to provide access to non-SE desktop APIs Reviewed-by: alanb, mchung ! make/common/Modules.gmk Changeset: 1c775a40f22e Author: prr Date: 2016-10-19 08:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1c775a40f22e Merge Changeset: 758bf38c3ee8 Author: prr Date: 2016-10-27 08:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/758bf38c3ee8 Merge Changeset: 3a9475875203 Author: ddehaven Date: 2016-10-27 09:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3a9475875203 8167187: Exported elements referring to inaccessible types in jdk.jsobject Reviewed-by: mchung, alanb ! make/CompileJavaModules.gmk Changeset: 5b0818f52a62 Author: lana Date: 2016-10-27 21:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5b0818f52a62 Merge Changeset: b913840943c0 Author: erikj Date: 2016-10-28 14:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b913840943c0 8062810: Examine src.zip in JDK image and decide if source classes should be organized by module Reviewed-by: mchung, kcr ! make/CompileJavaModules.gmk ! make/ZipSource.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk ! make/common/ZipArchive.gmk Changeset: a327b728bbe7 Author: erikj Date: 2016-10-31 16:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a327b728bbe7 8168950: Incremental build of images always rebuilds jmods Reviewed-by: tbell ! make/ExplodedImageOptimize.gmk Changeset: 7b791b507f9b Author: erikj Date: 2016-11-01 15:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7b791b507f9b 8168982: Missing dependency for docs-copy Reviewed-by: tbell ! make/Main.gmk Changeset: 772958837ba7 Author: jlahoda Date: 2016-11-02 07:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/772958837ba7 8131019: jshell tool: access javadoc from tool Summary: Disabling doclint on jdk.compiler/jdk.internal.* packages, to disable lint on newly added jdk.compiler/jdk.internal.shellsupport.doc package. Reviewed-by: jjg, rfield ! make/CompileJavaModules.gmk Changeset: 1fc62b1c629f Author: erikj Date: 2016-11-02 10:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1fc62b1c629f 8063154: Checked in jvmti.h not in sync with generated jvmti.h Reviewed-by: tbell ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 9f65970f778d Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9f65970f778d Added tag jdk-9+143 for changeset 1fc62b1c629f ! .hgtags Changeset: 12583438ea5e Author: mchung Date: 2016-11-05 12:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/12583438ea5e Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/CompileJavaModules.gmk ! make/Javadoc.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/ZipSource.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/common/ZipArchive.gmk From mandy.chung at oracle.com Sat Nov 5 19:03:52 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 05 Nov 2016 19:03:52 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201611051903.uA5J3qbv021612@aojmv0008.oracle.com> Changeset: d4f1dae17409 Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/d4f1dae17409 Added tag jdk-9+143 for changeset 6211236ef15e ! .hgtags Changeset: 48350ae6200f Author: mchung Date: 2016-11-05 12:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/48350ae6200f Merge From mandy.chung at oracle.com Sat Nov 5 19:04:17 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 05 Nov 2016 19:04:17 +0000 Subject: hg: jigsaw/jake/hotspot: 85 new changesets Message-ID: <201611051904.uA5J4IsD021830@aojmv0008.oracle.com> Changeset: a2f56f1169d4 Author: rprotacio Date: 2016-09-29 13:32 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a2f56f1169d4 8160064: StackWalker implementation added logging option without using UL Summary: Moved StackWalk logging to Unified Logging framework Reviewed-by: coleenp, mockner, dholmes, mchung ! src/share/vm/logging/logTag.hpp ! src/share/vm/prims/stackwalk.cpp ! src/share/vm/runtime/globals.hpp + test/runtime/logging/StackWalkTest.java Changeset: 6f05f0a297a1 Author: rprotacio Date: 2016-09-29 18:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6f05f0a297a1 Merge ! src/share/vm/runtime/globals.hpp - src/share/vm/utilities/chunkedList.cpp - test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java - test/runtime/SharedArchiveFile/SASymbolTableTestAttachee.java Changeset: a6934ab21a0b Author: amurillo Date: 2016-09-30 03:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a6934ab21a0b Merge Changeset: a575b5865683 Author: ccheung Date: 2016-09-30 12:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a575b5865683 8166930: minor cleanups 1) remove reference to ZIP_ReadMappedEntry 2) checking of st_mode Reviewed-by: jiangli, lfoltan ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/logging/logFileOutput.cpp ! src/share/vm/memory/filemap.cpp Changeset: a0d5b9a2a9ec Author: kzhaldyb Date: 2016-09-28 18:40 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a0d5b9a2a9ec 8166462: Convert TestResourcehash_test to Gtest Reviewed-by: mgerdin, iignatyev ! src/share/vm/utilities/internalVMTests.cpp - src/share/vm/utilities/resourceHash.cpp + test/native/utilities/test_resourceHash.cpp Changeset: 4962f9f46728 Author: dholmes Date: 2016-10-03 21:48 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4962f9f46728 8081800: AbstractMethodError when evaluating a private method in an interface via debugger Reviewed-by: acorn, dcubed, coleenp ! make/test/JtregNative.gmk ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp + test/runtime/RedefineTests/RedefineInterfaceMethods.java + test/runtime/jni/PrivateInterfaceMethods/PrivateInterfaceMethods.java + test/runtime/jni/PrivateInterfaceMethods/libPrivateInterfaceMethods.c ! test/runtime/logging/ItablesTest.java Changeset: d9960bd9fb6d Author: enevill Date: 2016-05-24 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9960bd9fb6d 8157708: aarch64: StrIndexOfChar intrinsic is not implemented Reviewed-by: aph Contributed-by: ningsheng.jian at linaro.org ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp Changeset: bb17fd6f2e36 Author: iignatyev Date: 2016-10-04 21:20 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bb17fd6f2e36 8166925: several native TESTs should be changed to TEST_VM Reviewed-by: vlivanov, kzhaldyb ! test/native/classfile/test_symbolTable.cpp ! test/native/logging/test_logConfiguration.cpp ! test/native/logging/test_logDecorations.cpp ! test/native/logging/test_logFileOutput.cpp ! test/native/oops/test_arrayOop.cpp ! test/native/utilities/test_json.cpp Changeset: 802c4b6f5119 Author: iignatyev Date: 2016-10-04 21:21 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/802c4b6f5119 8166129: hitting vmassert during gtest execution doesn't generate core and hs_err files Reviewed-by: kzhaldyb, kbarrett ! test/native/gtestMain.cpp Changeset: 5baf89bc0a4b Author: mdoerr Date: 2016-04-29 15:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5baf89bc0a4b 8155729: C2: Skip transformation of LoadConP for heap-based compressed oops Reviewed-by: kvn ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/ppc/vm/ppc.ad ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/matcher.hpp Changeset: 99ba38bd0e7c Author: erikj Date: 2016-10-05 11:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/99ba38bd0e7c 8164120: The minimal VM should be stripped using --strip-unneeded Reviewed-by: ihse, tbell, bobv ! make/lib/CompileJvm.gmk ! make/lib/JvmFeatures.gmk Changeset: d3032d8d3bc7 Author: mlarsson Date: 2016-09-08 15:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d3032d8d3bc7 8165696: Convert gcTraceTime internal tests to GTest Reviewed-by: rehn, rprotacio ! src/share/vm/logging/log.cpp ! src/share/vm/utilities/internalVMTests.cpp ! test/native/logging/logTestUtils.inline.hpp + test/native/logging/test_gcTraceTime.cpp Changeset: 37040fd2c7f5 Author: mlarsson Date: 2016-09-08 15:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/37040fd2c7f5 8165698: Convert LogTagSet related internal tests to GTest Reviewed-by: rehn, rprotacio ! src/share/vm/logging/log.cpp ! src/share/vm/utilities/internalVMTests.cpp ! test/native/logging/test_logTagLevelExpression.cpp ! test/native/logging/test_logTagSet.cpp + test/native/logging/test_logTagSetDescriptions.cpp Changeset: 1a8be2fab619 Author: mlarsson Date: 2016-09-08 15:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1a8be2fab619 8165700: Convert LogMessage internal tests to GTest Reviewed-by: rehn, rprotacio ! src/share/vm/logging/log.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/logging/test_logMessageTest.cpp Changeset: c3b0353786c1 Author: mlarsson Date: 2016-09-08 15:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c3b0353786c1 8165702: Convert LogFileOutput internal tests to GTest Reviewed-by: rehn, rprotacio ! src/share/vm/logging/log.cpp ! src/share/vm/utilities/internalVMTests.cpp ! test/native/logging/logTestUtils.inline.hpp ! test/native/logging/test_logFileOutput.cpp Changeset: 63fb7119a843 Author: mlarsson Date: 2016-09-08 15:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/63fb7119a843 8165704: Convert LogStream internal tests to GTest Reviewed-by: rehn, rprotacio ! src/share/vm/logging/log.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/logging/test_logStream.cpp Changeset: f6ef8a82b3cc Author: mlarsson Date: 2016-09-08 15:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f6ef8a82b3cc 8165600: Convert internal logging tests to GTest Reviewed-by: rehn, rprotacio - src/share/vm/logging/log.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/logging/test_log.cpp ! test/native/logging/test_logConfiguration.cpp Changeset: 97cd0eaed840 Author: mlarsson Date: 2016-10-05 12:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/97cd0eaed840 Merge Changeset: 062429f3c065 Author: jwilhelm Date: 2015-10-21 15:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/062429f3c065 8166276: Refactor gen_process_roots to allow simpler fix for 8165949 Reviewed-by: mgerdin, stefank Contributed-by: jesper.wilhelmsson at oracle.com, stefan.johansson at oracle.com ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/serial/defNewGeneration.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/genCollectedHeap.hpp Changeset: 1d70c7ca92cc Author: sjohanss Date: 2016-10-05 13:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d70c7ca92cc 8165949: Serial and ConcMarkSweep do not unload strings when class unloading is disabled Reviewed-by: mgerdin, tschatzl, stefank ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/genCollectedHeap.hpp Changeset: d574220871d3 Author: never Date: 2016-10-05 11:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d574220871d3 8166929: [JVMCI] Expose decompile counts in MDO Reviewed-by: twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodData.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.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/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/jvmci/vmStructs_jvmci.cpp Changeset: 4c7c4d8333ac Author: goetz Date: 2016-09-22 18:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c7c4d8333ac 8166562: C2: Suppress relocations in scratch emit. Reviewed-by: kvn ! src/cpu/ppc/vm/ppc.ad ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/opto/compile.cpp Changeset: 160d63f639af Author: kvn Date: 2016-10-05 21:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/160d63f639af Merge Changeset: fcadda510556 Author: dnsimon Date: 2016-10-05 13:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fcadda510556 8167194: [JVMCI] no reliable mechanism for querying JVMCI system properties Reviewed-by: kvn ! 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.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java ! src/share/vm/jvmci/jvmci_globals.cpp ! src/share/vm/jvmci/jvmci_globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/jvmci/TestJVMCIPrintProperties.java Changeset: 60a8cbf7030e Author: aph Date: 2016-10-06 09:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/60a8cbf7030e 8167200: AArch64: Broken stack pointer adjustment in interpreter Summary: Always adjust SP unconditionally Reviewed-by: dlong, kbarrett ! src/cpu/aarch64/vm/templateTable_aarch64.cpp Changeset: a53404b57257 Author: aph Date: 2016-10-06 09:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a53404b57257 Merge - src/share/vm/logging/log.cpp Changeset: bd5e566edbc4 Author: dnsimon Date: 2016-10-07 15:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bd5e566edbc4 8167353: [JVMCI] JVMCI re-initialization check is in the wrong location Reviewed-by: kvn, twisti ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/jvmci/jvmciRuntime.cpp ! src/share/vm/jvmci/systemDictionary_jvmci.hpp ! src/share/vm/jvmci/vmSymbols_jvmci.hpp Changeset: b1c62e595c4a Author: hseigel Date: 2016-10-10 08:34 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b1c62e595c4a 8166364: fatal error: acquiring lock DirtyCardQ_CBL_mon/16 out of order with lock Module_lock/6 -- possible deadlock Summary: Set the mirror's module field outside of the module lock. Reviewed-by: dsamersoff, dholmes, rehn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/modules.cpp Changeset: d3f508318705 Author: amurillo Date: 2016-10-13 08:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d3f508318705 Merge ! make/lib/CompileJvm.gmk - src/share/vm/logging/log.cpp - src/share/vm/utilities/resourceHash.cpp Changeset: 32b7bb18922d Author: mdoerr Date: 2016-09-27 09:26 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/32b7bb18922d 8166689: PPC64: Race condition between stack bang and non-entrant patching Reviewed-by: goetz ! src/cpu/ppc/vm/c1_MacroAssembler_ppc.cpp ! src/cpu/ppc/vm/templateTable_ppc_64.cpp Changeset: 9cc82b204d20 Author: adinn Date: 2016-09-27 09:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9cc82b204d20 8165673: AArch64: Fix JNI floating point argument handling Reviewed-by: aph, adinn Contributed-by: ningsheng.jian at linaro.org ! src/cpu/aarch64/vm/interpreterRT_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp - test/compiler/floatingpoint/Test15FloatJNIArgs.java + test/compiler/floatingpoint/TestFloatJNIArgs.java - test/compiler/floatingpoint/libTest15FloatJNIArgs.c + test/compiler/floatingpoint/libTestFloatJNIArgs.c Changeset: 174c38f7c4bc Author: dnsimon Date: 2016-09-27 04:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/174c38f7c4bc 8166517: [JVMCI] export JVMCI to auto-detected JVMCI compiler Reviewed-by: kvn, twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java Changeset: 6214eb051a30 Author: rasbold Date: 2016-09-28 10:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6214eb051a30 8166742: SIGFPE in C2 Loop IV elimination Reviewed-by: kvn ! src/share/vm/opto/loopnode.cpp + test/compiler/loopopts/TestImpossibleIV.java Changeset: a77e80a0a77f Author: never Date: 2016-09-29 10:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a77e80a0a77f 8166869: [JVMCI] record metadata relocations for metadata references Reviewed-by: kvn ! src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp ! src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.hpp Changeset: 4191b33b3629 Author: jcm Date: 2016-09-29 22:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4191b33b3629 8134389: Crash in HotSpot with jvm.dll+0x42b48 ciObjectFactory::create_new_metadata Summary: Always obtain return type from declared_signature for Invoke::declared_type. TypeCast return value to declared_signature return type for inlined lforms. Reviewed-by: kvn, vlivanov ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/ci/ciMethod.hpp + test/compiler/jsr292/TestArrayReturnType.java Changeset: ea0313bad050 Author: roland Date: 2016-09-28 11:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ea0313bad050 8166836: Elimination of clone's ArrayCopyNode may make compilation fail silently Reviewed-by: vlivanov ! src/share/vm/opto/macro.cpp + test/compiler/arraycopy/TestEliminatedCloneBadMemEdge.java Changeset: a46f84e4a4d2 Author: dlong Date: 2016-10-03 12:35 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a46f84e4a4d2 Merge - src/share/vm/utilities/chunkedList.cpp - test/runtime/SharedArchiveFile/SASymbolTableTestAttachee.java Changeset: 51214c891d11 Author: rschatz Date: 2016-10-03 17:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/51214c891d11 8166781: fix wrong comment in ReceiverTypeData Reviewed-by: kvn ! src/share/vm/oops/methodData.hpp Changeset: b2b2ec149a24 Author: rschatz Date: 2016-10-03 19:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b2b2ec149a24 Merge Changeset: b44d14948c83 Author: kvn Date: 2016-10-14 08:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b44d14948c83 Merge ! src/share/vm/c1/c1_GraphBuilder.cpp - test/compiler/floatingpoint/Test15FloatJNIArgs.java - test/compiler/floatingpoint/libTest15FloatJNIArgs.c Changeset: e5d554123372 Author: dholmes Date: 2016-10-17 18:40 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e5d554123372 8166197: assert(RelaxAssert || w != Thread::current()->_MutexEvent) failed: invariant Reviewed-by: dcubed, cvarming ! src/share/vm/runtime/mutex.cpp Changeset: 0fe2815ffa74 Author: stsmirno Date: 2016-10-17 18:54 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0fe2815ffa74 8165687: Fix license and copyright headers in jd9 under hotspot/test Summary: Legal notices and Oracle copyrights were updated (white and blank space, commas) in tests files for uniformity to meet Oracle requirements. Reviewed-by: dholmes, iris Contributed-by: Stanislav Smirnov , Vassili Igouchkine ! test/compiler/c1/NullCheckTest.java ! test/compiler/c1/Test6579789.java ! test/compiler/c1/Test6795465.java ! test/compiler/c1/Test6849574.java ! test/compiler/c1/Test6855215.java ! test/compiler/c1/Test6932496.java ! test/compiler/c1/Test7042153.java ! test/compiler/c1/Test7090976.java ! test/compiler/c1/Test7103261.java ! test/compiler/c1/Test7123108.java ! test/compiler/c1/Test8004051.java ! test/compiler/c1/TestArrayCopy.java ! test/compiler/c1/TestDeoptInt.java ! test/compiler/c1/TestUnalignedLoad.java ! test/compiler/c2/FloatingPointFoldingTest.java ! test/compiler/c2/IVTest.java ! test/compiler/c2/InterruptedTest.java ! test/compiler/c2/Test6186134.java ! test/compiler/c2/Test6196102.java ! test/compiler/c2/Test6357214.java ! test/compiler/c2/Test6443505.java ! test/compiler/c2/Test6559156.java ! test/compiler/c2/Test6661247.java ! test/compiler/c2/Test6732154.java ! test/compiler/c2/Test6753639.java ! test/compiler/c2/Test6792161.java ! test/compiler/c2/Test6796786.java ! test/compiler/c2/Test6799693.java ! test/compiler/c2/Test6823453.java ! test/compiler/c2/Test6832293.java ! test/compiler/c2/Test6850611.java ! test/compiler/c2/Test6851282.java ! test/compiler/c2/Test6852078.java ! test/compiler/c2/Test6857159.java ! test/compiler/c2/Test6885584.java ! test/compiler/c2/Test6897150.java ! test/compiler/c2/Test6905845.java ! test/compiler/c2/Test6910605_1.java ! test/compiler/c2/Test6910605_2.java ! test/compiler/c2/Test6916644.java ! test/compiler/c2/Test6930043.java ! test/compiler/c2/Test6931567.java ! test/compiler/c2/Test6935022.java ! test/compiler/c2/Test6956668.java ! test/compiler/c2/Test6959129.java ! test/compiler/c2/Test6968348.java ! test/compiler/c2/Test6985295.java ! test/compiler/c2/Test6992759.java ! test/compiler/c2/Test7002666.java ! test/compiler/c2/Test7009359.java ! test/compiler/c2/Test7020614.java ! test/compiler/c2/Test7024475.java ! test/compiler/c2/Test7041100.java ! test/compiler/c2/Test7046096.java ! test/compiler/c2/Test7047069.java ! test/compiler/c2/Test7048332.java ! test/compiler/c2/Test7068051.java ! test/compiler/c2/Test7110586.java ! test/compiler/c2/Test7125879.java ! test/compiler/c2/Test7160610.java ! test/compiler/c2/Test7169782.java ! test/compiler/c2/Test7174363.java ! test/compiler/c2/Test7177917.java ! test/compiler/c2/Test7190310.java ! test/compiler/c2/Test7190310_unsafe.java ! test/compiler/c2/Test7199742.java ! test/compiler/c2/Test8002069.java ! test/compiler/c2/TestDominatingDeadCheckCast.java ! test/compiler/c2/cr6340864/TestByteVect.java ! test/compiler/c2/cr6340864/TestDoubleVect.java ! test/compiler/c2/cr6340864/TestFloatVect.java ! test/compiler/c2/cr6340864/TestIntVect.java ! test/compiler/c2/cr6340864/TestLongVect.java ! test/compiler/c2/cr6340864/TestShortVect.java ! test/compiler/c2/cr6663854/Test6663854.java ! test/compiler/c2/cr6711117/Test.java ! test/compiler/c2/cr6890943/Test6890943.java ! test/compiler/c2/cr7005594/Test7005594.java ! test/compiler/c2/cr7192963/TestByteVect.java ! test/compiler/c2/cr7192963/TestDoubleVect.java ! test/compiler/c2/cr7192963/TestFloatVect.java ! test/compiler/c2/cr7192963/TestIntVect.java ! test/compiler/c2/cr7192963/TestLongVect.java ! test/compiler/c2/cr7192963/TestShortVect.java ! test/compiler/c2/cr7200264/TestIntVect.java ! test/compiler/c2/cr8004867/TestIntAtomicCAS.java ! test/compiler/c2/cr8004867/TestIntAtomicOrdered.java ! test/compiler/c2/cr8004867/TestIntAtomicVolatile.java ! test/compiler/c2/cr8004867/TestIntUnsafeCAS.java ! test/compiler/c2/cr8004867/TestIntUnsafeOrdered.java ! test/compiler/c2/cr8004867/TestIntUnsafeVolatile.java ! test/compiler/codecache/OverflowCodeCacheTest.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/Test6431242.java ! test/compiler/codegen/Test6909839.java ! test/compiler/codegen/Test6942326.java ! test/compiler/codegen/Test7009231.java ! test/compiler/codegen/Test7100757.java ! test/compiler/codegen/TestBooleanVect.java ! test/compiler/codegen/TestByteDoubleVect.java ! test/compiler/codegen/TestByteFloatVect.java ! test/compiler/codegen/TestByteIntVect.java ! test/compiler/codegen/TestByteLongVect.java ! test/compiler/codegen/TestByteShortVect.java ! test/compiler/codegen/TestByteVect.java ! test/compiler/codegen/TestCharShortVect.java ! test/compiler/codegen/TestCharVect.java ! test/compiler/codegen/TestCharVect2.java ! test/compiler/codegen/TestDoubleVect.java ! test/compiler/codegen/TestFloatDoubleVect.java ! test/compiler/codegen/TestFloatVect.java ! test/compiler/codegen/TestIntDoubleVect.java ! test/compiler/codegen/TestIntFloatVect.java ! test/compiler/codegen/TestIntLongVect.java ! test/compiler/codegen/TestIntVect.java ! test/compiler/codegen/TestLongDoubleVect.java ! test/compiler/codegen/TestLongFloatVect.java ! test/compiler/codegen/TestLongVect.java ! test/compiler/codegen/TestShortDoubleVect.java ! test/compiler/codegen/TestShortFloatVect.java ! test/compiler/codegen/TestShortIntVect.java ! test/compiler/codegen/TestShortLongVect.java ! test/compiler/codegen/TestShortVect.java ! test/compiler/codegen/aes/TestAESBase.java ! test/compiler/codegen/aes/TestAESDecode.java ! test/compiler/codegen/aes/TestAESEncode.java ! test/compiler/codegen/aes/TestAESMain.java ! test/compiler/controldependency/TestEliminatedCastPPAtPhi.java ! test/compiler/cpuflags/AESIntrinsicsBase.java ! test/compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java ! test/compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java ! test/compiler/cpuflags/TestSSE4Disabled.java ! test/compiler/cpuflags/predicate/AESSupportPredicate.java ! test/compiler/escapeAnalysis/Test6726999.java ! test/compiler/escapeAnalysis/Test6775880.java ! test/compiler/escapeAnalysis/Test6895383.java ! test/compiler/escapeAnalysis/Test6896727.java ! test/compiler/escapeAnalysis/cr6795161/Test.java ! test/compiler/gcbarriers/G1CrashTest.java ! test/compiler/gcbarriers/PreserveFPRegistersTest.java ! test/compiler/inlining/InlineAccessors.java ! test/compiler/interpreter/cr7116216/LargeFrame.java ! test/compiler/interpreter/cr7116216/StackOverflow.java ! test/compiler/intrinsics/Test6982370.java ! test/compiler/intrinsics/bigInteger/TestMulAdd.java ! test/compiler/intrinsics/bigInteger/TestMultiplyToLen.java ! test/compiler/intrinsics/bigInteger/TestMultiplyToLenReturnProfile.java ! test/compiler/intrinsics/bigInteger/TestSquareToLen.java ! test/compiler/intrinsics/bmi/BMITestRunner.java ! test/compiler/intrinsics/bmi/Expr.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/BmiIntrinsicBase.java ! test/compiler/intrinsics/klass/TestIsPrimitive.java ! test/compiler/intrinsics/object/TestClone.java ! test/compiler/intrinsics/sha/TestSHA.java ! test/compiler/intrinsics/unsafe/AllocateUninitializedArray.java ! test/compiler/intrinsics/unsafe/TestUnsafeMismatchedArrayFieldAccess.java ! test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java ! test/compiler/intrinsics/unsafe/UnsafeTwoCASLong.java ! test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java ! test/compiler/jsr292/LongReferenceCastingTest.java ! test/compiler/jsr292/MHInlineTest.java ! test/compiler/jsr292/Test7082949.java ! test/compiler/jsr292/cr6990212/Test6990212.java ! test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java ! test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java ! test/compiler/jsr292/methodHandleExceptions/p/C.java ! test/compiler/jsr292/methodHandleExceptions/p/Dok.java ! test/compiler/jsr292/methodHandleExceptions/p/E.java ! test/compiler/jsr292/methodHandleExceptions/p/F.java ! test/compiler/jsr292/methodHandleExceptions/p/I.java ! test/compiler/jsr292/methodHandleExceptions/p/Tdirect.java ! test/compiler/jsr292/methodHandleExceptions/p/Treflect.java ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/compiler/jvmci/common/testcases/TestCase.java ! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java ! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java ! test/compiler/jvmci/compilerToVM/ConstantPoolTestCase.java ! test/compiler/jvmci/compilerToVM/ConstantPoolTestsHelper.java ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java ! test/compiler/jvmci/compilerToVM/DummyAbstractClass.java ! test/compiler/jvmci/compilerToVM/DummyClass.java ! test/compiler/jvmci/compilerToVM/DummyInterface.java ! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java ! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java ! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java ! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.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/MethodIsIgnoredBySecurityStackWalkTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java ! test/compiler/jvmci/jdk.vm.ci.code.test/libNativeCallTest.c ! test/compiler/linkage/LinkageErrors.java ! test/compiler/loopopts/BadPredicateAfterPartialPeel.java ! test/compiler/loopopts/ConstFPVectorization.java ! test/compiler/loopopts/CountedLoopProblem.java ! test/compiler/loopopts/Test6659207.java ! test/compiler/loopopts/Test7044738.java ! test/compiler/loopopts/Test7052494.java ! test/compiler/loopopts/TestArraysFillDeadControl.java ! test/compiler/loopopts/TestCastIINoLoopLimitCheck.java ! test/compiler/loopopts/TestDeadBackbranchArrayAccess.java ! test/compiler/loopopts/TestMoveStoresOutOfLoops.java ! test/compiler/loopopts/TestPredicateLostDependency.java ! test/compiler/loopopts/TestSplitIfBlocksDisabled.java ! test/compiler/loopopts/TestSplitIfUnswitchedLoopsEliminated.java ! test/compiler/loopopts/UseCountedLoopSafepoints.java ! test/compiler/loopopts/superword/ProdRed_Double.java ! test/compiler/loopopts/superword/ProdRed_Float.java ! test/compiler/loopopts/superword/ProdRed_Int.java ! test/compiler/loopopts/superword/ReductionPerf.java ! test/compiler/loopopts/superword/SumRedAbsNeg_Double.java ! test/compiler/loopopts/superword/SumRedAbsNeg_Float.java ! test/compiler/loopopts/superword/SumRedSqrt_Double.java ! test/compiler/loopopts/superword/SumRed_Double.java ! test/compiler/loopopts/superword/SumRed_Float.java ! test/compiler/loopopts/superword/SumRed_Int.java ! test/compiler/loopopts/superword/SumRed_Long.java ! test/compiler/loopopts/superword/TestVectorizationWithInvariant.java ! test/compiler/memoryinitialization/ZeroTLABTest.java ! test/compiler/rangechecks/PowerOf2SizedArraysChecks.java ! test/compiler/rangechecks/TestRangeCheckEliminationDisabled.java ! test/compiler/rangechecks/TestRangeCheckExceptionHandlerLoopMain.java ! test/compiler/regalloc/TestVectorRegAlloc.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/StackOverflowBug.java ! test/compiler/runtime/Test6778657.java ! test/compiler/runtime/Test6826736.java ! test/compiler/runtime/Test6859338.java ! test/compiler/runtime/Test6892265.java ! test/compiler/runtime/Test7088020.java ! test/compiler/runtime/Test7196199.java ! test/compiler/runtime/cr6891750/Test6891750.java ! test/compiler/runtime/safepoints/TestRegisterRestoring.java ! test/compiler/stable/TestStableMismatched.java ! test/compiler/testlibrary/rtm/AbortProvoker.java ! test/compiler/testlibrary/rtm/AbortType.java ! test/compiler/testlibrary/rtm/BufferOverflowProvoker.java ! test/compiler/testlibrary/rtm/BusyLock.java ! test/compiler/testlibrary/rtm/CompilableTest.java ! test/compiler/testlibrary/rtm/MemoryConflictProvoker.java ! test/compiler/testlibrary/rtm/NestedAbortProvoker.java ! test/compiler/testlibrary/rtm/RTMLockingStatistics.java ! test/compiler/testlibrary/rtm/RTMTestBase.java ! test/compiler/testlibrary/rtm/XAbortProvoker.java ! test/compiler/testlibrary/rtm/predicate/SupportedCPU.java ! test/compiler/testlibrary/rtm/predicate/SupportedVM.java ! test/compiler/types/TestPhiElimination.java ! test/compiler/uncommontrap/UncommonTrapStackBang.java ! test/compiler/whitebox/AllocationCodeBlobTest.java ! test/compiler/whitebox/ForceNMethodSweepTest.java ! test/compiler/whitebox/GetCodeHeapEntriesTest.java ! test/compiler/whitebox/GetNMethodTest.java ! test/gc/TestCardTablePageCommits.java ! test/gc/TestHumongousReferenceObject.java ! test/gc/TestSystemGC.java ! test/gc/arguments/AllocationHelper.java ! test/gc/arguments/FlagsValue.java ! test/gc/arguments/GCTypes.java ! test/gc/arguments/HeapRegionUsageTool.java ! test/gc/arguments/TestCMSHeapSizeFlags.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/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/TestNewSizeThreadIncrease.java ! test/gc/arguments/TestObjectTenuringFlags.java ! test/gc/arguments/TestParallelGCThreads.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestSerialHeapSizeFlags.java ! test/gc/arguments/TestShrinkHeapInSteps.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/TestVerifyBeforeAndAfterGCFlags.java ! test/gc/cms/DisableResizePLAB.java ! test/gc/cms/TestCMSScavengeBeforeRemark.java ! test/gc/g1/humongousObjects/ClassLoaderGenerator.java ! test/gc/g1/humongousObjects/G1SampleClass.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/GC.java ! test/gc/g1/humongousObjects/objectGraphTest/GCTokens.java ! test/gc/g1/humongousObjects/objectGraphTest/ObjectGraph.java ! test/gc/g1/humongousObjects/objectGraphTest/ReferenceInfo.java ! test/gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java ! test/gc/g1/humongousObjects/objectGraphTest/TestcaseData.java ! test/gc/logging/TestUnifiedLoggingSwitchStress.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/TestGCOld.java ! test/gc/testlibrary/Helpers.java ! test/native/GTestWrapper.java ! test/native/gtestLauncher.cpp ! 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 ! test/native/runtime/test_arguments.cpp ! test/native/runtime/test_classLoader.cpp ! test/native/runtime/test_globals.cpp ! test/native/runtime/test_os.cpp ! test/native/unittest.hpp ! test/native/utilities/test_bitMap_setops.cpp ! test/native/utilities/test_quicksort.cpp ! test/runtime/7116786/Test7116786.java ! test/runtime/7167069/PrintAsFlag.java ! test/runtime/BootClassAppendProp/BootClassPathAppend.java ! test/runtime/BootClassAppendProp/SunBootClassPath.java ! test/runtime/CommandLine/ObsoleteFlagErrorMessage.java ! test/runtime/CommandLine/TraceExceptionsTest.java ! test/runtime/Final/TestPutMain.java ! test/runtime/InternalApi/ThreadCpuTimesDeadlock.java ! test/runtime/MirrorFrame/Asmator.java ! test/runtime/MirrorFrame/Test8003720.java ! test/runtime/MirrorFrame/Victim.java ! test/runtime/MirrorFrame/VictimClassLoader.java ! test/runtime/SelectionResolution/AbstractMethodErrorTest.java ! test/runtime/SelectionResolution/classes/selectionresolution/Builder.java ! test/runtime/SelectionResolution/classes/selectionresolution/ByteCodeClassLoader.java ! test/runtime/SelectionResolution/classes/selectionresolution/ClassBuilder.java ! test/runtime/SelectionResolution/classes/selectionresolution/ClassConstruct.java ! test/runtime/SelectionResolution/classes/selectionresolution/Clazz.java ! test/runtime/SelectionResolution/classes/selectionresolution/HierarchyShape.java ! test/runtime/SelectionResolution/classes/selectionresolution/Interface.java ! test/runtime/SelectionResolution/classes/selectionresolution/Method.java ! test/runtime/SelectionResolution/classes/selectionresolution/MethodData.java ! test/runtime/SelectionResolution/classes/selectionresolution/TestBuilder.java ! test/runtime/SharedArchiveFile/DumpSymbolAndStringTable.java ! test/runtime/StackGuardPages/exeinvoke.c ! test/runtime/Throwable/StackTraceLogging.java ! test/runtime/Throwable/ThrowableIntrospectionSegfault.java ! test/runtime/classFileParserBug/AnnotationTag.java ! test/runtime/classFileParserBug/BadInitMethod.java ! test/runtime/classFileParserBug/BadNameAndType.java ! test/runtime/classFileParserBug/EnclosingMethod.java ! test/runtime/classFileParserBug/InitInInterface.java ! test/runtime/classFileParserBug/TestBadClassName.java ! test/runtime/lambda-features/InvokespecialInterface.java ! test/runtime/lambda-features/PublicStaticInterfaceMethodHandling.java ! test/runtime/lambda-features/TestConcreteClassWithAbstractMethod.java ! test/runtime/lambda-features/TestInterfaceInit.java ! test/runtime/lambda-features/TestInterfaceOrder.java ! test/runtime/lambda-features/TestStaticandInstance.java ! test/runtime/logging/BiasedLockingTest.java ! test/runtime/logging/CompressedOopsTest.java ! test/runtime/logging/DefaultMethodsTest.java ! test/runtime/logging/ExceptionsTest.java ! test/runtime/logging/ItablesTest.java ! test/runtime/logging/ModulesTest.java ! test/runtime/logging/MonitorInflationTest.java ! test/runtime/logging/OsCpuLoggingTest.java ! test/runtime/logging/SafepointCleanupTest.java ! test/runtime/logging/SafepointTest.java ! test/runtime/logging/StartupTimeTest.java ! test/runtime/logging/VMOperationTest.java ! test/runtime/logging/VerificationTest.java ! test/runtime/logging/VtablesTest.java ! test/runtime/logging/p1/A.java ! test/runtime/logging/p1/C.java ! test/runtime/logging/p2/D.java ! test/runtime/stackMapCheck/StackMapCheck.java ! test/runtime/verifier/PrimIntArray.java ! test/runtime/verifier/TraceClassRes.java ! test/sanity/ExecuteInternalVMTests.java ! test/serviceability/dcmd/vm/DynLibsTest.java ! test/serviceability/jvmti/TestLambdaFormRetransformation.java ! test/serviceability/tmtools/share/common/TmTool.java Changeset: dfff5edc66df Author: mwalsh Date: 2016-10-17 19:12 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dfff5edc66df 8165482: java in ldoms, with cpu-arch=generic has problems Reviewed-by: dholmes, alanbur ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: 43c36489d6fe Author: alanbur Date: 2016-10-17 19:18 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43c36489d6fe 8157141: Fix for JDK-8031290 is unnecessarily fragile 8166454: meminfo(2) has been available since Solaris 9 Reviewed-by: dholmes, kbarrett ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotJVMCIBackendFactory.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotVMConfig.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARC.java ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/jvmci/vmStructs_jvmci.cpp Changeset: e86cc2a83428 Author: jmasa Date: 2016-10-17 16:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e86cc2a83428 8155948: Add message for CMS deprecation for Oracle builds Reviewed-by: kbarrett, dholmes, coleenp, drwhite ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp + src/share/vm/runtime/arguments_ext.cpp ! test/gc/startup_warnings/TestCMS.java Changeset: 135ce0e36619 Author: sangheki Date: 2016-10-18 01:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/135ce0e36619 Merge ! test/gc/startup_warnings/TestCMS.java Changeset: 036f46dcf262 Author: mdoerr Date: 2016-10-12 10:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/036f46dcf262 8166970: Adapt mutex padding according to DEFAULT_CACHE_LINE_SIZE Reviewed-by: coleenp, dholmes, dcubed, redestad ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/mutexLocker.cpp Changeset: 10724994b8bf Author: coleenp Date: 2016-10-18 00:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/10724994b8bf Merge - test/compiler/floatingpoint/Test15FloatJNIArgs.java - test/compiler/floatingpoint/libTest15FloatJNIArgs.c Changeset: 728e5166a597 Author: coleenp Date: 2016-10-18 02:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/728e5166a597 Merge Changeset: a44e1708bb9f Author: sangheki Date: 2016-10-17 21:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a44e1708bb9f 8166461: Deprecate UseAutoGCSelectPolicy Reviewed-by: kbarrett, ehelin ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestUseAutoGCSelectPolicy.java Changeset: f5fd57f23732 Author: sangheki Date: 2016-10-17 16:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5fd57f23732 8167494: Deprecate AutoGCSelectPauseMillis Reviewed-by: kbarrett, ehelin ! src/share/vm/runtime/arguments.cpp ! test/gc/startup_warnings/TestUseAutoGCSelectPolicy.java Changeset: f482f393222d Author: thartmann Date: 2016-10-18 09:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f482f393222d 8153134: Infinite loop in handle_wrong_method in jmod Summary: Use Patching_lock to synchronize access between set_code() and clear_code(). Reviewed-by: kvn, dlong ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: d1031aa909fd Author: roland Date: 2016-10-17 17:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d1031aa909fd 8168086: 8166869 broke jvmci build on aarch64 Reviewed-by: kvn ! src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp Changeset: be080d1a870c Author: rehn Date: 2016-10-18 10:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/be080d1a870c 8165526: Kitchensink sudden death - error code 0x406d1388 Reviewed-by: dholmes, sla, gtriantafill ! src/os/windows/vm/os_windows.cpp Changeset: e721efdc2ae3 Author: rehn Date: 2016-10-18 12:06 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e721efdc2ae3 Merge Changeset: 652537a80080 Author: rehn Date: 2016-10-18 13:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/652537a80080 Merge Changeset: 313dda585dbc Author: ctornqvi Date: 2016-10-18 06:14 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/313dda585dbc 8166738: Enable concurrency in Hotspot jtreg testing Reviewed-by: gtriantafill, erikj, sspitsyn ! test/Makefile Changeset: d8b867be6027 Author: ctornqvi Date: 2016-10-18 06:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d8b867be6027 8159799: Tests using jcmd fails intermittently with Could not open PerfMemory on Windows Reviewed-by: gtriantafill, dholmes, sla, fparain ! src/os/windows/vm/perfMemory_windows.cpp Changeset: b2fa2456dc3c Author: ctornqvi Date: 2016-10-18 12:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b2fa2456dc3c Merge Changeset: fd254be27168 Author: ehelin Date: 2016-10-05 16:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fd254be27168 8167190: Remove confusing timestamps from the gc log Reviewed-by: sjohanss, pliden ! src/share/vm/gc/shared/gcTraceTime.inline.hpp ! test/gc/logging/TestPrintReferences.java ! test/native/logging/test_gcTraceTime.cpp ! test/serviceability/logging/TestLogRotation.java Changeset: 830643d17e58 Author: ehelin Date: 2016-10-18 16:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/830643d17e58 Merge Changeset: ca57b5424e21 Author: dnsimon Date: 2016-10-11 00:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ca57b5424e21 8167180: [JVMCI] Exported elements referring to inaccessible types in jdk.vm.ci Reviewed-by: mchung, twisti, alanb + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/EmptyEventProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/EventProvider.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerFactory.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/HotSpotVMEventListener.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EmptyEventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCICompilerFactory.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java ! src/jdk.vm.ci/share/classes/module-info.java ! test/compiler/jvmci/common/JVMCIHelpers.java - test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.services.HotSpotVMEventListener - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.JVMCICompiler - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.services.JVMCICompilerFactory ! test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.config ! test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.config ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/compiler/jvmci/events/JvmciShutdownEventListener.java ! test/compiler/jvmci/events/JvmciShutdownEventTest.config ! test/compiler/jvmci/events/JvmciShutdownEventTest.java Changeset: 80c7ad7c11e7 Author: dnsimon Date: 2016-10-18 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/80c7ad7c11e7 Merge - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EmptyEventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java - test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.services.HotSpotVMEventListener - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.JVMCICompiler - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.services.JVMCICompilerFactory Changeset: 340dc4fa4fff Author: coleenp Date: 2016-10-18 08:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/340dc4fa4fff 8164921: Memory leaked when instrumentation.retransformClasses() is called repeatedly Summary: Return Metablocks smaller than dictionary's dark matter. Reviewed-by: mgerdin, sspitsyn, dsamersoff Contributed-by: jon.masamitsu at oracle.com, coleen.phillimore at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! test/TEST.groups + test/runtime/RedefineTests/RedefineLeak.java Changeset: ea5510ece7b9 Author: coleenp Date: 2016-10-18 16:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ea5510ece7b9 Merge Changeset: 08b6c4e9431a Author: aph Date: 2016-10-12 12:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/08b6c4e9431a 8167595: AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt Reviewed-by: aph Contributed-by: ningsheng.jian at linaro.org ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: 7a5a9fa501b5 Author: aph Date: 2016-10-18 17:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7a5a9fa501b5 Merge - make/Dist.gmk - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EmptyEventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java - test/compiler/floatingpoint/Test15FloatJNIArgs.java - test/compiler/floatingpoint/libTest15FloatJNIArgs.c - test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.services.HotSpotVMEventListener - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.JVMCICompiler - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.services.JVMCICompilerFactory Changeset: 80e226479802 Author: aph Date: 2016-10-18 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/80e226479802 Merge Changeset: 5d97f06d13ff Author: dfazunen Date: 2016-10-18 19:26 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d97f06d13ff 8165621: Convert TestG1BiasedArray_test to GTest Reviewed-by: jwilhelm, kzhaldyb ! src/share/vm/gc/g1/g1BiasedArray.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/g1/test_g1BiasedArray.cpp Changeset: 4a0e938f0df5 Author: dfazunen Date: 2016-10-18 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4a0e938f0df5 Merge Changeset: 62c7f801493e Author: dfazunen Date: 2016-10-18 17:18 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/62c7f801493e Merge Changeset: 02048d90e669 Author: dfazunen Date: 2016-10-18 18:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/02048d90e669 Merge Changeset: eba50697795d Author: never Date: 2016-10-18 17:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eba50697795d 8166972: [JVMCI] reduce size of interpreter when JVMCI is enabled Reviewed-by: kvn, twisti ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp ! src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp Changeset: 6d628fd1d44b Author: never Date: 2016-10-18 17:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6d628fd1d44b Merge Changeset: b28ce306a902 Author: never Date: 2016-10-18 19:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b28ce306a902 Merge Changeset: 50a90b65620b Author: jiangli Date: 2016-10-10 20:50 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/50a90b65620b 8167333: Invalid source path info might be used when creating ClassFileStream after CFLH transforms a shared classes in some cases Summary: Use NULL as 'source' when there is no valid source path info. Reviewed-by: iklam, dholmes, dsamersoff ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/filemap.hpp Changeset: f24e29eb860e Author: jiangli Date: 2016-10-18 17:38 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f24e29eb860e Merge Changeset: 5fe734a2323b Author: ccheung Date: 2016-10-18 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fe734a2323b 8166931: Do not include classes which are unusable during run time in the classlist file Summary: added check to exclude classes found in the --patch-module list Reviewed-by: jiangli, lfoltan, iklam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp + test/runtime/modules/PatchModule/PatchModuleClassList.java Changeset: aeafaf272877 Author: dholmes Date: 2016-10-18 20:03 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aeafaf272877 8165827: Support private interface methods in JNI, JDWP, JDI and JDB Reviewed-by: dcubed, lfoltan, sspitsyn ! test/runtime/jni/PrivateInterfaceMethods/PrivateInterfaceMethods.java ! test/runtime/jni/PrivateInterfaceMethods/libPrivateInterfaceMethods.c Changeset: ad2a67815b99 Author: dholmes Date: 2016-10-19 00:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ad2a67815b99 Merge Changeset: 6772dde13bed Author: amurillo Date: 2016-10-20 16:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6772dde13bed Merge - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EmptyEventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java ! src/share/vm/classfile/classFileParser.cpp - src/share/vm/logging/log.cpp ! src/share/vm/runtime/arguments.cpp - src/share/vm/utilities/resourceHash.cpp - test/compiler/floatingpoint/Test15FloatJNIArgs.java - test/compiler/floatingpoint/libTest15FloatJNIArgs.c - test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.services.HotSpotVMEventListener - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.JVMCICompiler - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.services.JVMCICompilerFactory Changeset: c30b6e2d2ec4 Author: lana Date: 2016-10-27 21:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c30b6e2d2ec4 Merge - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EmptyEventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/EventProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java - src/share/vm/logging/log.cpp - src/share/vm/utilities/resourceHash.cpp - test/compiler/floatingpoint/Test15FloatJNIArgs.java - test/compiler/floatingpoint/libTest15FloatJNIArgs.c - test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.services.HotSpotVMEventListener - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.JVMCICompiler - test/compiler/jvmci/common/services/jdk.vm.ci.runtime.services.JVMCICompilerFactory Changeset: d87d5d430c42 Author: erikj Date: 2016-11-02 10:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d87d5d430c42 8063154: Checked in jvmti.h not in sync with generated jvmti.h Reviewed-by: tbell ! make/gensrc/GensrcJvmti.gmk Changeset: 6ee1eeed0d77 Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ee1eeed0d77 Added tag jdk-9+143 for changeset d87d5d430c42 ! .hgtags Changeset: 3261a6ce7cf1 Author: mchung Date: 2016-11-05 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3261a6ce7cf1 Merge ! .hgtags ! make/test/JtregNative.gmk ! src/jdk.vm.ci/share/classes/module-info.java ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/thread.cpp ! test/compiler/c1/Test6932496.java ! test/compiler/c2/Test6852078.java ! test/compiler/c2/Test6968348.java ! test/compiler/c2/Test7190310_unsafe.java ! test/compiler/c2/cr8004867/TestIntUnsafeCAS.java ! test/compiler/c2/cr8004867/TestIntUnsafeOrdered.java ! test/compiler/c2/cr8004867/TestIntUnsafeVolatile.java ! test/compiler/intrinsics/unsafe/AllocateUninitializedArray.java ! test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java ! test/compiler/intrinsics/unsafe/UnsafeTwoCASLong.java ! test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java ! test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.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/DoNotInlineOrCompileTest.java ! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java ! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java ! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java ! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/compiler/jvmci/events/JvmciShutdownEventTest.java ! test/gc/arguments/TestG1HeapRegionSize.java ! test/gc/arguments/TestTargetSurvivorRatioFlag.java ! test/gc/arguments/TestUseCompressedOopsErgo.java ! test/runtime/InternalApi/ThreadCpuTimesDeadlock.java ! test/runtime/MirrorFrame/Test8003720.java ! test/runtime/SharedArchiveFile/DumpSymbolAndStringTable.java ! test/runtime/Throwable/StackTraceLogging.java ! test/runtime/Throwable/ThrowableIntrospectionSegfault.java ! test/runtime/lambda-features/TestConcreteClassWithAbstractMethod.java ! test/runtime/lambda-features/TestStaticandInstance.java ! test/runtime/logging/ModulesTest.java - test/runtime/modules/JVMCanReadModule.java - test/runtime/modules/JVMIsExportedToModule.java From mandy.chung at oracle.com Sat Nov 5 19:04:38 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 05 Nov 2016 19:04:38 +0000 Subject: hg: jigsaw/jake/jaxp: 4 new changesets Message-ID: <201611051904.uA5J4cXg021964@aojmv0008.oracle.com> Changeset: eb3b5f3ecb9a Author: joehw Date: 2016-10-31 09:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/eb3b5f3ecb9a 8069098: StAX produces the wrong event stream Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/java.xml/share/classes/javax/xml/stream/XMLEventReader.java ! src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/BugTest.java Changeset: ce81d03ad732 Author: fyuan Date: 2016-11-02 14:16 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ce81d03ad732 8168968: Two jaxp tests failing after JDK-8167646 Reviewed-by: joehw, weijun ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest.java + test/javax/xml/jaxp/unittest/catalog/CatalogInvalidPathTest.java ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java Changeset: 99be33734ff6 Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/99be33734ff6 Added tag jdk-9+143 for changeset ce81d03ad732 ! .hgtags Changeset: 0920e7c9ead4 Author: mchung Date: 2016-11-05 12:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0920e7c9ead4 Merge From mandy.chung at oracle.com Sat Nov 5 19:04:42 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 05 Nov 2016 19:04:42 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201611051904.uA5J4gUx022023@aojmv0008.oracle.com> Changeset: 92523c51d6a4 Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/92523c51d6a4 Added tag jdk-9+143 for changeset 1c988e708a06 ! .hgtags Changeset: 76cf5c86865b Author: mchung Date: 2016-11-05 12:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/76cf5c86865b Merge From mandy.chung at oracle.com Sat Nov 5 19:05:02 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 05 Nov 2016 19:05:02 +0000 Subject: hg: jigsaw/jake/jdk: 90 new changesets Message-ID: <201611051905.uA5J55a1022131@aojmv0008.oracle.com> Changeset: e5ee2bd22f3f Author: mli Date: 2016-10-24 21:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5ee2bd22f3f 8168505: Remove the intermittent keyword from java/util/Arrays/ParallelPrefix.java Reviewed-by: darcy, amlu ! test/java/util/Arrays/ParallelPrefix.java Changeset: da2d2bfe98ff Author: okutsu Date: 2016-10-25 15:43 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/da2d2bfe98ff 8165804: Revisit the way of loading BreakIterator rules/dictionaries Reviewed-by: naoto, peytoia, erikj ! make/gendata/GendataBreakIterator.gmk + src/java.base/share/classes/sun/text/BreakDictionary.java + src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java + src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java + src/java.base/share/classes/sun/text/resources/BreakIteratorResources.java - src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java ! src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java - src/java.base/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java - src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java + src/java.base/share/classes/sun/util/resources/BreakIteratorResourceBundle.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java + src/jdk.localedata/share/classes/sun/text/resources/ext/BreakIteratorResources_th.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.sh ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: a80fd00b0cd0 Author: chegar Date: 2016-10-25 10:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a80fd00b0cd0 8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" Reviewed-by: rriggs, mli ! src/java.rmi/share/classes/sun/rmi/server/Activation.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkActivateRef/rmid.security.policy ! test/java/rmi/activation/Activatable/checkActivateRef/security.policy ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkAnnotations/rmid.security.policy ! test/java/rmi/activation/Activatable/checkAnnotations/security.policy ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/rmid.security.policy ! test/java/rmi/activation/Activatable/checkImplClassLoader/security.policy ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/rmid.security.policy ! test/java/rmi/activation/Activatable/checkRegisterInLog/security.policy ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/createPrivateActivable/rmid.security.policy ! test/java/rmi/activation/Activatable/createPrivateActivable/security.policy ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/downloadParameterClass/manual.security.policy ! test/java/rmi/activation/Activatable/downloadParameterClass/rmid.security.policy ! test/java/rmi/activation/Activatable/downloadParameterClass/security.policy ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/rmid.security.policy ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/security.policy ! test/java/rmi/activation/Activatable/extLoadedImpl/ExtLoadedImplTest.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/forceLogSnapshot/rmid.security.policy ! test/java/rmi/activation/Activatable/forceLogSnapshot/security.policy ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/inactiveGroup/rmid.security.policy ! test/java/rmi/activation/Activatable/inactiveGroup/security.policy ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java + test/java/rmi/activation/Activatable/lookupActivationSystem/rmid.security.policy ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nestedActivate/rmid.security.policy ! test/java/rmi/activation/Activatable/nestedActivate/security.policy ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/rmid.security.policy ! test/java/rmi/activation/Activatable/nonExistentActivatable/security.policy ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartCrashedService/rmid.security.policy ! test/java/rmi/activation/Activatable/restartCrashedService/security.policy ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartLatecomer/rmid.security.policy ! test/java/rmi/activation/Activatable/restartLatecomer/security.policy ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/restartService/rmid.security.policy ! test/java/rmi/activation/Activatable/restartService/security.policy ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/Activatable/shutdownGracefully/rmid.security.policy ! test/java/rmi/activation/Activatable/shutdownGracefully/security.policy ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/Activatable/unregisterInactive/rmid.security.policy ! test/java/rmi/activation/Activatable/unregisterInactive/security.policy ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivateFailedException/activateFails/rmid.security.policy ! test/java/rmi/activation/ActivateFailedException/activateFails/security.policy ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java + test/java/rmi/testlibrary/RMIDSelectorProvider.java ! test/java/rmi/testlibrary/TestParams.java Changeset: 11e15af1947f Author: ksrini Date: 2016-10-25 07:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/11e15af1947f 8160213: tools/pack200/Utils.java should clean up javac*.tmp files Reviewed-by: darcy ! test/tools/pack200/MultiRelease.java ! test/tools/pack200/Utils.java Changeset: 95a8c745128a Author: bchristi Date: 2016-10-25 12:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/95a8c745128a 8165793: Provide an API to query if a ClassLoader is parallel capable Reviewed-by: alanb, mchung ! src/java.base/share/classes/java/lang/ClassLoader.java + test/java/lang/ClassLoader/IsParallelCapable.java Changeset: e340b25a9e59 Author: sdrach Date: 2016-10-25 13:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e340b25a9e59 8164805: Fail to create a MR modular JAR with a versioned entry of a concealed package Reviewed-by: chegar, mchung ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties + test/tools/jar/mmrjar/ConcealedPackage.java + test/tools/jar/mmrjar/src/classes/p/Hi.java + test/tools/jar/mmrjar/src/mr9/module-info.java + test/tools/jar/mmrjar/src/mr9/p/Hi.java + test/tools/jar/mmrjar/src/mr9/p/internal/Bar.java Changeset: 9d4a52d62493 Author: dsamersoff Date: 2016-10-03 15:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9d4a52d62493 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent Summary: Remove exports com.sun.tools.jdi to jdk.hotspot.agent Reviewed-by: alanb, dsamersoff Contributed-by: sharath.ballal at oracle.com ! src/jdk.jdi/share/classes/module-info.java Changeset: 3d3f338b5aea Author: simonis Date: 2016-09-28 11:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3d3f338b5aea 8166801: [s390] Add jvm.cfg file for Linux/s390x Reviewed-by: erikj, shade + src/java.base/unix/conf/s390x/jvm.cfg Changeset: 86e5d318fad9 Author: amurillo Date: 2016-10-13 08:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/86e5d318fad9 Merge Changeset: 028d56ebb42a Author: amurillo Date: 2016-10-13 09:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/028d56ebb42a Merge - make/Import.gmk - src/java.desktop/share/classes/sun/java2d/pipe/hw/AccelDeviceEventListener.java - src/java.desktop/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java - test/java/awt/image/multiresolution/MultiResolutionTrayIconTest/MultiResolutionTrayIconTest.html - test/java/beans/XMLEncoder/EnumPrivate.java - test/java/beans/XMLEncoder/EnumPublic.java - test/java/beans/XMLEncoder/java_util_Collections_CheckedCollection.java - test/java/beans/XMLEncoder/java_util_Collections_CheckedList.java - test/java/beans/XMLEncoder/java_util_Collections_CheckedMap.java - test/java/beans/XMLEncoder/java_util_Collections_CheckedRandomAccessList.java - test/java/beans/XMLEncoder/java_util_Collections_CheckedSet.java - test/java/beans/XMLEncoder/java_util_Collections_CheckedSortedMap.java - test/java/beans/XMLEncoder/java_util_Collections_CheckedSortedSet.java - test/java/beans/XMLEncoder/java_util_EnumMap.java - test/java/beans/XMLEncoder/java_util_JumboEnumSet.java - test/java/beans/XMLEncoder/java_util_RegularEnumSet.java Changeset: 234fa7498814 Author: akulyakh Date: 2016-10-17 15:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/234fa7498814 8158797: Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails when GC is specified explicitly Summary: Fixed GC options for running the test Reviewed-by: ddmitriev, sspitsyn ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java Changeset: 569e17c52c7d Author: cjplummer Date: 2016-10-18 12:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/569e17c52c7d 8167001: [TESTBUG] java/lang/instrument/DaemonThread/TestDaemonThread.java fails when run by jprt Summary: force classpath to be added to subprocesses Reviewed-by: dholmes, sspitsyn ! test/java/lang/instrument/DaemonThread/TestDaemonThreadLauncher.java Changeset: 87579fa99c58 Author: cjplummer Date: 2016-10-18 12:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/87579fa99c58 8167034: Re-enable TestDaemonThread.java once JDK-8167001 is fixed Reviewed-by: jwilhelm, sspitsyn ! test/ProblemList.txt Changeset: ce7f9a34492e Author: dholmes Date: 2016-10-18 20:04 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ce7f9a34492e 8165827: Support private interface methods in JNI, JDWP, JDI and JDB Reviewed-by: dcubed, lfoltan, sspitsyn ! src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! test/com/sun/jdi/InterfaceMethodsTest.java Changeset: 0ecf4eb13c2d Author: amurillo Date: 2016-10-20 16:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ecf4eb13c2d Merge Changeset: 490854ad860c Author: amurillo Date: 2016-10-25 12:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/490854ad860c Merge - src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java - src/java.base/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java - src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java - test/sun/reflect/ReflectionFactory/NewConstructorForSerialization.java Changeset: 6ba0cc0314d0 Author: amurillo Date: 2016-10-25 14:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6ba0cc0314d0 Merge Changeset: 8c5900a31c2e Author: sundar Date: 2016-10-26 10:42 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c5900a31c2e 8166810: jlink should fail on extra arguments Reviewed-by: jlaskey ! 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/jlink/resources/jlink.properties ! test/tools/jlink/JLinkTest.java ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: dce8fdd7af97 Author: chegar Date: 2016-10-26 11:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dce8fdd7af97 8168773: Temporarily remove java/net/httpclient from jdk_net test group Reviewed-by: darcy, rriggs ! test/TEST.groups Changeset: ecd3f7dda51c Author: rriggs Date: 2016-10-26 09:38 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ecd3f7dda51c 8168613: CORBA ObjectStreamTest fails with address in use Reviewed-by: psandoz ! test/com/sun/corba/serialization/ObjectStreamTest.java Changeset: 8bb97435f7de Author: redestad Date: 2016-10-26 17:50 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bb97435f7de 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup Reviewed-by: alanb, plevart ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/io/FileOutputStream.java Changeset: c3724a682206 Author: mli Date: 2016-10-26 19:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c3724a682206 8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" Summary: It takes advantage of SSLTest.java to fix intermittent SSLHandshakeException failure Reviewed-by: xuelei, asmotrak Contributed-by: John Jiang ! test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java Changeset: 9f0ab4b20ff7 Author: clanger Date: 2016-10-27 11:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9f0ab4b20ff7 8167481: cleanup of headers and includes for native libnet Reviewed-by: chegar ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/native/libnet/net_util.c ! src/java.base/share/native/libnet/net_util.h ! src/java.base/unix/native/libnet/Inet4AddressImpl.c ! src/java.base/unix/native/libnet/Inet6AddressImpl.c ! src/java.base/unix/native/libnet/NetworkInterface.c ! src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c ! src/java.base/unix/native/libnet/PlainSocketImpl.c ! src/java.base/unix/native/libnet/SocketInputStream.c ! src/java.base/unix/native/libnet/SocketOutputStream.c ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/unix/native/libnet/net_util_md.h ! src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c ! src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c ! src/java.base/windows/native/libnet/Inet4AddressImpl.c ! src/java.base/windows/native/libnet/Inet6AddressImpl.c ! src/java.base/windows/native/libnet/NetworkInterface.c ! src/java.base/windows/native/libnet/NetworkInterface.h ! src/java.base/windows/native/libnet/NetworkInterface_winXP.c ! src/java.base/windows/native/libnet/SocketInputStream.c ! src/java.base/windows/native/libnet/SocketOutputStream.c ! src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c ! src/java.base/windows/native/libnet/TwoStacksPlainSocketImpl.c - src/java.base/windows/native/libnet/icmp.h ! src/java.base/windows/native/libnet/net_util_md.c ! src/java.base/windows/native/libnet/net_util_md.h Changeset: 384632278ce2 Author: serb Date: 2016-10-04 12:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/384632278ce2 8167028: SunCodec.java can be removed Reviewed-by: prr, amenkov ! src/java.desktop/share/classes/com/sun/media/sound/AlawCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java ! src/java.desktop/share/classes/com/sun/media/sound/PCMtoPCMCodec.java - src/java.desktop/share/classes/com/sun/media/sound/SunCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/UlawCodec.java ! src/java.desktop/share/classes/javax/sound/sampled/spi/FormatConversionProvider.java Changeset: ff61a6fd0349 Author: alexsch Date: 2016-10-05 18:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff61a6fd0349 8166591: [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only) Reviewed-by: malenkov, serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/NSEvent.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m + test/javax/swing/plaf/basic/BasicScrollPaneUI/8166591/TooMuchWheelRotationEventsTest.java Changeset: a731def8631f Author: alexsch Date: 2016-10-05 18:42 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a731def8631f 8165485: Bad rendering of Swing UI controls with Motif L&F on HiDPI display 8147600: [hidpi] invalid rendering of Swing UI controls (radiobuttons, choice etc.) Reviewed-by: serb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifComboBoxUI.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifIconFactory.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifScrollBarButton.java + test/javax/swing/plaf/motif/8165485/MotifHiDPIIconsTest.java Changeset: 7cb7ca59fe7f Author: alexsch Date: 2016-10-05 18:52 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7cb7ca59fe7f 7067885: FileChooser does not display soft link name if link is to nonexistent file/directory Reviewed-by: alexsch Contributed-by: Alok Kumar Sharma ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java Changeset: 38bf8bb1f5e7 Author: rchamyal Date: 2016-10-06 14:31 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/38bf8bb1f5e7 8151787: Unify the HiDPI splash screen image naming convention Reviewed-by: prr, alexsch, ksrini Contributed-by: rajeev.chamyal at oracle.com ! make/mapfiles/libsplashscreen/mapfile-vers ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m ! src/java.desktop/share/classes/java/awt/SplashScreen.java ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.c ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c ! src/java.desktop/windows/native/libsplashscreen/splashscreen_sys.c ! test/java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java ! test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java Changeset: fff8db067374 Author: aghaisas Date: 2016-10-06 20:37 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fff8db067374 8058950: [TESTBUG] There is no F1 dialog when the case loading,so we can't restore it. Reviewed-by: serb, arapte - test/java/awt/Modal/InvisibleParentTest/InvisibleParentTest.html ! test/java/awt/Modal/InvisibleParentTest/InvisibleParentTest.java Changeset: 89a3d9f69497 Author: mhalder Date: 2016-10-06 20:51 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89a3d9f69497 8165555: [macosx] VM crashes on second attempt to execute JCK interactive tests that use Robot (single JVM, agent) Reviewed-by: serb, aniyogi ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobotKeyCode.m + test/java/awt/event/KeyEvent/RobotCrash/RobotCrash.java Changeset: fbc5498378d6 Author: alanbur Date: 2016-10-06 11:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fbc5498378d6 8165232: XKeycodeToKeysym is deprecated and should be replaced Reviewed-by: prr, azvegint ! src/java.desktop/unix/native/libawt_xawt/xawt/XWindow.c ! src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c Changeset: e5be7a186fcc Author: ptbrunet Date: 2016-10-06 20:31 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5be7a186fcc 8160893: [macosx] JMenuItems in JPopupMenu are not accessible Summary: post events for MenuOpened/Closed/ItemSelected Reviewed-by: ant, alexsch ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m Changeset: 103be1c3c4f7 Author: prr Date: 2016-10-10 14:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/103be1c3c4f7 Merge - make/Import.gmk Changeset: 2d3ca05c6ea7 Author: prr Date: 2016-10-11 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2d3ca05c6ea7 8167523: JDK 9 build failure on MacOS due to unhandled cases in switch statement Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m Changeset: 27794f0eee1a Author: psadhukhan Date: 2016-10-12 23:04 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/27794f0eee1a 8167291: [TEST_BUG] javax/print/attribute/Services_getDocFl.java Reviewed-by: prr ! test/javax/print/attribute/Services_getDocFl.java Changeset: 557da3953b0b Author: jdv Date: 2016-10-13 11:37 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/557da3953b0b 6294607: GIFWriter returns the same compression type twice Reviewed-by: prr, serb, bpb ! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java + test/javax/imageio/ImageCompressionTypesTest.java Changeset: f7cee1fa870e Author: aghaisas Date: 2016-10-14 10:18 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f7cee1fa870e 8166980: JCK testing of Window.setIconImage() leads to VM crash starting approx from JDK9 b134 Reviewed-by: serb, rchamyal Contributed-by: ajit.ghaisas at oracle.com ! src/java.desktop/share/classes/sun/awt/IconInfo.java + test/java/awt/Frame/SetIconImagesCrashTest/SetIconImagesCrashTest.java Changeset: acbb657405c6 Author: mhalder Date: 2016-10-14 10:39 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/acbb657405c6 8158380: [macosx] Regression: java/awt/List/ActionEventTest/ActionEventTest.java Reviewed-by: serb, aghaisas Contributed-by: manajit.halder at oracle.com ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java ! test/java/awt/List/ActionEventTest/ActionEventTest.java Changeset: 104b1fb094e6 Author: azvegint Date: 2016-10-14 16:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/104b1fb094e6 8167565: [macosx] Maximization of a dialog hides it Reviewed-by: serb, ssadetsky ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m Changeset: 773164b67434 Author: serb Date: 2016-10-14 19:12 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/773164b67434 8167310: The graphics clip is incorrectly rounded for some fractional scales Reviewed-by: flar ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java ! src/java.desktop/share/classes/sun/java2d/pipe/Region.java + test/java/awt/Graphics/IncorrectFractionalClip/IncorrectFractionalClip.java Changeset: 45061b711579 Author: prr Date: 2016-10-14 11:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/45061b711579 Merge Changeset: e61ec90c30b4 Author: serb Date: 2016-10-14 21:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e61ec90c30b4 8167435: IllegalArgumentException is not thrown by Clip.open(AudioFormat,byte[], int, int) Reviewed-by: amenkov ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftMixingClip.java ! src/java.desktop/share/classes/com/sun/media/sound/Toolkit.java + test/javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java Changeset: f3ce13e9394f Author: prr Date: 2016-10-14 15:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f3ce13e9394f 8166034: [macosx] Non-AA Serif font always displays as regular - no bold Reviewed-by: serb, pnarayanan ! src/java.desktop/share/classes/java/awt/Font.java Changeset: 5f93ebc13ae1 Author: ssadetsky Date: 2016-10-17 09:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f93ebc13ae1 8164321: Crash of SwingNode with GTK LaF Reviewed-by: azvegint, alexsch ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.h Changeset: 815141d605ef Author: ssadetsky Date: 2016-10-17 10:14 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/815141d605ef 8167486: Device.getDisplayMode() doesn't report refresh rate on Linux in case of dual screen Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/DisplayMode.java ! src/java.desktop/unix/native/libawt_xawt/awt/Xrandr.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c + test/java/awt/FullScreen/CurrentDisplayModeTest/CurrentDisplayModeTest.java Changeset: ffba2718d7f6 Author: jdv Date: 2016-10-17 13:04 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ffba2718d7f6 8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods Reviewed-by: prr, pnarayanan ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java + test/javax/imageio/metadata/GetElementsByTagNameTest.java + test/javax/imageio/metadata/NthItemNodeListTest.java Changeset: 6d10cecb150f Author: rchamyal Date: 2016-10-17 13:20 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6d10cecb150f 8161473: [TEST_BUG] [macosx] add autodelay to java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java Reviewed-by: arapte, serb Contributed-by: anubhav.meena at oracle.com ! test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java Changeset: f6eef7e68dea Author: ssadetsky Date: 2016-10-17 10:51 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f6eef7e68dea 8163167: [PIT] javax/swing/JTextArea/ScrollbarFlicker/ScrollFlickerTest.java always fail Reviewed-by: serb, alexsch ! test/javax/swing/JTextArea/ScrollbarFlicker/ScrollFlickerTest.java Changeset: c49a77b864a4 Author: azvegint Date: 2016-10-17 12:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c49a77b864a4 8153526: [Unity] Taskbar.getTaskbar().setMenu(null) doesn't remove menu Reviewed-by: ssadetsky ! src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c Changeset: 79c8d3b12cf1 Author: mhalder Date: 2016-10-17 15:47 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/79c8d3b12cf1 8158390: [macosx] Regression: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java Reviewed-by: serb Contributed-by: manajit.halder at oracle.com ! test/javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java Changeset: 32d9fe67dede Author: arapte Date: 2016-10-17 18:43 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32d9fe67dede 8167288: [TEST_BUG] Consistent failure on Unity of WarningWindowDisposeTest.java Reviewed-by: ssadetsky, alexsch ! test/java/awt/security/WarningWindowDisposeTest/WarningWindowDisposeTest.java Changeset: 15f7a6717104 Author: ssadetsky Date: 2016-10-17 19:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/15f7a6717104 8168077: Solaris build failed: gtk2_interface.h typedef redeclared: GThreadFunctions Reviewed-by: prr ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h Changeset: f950cc6004c6 Author: prr Date: 2016-10-17 13:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f950cc6004c6 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10 Reviewed-by: serb, vadim ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m Changeset: d69c9ce5653d Author: ssadetsky Date: 2016-10-18 12:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d69c9ce5653d 8166897: Some font overlap in the Optionpane dialog. Reviewed-by: azvegint ! src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java Changeset: fec7a8a6a46a Author: serb Date: 2016-10-18 18:00 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fec7a8a6a46a 8166673: The new implementation of Robot.waitForIdle() may hang Reviewed-by: azvegint, ssadetsky ! src/java.desktop/share/classes/sun/awt/SunToolkit.java + test/java/awt/Robot/WaitForIdleSyncroizedOnString/WaitForIdleSyncroizedOnString.java Changeset: d7944c75be9c Author: prr Date: 2016-10-18 13:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7944c75be9c 8167126: Create a module to provide access to non-SE desktop APIs Reviewed-by: alanb, mchung ! src/java.desktop/share/classes/module-info.java + src/jdk.desktop/share/classes/jdk/awt/AWTUtils.java + src/jdk.desktop/share/classes/module-info.java + test/java/awt/jdk/TestJDKAWTUtils.java Changeset: 23544028909a Author: ssadetsky Date: 2016-10-19 11:51 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23544028909a 8154434: Open the request focus methods of the java.awt.Component which accept FocusEvent.Cause Reviewed-by: azvegint ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! src/java.desktop/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java + test/java/awt/Focus/RequestFocusByCause/RequestFocusByCauseTest.java Changeset: 83581f5ab677 Author: prr Date: 2016-10-19 08:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/83581f5ab677 Merge - src/java.base/share/classes/jdk/internal/misc/JavaNetAccess.java - src/jdk.jlink/share/classes/jdk/tools/jlink/Jlink.java - src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkPermission.java Changeset: 64781a24c0f4 Author: alexsch Date: 2016-10-20 12:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64781a24c0f4 8156217: Selected text is shifted on HiDPI display Reviewed-by: prr, serb ! src/java.desktop/share/classes/javax/swing/plaf/TextUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/java.desktop/share/classes/javax/swing/plaf/multi/MultiTextUI.java ! src/java.desktop/share/classes/javax/swing/text/GlyphPainter1.java ! src/java.desktop/share/classes/javax/swing/text/GlyphPainter2.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/ParagraphView.java ! src/java.desktop/share/classes/javax/swing/text/PasswordView.java ! src/java.desktop/share/classes/javax/swing/text/PlainView.java ! src/java.desktop/share/classes/javax/swing/text/Utilities.java ! src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java + test/javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java + test/javax/swing/text/JTextComponent/8156217/TextSelectionTest.java + test/javax/swing/text/View/8156217/FPMethodCalledTest.java Changeset: eddea9682fa9 Author: prr Date: 2016-10-27 08:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eddea9682fa9 8167988: java.nio.file.InvalidPathException if click button in JFileChooser demo of SwingSet2 Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java Changeset: ee20b74f21f3 Author: prr Date: 2016-10-27 08:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee20b74f21f3 Merge - src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java - src/java.base/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java - src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java - src/java.base/windows/native/libnet/icmp.h - test/sun/net/www/protocol/https/HttpsClient/OriginServer.java - test/sun/reflect/ReflectionFactory/NewConstructorForSerialization.java - test/sun/security/tools/jarsigner/ts.sh Changeset: fd0abdaac385 Author: ddehaven Date: 2016-10-27 09:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd0abdaac385 8167187: Exported elements referring to inaccessible types in jdk.jsobject Reviewed-by: mchung, alanb ! src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java Changeset: 7113bb5b075f Author: ksrini Date: 2016-10-27 05:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7113bb5b075f 8168010: Deprecate obsolete launcher -d32/-d64 options Reviewed-by: alanb ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: a3b46c0604d2 Author: mullan Date: 2016-10-27 14:50 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3b46c0604d2 8168851: Tighten permissions granted to the java.smartcardio module Reviewed-by: vinnie, mchung ! src/java.base/share/lib/security/default.policy ! test/sun/security/smartcardio/TestChannel.java ! test/sun/security/smartcardio/TestControl.java ! test/sun/security/smartcardio/TestDefault.java ! test/sun/security/smartcardio/TestDirect.java + test/sun/security/smartcardio/test.policy Changeset: 05ac4f67f7df Author: mullan Date: 2016-10-27 14:52 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/05ac4f67f7df Merge - src/java.desktop/share/classes/com/sun/media/sound/SunCodec.java - test/java/awt/Modal/InvisibleParentTest/InvisibleParentTest.html Changeset: d2e6785070f2 Author: mchung Date: 2016-10-27 13:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d2e6785070f2 8168205: Should not default class path to CWD if -cp is not specified but -m is specified Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.base/share/native/launcher/defines.h ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/java.c + test/tools/launcher/modules/classpath/JavaClassPathTest.java + test/tools/launcher/modules/classpath/src/m/jdk/test/Main.java + test/tools/launcher/modules/classpath/src/m/module-info.java Changeset: e6b6ca2d616e Author: lana Date: 2016-10-27 21:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e6b6ca2d616e Merge - src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java - src/java.base/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java - src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java - src/java.base/windows/native/libnet/icmp.h - src/java.desktop/share/classes/com/sun/media/sound/SunCodec.java - test/java/awt/Modal/InvisibleParentTest/InvisibleParentTest.html Changeset: 8a62cba5c9ff Author: xuelei Date: 2016-10-27 23:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a62cba5c9ff 8168822: Document that algorithm restrictions do not apply to trusted anchors Reviewed-by: weijun, jnimeh, mullan ! src/java.base/share/conf/security/java.security Changeset: afe2c6190333 Author: alanb Date: 2016-10-28 10:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/afe2c6190333 8168789: ModuleReader.list and ModuleFinder.of update Reviewed-by: mchung ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/jmod/JmodFile.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/ConfigurableModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.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/module/AutomaticModulesTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java + test/java/lang/module/MultiReleaseJarTest.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/jmod/hashes/HashesTest.java Changeset: 9a3a5bc38432 Author: dfuchs Date: 2016-10-28 12:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a3a5bc38432 8163162: The separation between system loggers and application loggers should take the extension loader in consideration. Summary: DefaultLoggerFinder.isSystem is changed to return 'true' for classes loaded from the platform loader and its ancestors. This means that classes loaded by the platform loader will get exactly the same kind of loggers than classes loaded by the boot (null) loader. Reviewed-by: rriggs, mchung ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java + test/java/lang/System/LoggerFinder/internal/SystemLoggerInPlatformLoader/SystemLoggerInPlatformLoader.java + test/java/lang/System/LoggerFinder/internal/SystemLoggerInPlatformLoader/systempkg/log/SystemLoggerAccessor.java Changeset: 3192d7aa428d Author: rpatil Date: 2016-10-28 10:10 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3192d7aa428d 8168512: (tz) Support tzdata2016h Reviewed-by: martin, okutsu ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/northamerica Changeset: 42268eb6e04e Author: xuelei Date: 2016-10-29 13:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/42268eb6e04e 8167680: DTLS implementation bugs Reviewed-by: jnimeh, asmotrak ! src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java ! src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/DTLSRecord.java ! src/java.base/share/classes/sun/security/ssl/Debug.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/Plaintext.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java ! test/javax/net/ssl/DTLS/DTLSOverDatagram.java + test/javax/net/ssl/DTLS/PacketLossRetransmission.java + test/javax/net/ssl/DTLS/RespondToRetransmit.java ! test/javax/net/ssl/TLSCommon/SSLEngineTestCase.java Changeset: 00192a14fdc6 Author: amlu Date: 2016-10-31 13:45 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/00192a14fdc6 8168524: Remove two jdk_nio tests from ProblemList: BashStreams and DeleteInterference.java Reviewed-by: bpb, rriggs ! test/ProblemList.txt Changeset: 5d95f2e1b9eb Author: weijun Date: 2016-10-31 16:40 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5d95f2e1b9eb 8168127: FilePermissionCollection merges incorrectly Reviewed-by: rriggs ! src/java.base/share/classes/java/io/FilePermission.java + test/java/io/FilePermission/FilePermissionCollectionMerge.java Changeset: 77f35eef4ef9 Author: weijun Date: 2016-10-31 16:41 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/77f35eef4ef9 8167646: Better invalid FilePermission Reviewed-by: rriggs ! src/java.base/share/classes/java/io/FilePermission.java + test/java/io/FilePermission/Invalid.java Changeset: 608dcced40aa Author: sherman Date: 2016-10-31 10:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/608dcced40aa 8166261: Scanner.nextInt(int) (and similar methods) throws PatternSyntaxException Reviewed-by: naoto ! src/java.base/share/classes/java/util/Scanner.java ! test/java/util/Scanner/ScanTest.java Changeset: 88ec80d47d4a Author: rriggs Date: 2016-10-31 13:57 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88ec80d47d4a 8168517: java/lang/ProcessBuilder/Basic.java failed Reviewed-by: dholmes ! test/java/lang/ProcessBuilder/Basic.java Changeset: 4891c03305cc Author: wetmore Date: 2016-10-31 14:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4891c03305cc 4985694: Incomplete spec for most of the getInstances Reviewed-by: xuelei, mullan ! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java ! src/java.base/share/classes/java/security/AlgorithmParameters.java ! src/java.base/share/classes/java/security/KeyFactory.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/KeyStore.java ! src/java.base/share/classes/java/security/MessageDigest.java ! src/java.base/share/classes/java/security/Policy.java ! src/java.base/share/classes/java/security/SecureRandom.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/security/cert/CertPathBuilder.java ! src/java.base/share/classes/java/security/cert/CertPathValidator.java ! src/java.base/share/classes/java/security/cert/CertStore.java ! src/java.base/share/classes/java/security/cert/CertificateFactory.java ! src/java.base/share/classes/javax/crypto/Cipher.java ! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java ! src/java.base/share/classes/javax/crypto/KeyAgreement.java ! src/java.base/share/classes/javax/crypto/KeyGenerator.java ! src/java.base/share/classes/javax/crypto/Mac.java ! src/java.base/share/classes/javax/crypto/SecretKeyFactory.java ! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLContext.java ! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/java.base/share/classes/javax/security/auth/login/Configuration.java + test/java/security/misc/GetInstanceNullsEmpties.java Changeset: 7745b4f6cbde Author: chegar Date: 2016-11-01 12:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7745b4f6cbde 8168980: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class,Constructor) Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java ! test/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java Changeset: f3e3ad225c1e Author: sdrach Date: 2016-11-01 14:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f3e3ad225c1e 8156499: Update jlink to support creating images with modules that are packaged as multi-release JARs Reviewed-by: alanb, mchung ! src/java.base/share/classes/module-info.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModularJarArchive.java + test/tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java + test/tools/jlink/multireleasejar/base/m1/module-info.java + test/tools/jlink/multireleasejar/base/m1/p/Main.java + test/tools/jlink/multireleasejar/rt/m1/module-info.java + test/tools/jlink/multireleasejar/rt/m1/p/Main.java + test/tools/jlink/multireleasejar/rt/m1/p/Type.java + test/tools/jlink/multireleasejar/rt/m1/q/PublicClass.java Changeset: 29831b6c481b Author: psandoz Date: 2016-11-01 17:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/29831b6c481b 8167974: MethodHandles.iteratedLoop(...) fails with CCE in the case of iterating over array 8167966: MethodHandles.iteratedLoop fails with IAE in the case of correct arguments Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/LoopCombinatorTest.java Changeset: 92103cb21bd6 Author: psandoz Date: 2016-11-01 17:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92103cb21bd6 8168841: The JavaDoc of java.util.stream.Collectors method collectingAndThen has incorrect code snippet Reviewed-by: smarks, lancea, tvaleev ! src/java.base/share/classes/java/util/stream/Collectors.java Changeset: 58796fb3241f Author: sundar Date: 2016-11-02 10:49 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/58796fb3241f 8160063: Provide a means to disable a plugin via the command line Reviewed-by: jlaskey ! 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/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/tools/jlink/JLinkPluginsTest.java Changeset: 79d71eeecfc8 Author: weijun Date: 2016-11-02 14:44 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/79d71eeecfc8 8168518: rcache interop with krb5-1.15 Reviewed-by: xuelei ! src/java.security.jgss/share/classes/sun/security/krb5/KrbApReq.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/rcache/AuthTime.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/rcache/AuthTimeWithHash.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/rcache/DflCache.java ! test/java/security/testlibrary/Proc.java ! test/sun/security/krb5/auto/ReplayCacheExpunge.java ! test/sun/security/krb5/auto/ReplayCachePrecise.java ! test/sun/security/krb5/auto/ReplayCacheTestProc.java + test/sun/security/krb5/auto/rcache_usemd5.sh Changeset: be7aedddbb76 Author: erikj Date: 2016-11-02 10:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be7aedddbb76 8063154: Checked in jvmti.h not in sync with generated jvmti.h Reviewed-by: tbell ! make/copy/Copy-java.base.gmk - src/java.base/share/native/include/jvmti.h Changeset: 6577fabed061 Author: clanger Date: 2016-11-02 11:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6577fabed061 8168771: Remove #ifdef AF_INET6 guards in libnet native coding Reviewed-by: chegar ! src/java.base/share/native/libnet/net_util.c ! src/java.base/unix/native/libnet/Inet6AddressImpl.c ! src/java.base/unix/native/libnet/InetAddressImplFactory.c ! src/java.base/unix/native/libnet/NetworkInterface.c ! src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c ! src/java.base/unix/native/libnet/PlainSocketImpl.c ! src/java.base/unix/native/libnet/SdpSupport.c ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/unix/native/libnet/net_util_md.h ! src/java.base/windows/native/libnet/Inet6AddressImpl.c Changeset: 9372d3dd3aae Author: dfuchs Date: 2016-11-02 14:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9372d3dd3aae 8152515: (logging) LogManager.resetLogger should ignore LinkageError Summary: LogManager.resetLogger will also ignore errors, but only while shutting down. Reviewed-by: rriggs, dholmes ! src/java.logging/share/classes/java/util/logging/LogManager.java + test/java/util/logging/LogManager/LinkageErrorTest.java Changeset: 8dbc8594f9d5 Author: darcy Date: 2016-11-03 01:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8dbc8594f9d5 8169024: Problem list OpenNonIntegralNumberOfSampleframes.java until JDK-8168881 is fixed Reviewed-by: rriggs ! test/ProblemList.txt Changeset: 1574becd1f23 Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1574becd1f23 Added tag jdk-9+143 for changeset 8dbc8594f9d5 ! .hgtags Changeset: d7bb81096499 Author: mchung Date: 2016-11-05 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7bb81096499 Merge ! .hgtags ! make/copy/Copy-java.base.gmk ! make/gendata/GendataBreakIterator.gmk ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java - 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/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/jmod/JmodFile.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.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/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/text/BreakDictionary.java ! src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java ! src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java ! src/java.base/share/conf/security/java.security ! src/java.base/share/native/launcher/defines.h ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/java.c ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/module-info.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.rmi/share/classes/sun/rmi/server/Activation.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/rcache/DflCache.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jdi/share/classes/module-info.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/ModularJarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/ProblemList.txt ! test/TEST.groups ! test/com/sun/corba/serialization/ObjectStreamTest.java ! test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.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/System/LoggerFinder/internal/SystemLoggerInPlatformLoader/SystemLoggerInPlatformLoader.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.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/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/security/testlibrary/Proc.java ! test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesProvider.java - test/java/util/ServiceLoader/Basic.java - test/java/util/ServiceLoader/FooProvider1.java - test/java/util/ServiceLoader/FooProvider2.java - test/java/util/ServiceLoader/FooProvider3.java - test/java/util/ServiceLoader/FooService.java - test/java/util/ServiceLoader/Load.java - test/java/util/ServiceLoader/basic.sh - 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/DTLSOverDatagram.java ! test/tools/jar/mmrjar/ConcealedPackage.java ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/JLinkPluginsTest.java ! test/tools/jlink/JLinkTest.java + test/tools/jlink/basic/AllModulePath.java ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java ! test/tools/jmod/hashes/HashesTest.java ! test/tools/pack200/Utils.java From mandy.chung at oracle.com Sat Nov 5 19:05:23 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 05 Nov 2016 19:05:23 +0000 Subject: hg: jigsaw/jake/nashorn: 5 new changesets Message-ID: <201611051905.uA5J5NpG022198@aojmv0008.oracle.com> Changeset: 96f47313aae7 Author: hannesw Date: 2016-10-28 16:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/96f47313aae7 8148924: Inconsistent "this" context in JSAdapter adaptee function calls Reviewed-by: jlaskey ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java ! test/script/basic/jsadapter-ids.js ! test/script/basic/jsadapter.js ! test/script/basic/jsadapter.js.EXPECTED ! test/script/basic/jsadapterlink.js Changeset: 7caf1f762f1d Author: attila Date: 2016-11-01 15:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7caf1f762f1d 8168005: Introduce namespaces for GET, SET Dynalink operations Reviewed-by: hannesw, sundar ! samples/dynalink/ArrayStreamLinkerExporter.java ! samples/dynalink/BufferIndexingLinkerExporter.java ! samples/dynalink/DOMLinkerExporter.java ! samples/dynalink/MissingMethodLinkerExporter.java ! samples/dynalink/UnderscoreNameLinkerExporter.java ! src/jdk.dynalink/share/classes/jdk/dynalink/CallSiteDescriptor.java - src/jdk.dynalink/share/classes/jdk/dynalink/CompositeOperation.java ! src/jdk.dynalink/share/classes/jdk/dynalink/NamedOperation.java + src/jdk.dynalink/share/classes/jdk/dynalink/Namespace.java + src/jdk.dynalink/share/classes/jdk/dynalink/NamespaceOperation.java ! src/jdk.dynalink/share/classes/jdk/dynalink/Operation.java + src/jdk.dynalink/share/classes/jdk/dynalink/StandardNamespace.java ! src/jdk.dynalink/share/classes/jdk/dynalink/StandardOperation.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/AbstractJavaLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeansLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/DynamicMethodLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/GuardedInvocationComponent.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/StaticClass.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/StaticClassLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/package-info.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! test/src/jdk/dynalink/beans/test/BeanLinkerTest.java ! test/src/jdk/dynalink/beans/test/BeansLinkerTest.java ! test/src/jdk/dynalink/support/test/CallSiteTest.java ! test/src/jdk/dynalink/test/DynamicLinkerFactoryTest.java ! test/src/jdk/dynalink/test/LinkedCallSiteLocationTest.java Changeset: b4e57ead3fae Author: sundar Date: 2016-11-02 18:36 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b4e57ead3fae 8169050: underscore_linker.js sample fails after dynalink changes for JDK-8168005 Reviewed-by: jlaskey, hannesw ! samples/dynalink/underscore_linker.js ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! test/src/META-INF/services/jdk.dynalink.linker.GuardingDynamicLinkerExporter + test/src/jdk/dynalink/test/TrustedUnderscoreNameLinkerExporter.java ! test/src/jdk/nashorn/api/javaaccess/test/ArrayConversionTest.java + test/src/jdk/nashorn/api/scripting/test/JDK_8169050_Test.java Changeset: d2b0a8054f9f Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d2b0a8054f9f Added tag jdk-9+143 for changeset b4e57ead3fae ! .hgtags Changeset: cc05275c5f44 Author: mchung Date: 2016-11-05 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cc05275c5f44 Merge ! .hgtags ! test/src/jdk/dynalink/test/DynamicLinkerFactoryTest.java From alan.bateman at oracle.com Sat Nov 5 20:38:23 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 05 Nov 2016 20:38:23 +0000 Subject: hg: jigsaw/jake/jdk: sun/security/krb5/ccache/TimeInCCache.java failing Message-ID: <201611052038.uA5KcN7i010574@aojmv0008.oracle.com> Changeset: 78d0327ac55c Author: alanb Date: 2016-11-05 20:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/78d0327ac55c sun/security/krb5/ccache/TimeInCCache.java failing ! test/sun/security/krb5/ccache/TimeInCCache.java From james.laskey at oracle.com Mon Nov 7 12:29:27 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 08:29:27 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned Message-ID: http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html https://bugs.openjdk.java.net/browse/JDK-8159393 From Alan.Bateman at oracle.com Mon Nov 7 12:40:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Nov 2016 12:40:39 +0000 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: Message-ID: n 07/11/2016 12:29, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html > https://bugs.openjdk.java.net/browse/JDK-8159393 > I think this is the link: http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html I hope someone from the security area will be able to help review this. One thing that isn't clear to me is whether the check for META-INF/SIG-* is right. Also I assume you need to toUpperCase(Locale.ENGLISH) to align with how JAR file verification checks for signed JARs. In passing, should the usage and warning use "modular JAR" rather than "modular jar"? -Alan From james.laskey at oracle.com Mon Nov 7 13:09:19 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 09:09:19 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: Message-ID: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> Thank you. Regarding SIG- I was just followed the spec. Signed JAR File <>Overview A JAR file can be signed by using the command line jarsigner tool or directly through the java.security API. Every file entry, including non-signature related files in the META-INF directory, will be signed if the JAR file is signed by the jarsigner tool. The signature related files are: META-INF/MANIFEST.MF META-INF/*.SF META-INF/*.DSA META-INF/*.RSA META-INF/SIG-* Note that if such files are located in META-INF subdirectories, they are not considered signature-related. Case-insensitive versions of these filenames are reserved and will also not be signed. Subsets of a JAR file can be signed by using the java.security API. A signed JAR file is exactly the same as the original JAR file, except that its manifest is updated and two additional files are added to the META-INF directory: a signature file and a signature block file. When jarsigner is not used, the signing program has to construct both the signature file and the signature block file. > On Nov 7, 2016, at 8:40 AM, Alan Bateman wrote: > > > n 07/11/2016 12:29, Jim Laskey (Oracle) wrote: >> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html >> https://bugs.openjdk.java.net/browse/JDK-8159393 >> > I think this is the link: > http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html > > I hope someone from the security area will be able to help review this. One thing that isn't clear to me is whether the check for META-INF/SIG-* is right. Also I assume you need to toUpperCase(Locale.ENGLISH) to align with how JAR file verification checks for signed JARs. > > In passing, should the usage and warning use "modular JAR" rather than "modular jar"? > > -Alan > From james.laskey at oracle.com Mon Nov 7 13:13:05 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 09:13:05 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> Message-ID: <594D2DC8-4EF5-4BC2-9FBE-D5B008578579@oracle.com> But I need to be more careful with "Note that if such files are located in META-INF subdirectories, they are not considered signature-related.? > On Nov 7, 2016, at 9:09 AM, Jim Laskey (Oracle) wrote: > > Thank you. Regarding SIG- I was just followed the spec. > > > Signed JAR File > <>Overview > A JAR file can be signed by using the command line jarsigner tool or directly through the java.security API. Every file entry, including non-signature related files in the META-INF directory, will be signed if the JAR file is signed by the jarsigner tool. The signature related files are: > META-INF/MANIFEST.MF > META-INF/*.SF > META-INF/*.DSA > META-INF/*.RSA > META-INF/SIG-* > Note that if such files are located in META-INF subdirectories, they are not considered signature-related. Case-insensitive versions of these filenames are reserved and will also not be signed. > Subsets of a JAR file can be signed by using the java.security API. A signed JAR file is exactly the same as the original JAR file, except that its manifest is updated and two additional files are added to the META-INF directory: a signature file and a signature block file. When jarsigner is not used, the signing program has to construct both the signature file and the signature block file. > > >> On Nov 7, 2016, at 8:40 AM, Alan Bateman wrote: >> >> >> n 07/11/2016 12:29, Jim Laskey (Oracle) wrote: >>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html >>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>> >> I think this is the link: >> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >> >> I hope someone from the security area will be able to help review this. One thing that isn't clear to me is whether the check for META-INF/SIG-* is right. Also I assume you need to toUpperCase(Locale.ENGLISH) to align with how JAR file verification checks for signed JARs. >> >> In passing, should the usage and warning use "modular JAR" rather than "modular jar"? >> >> -Alan >> > From Alan.Bateman at oracle.com Mon Nov 7 13:16:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Nov 2016 13:16:41 +0000 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> Message-ID: <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: > Thank you. Regarding SIG- I was just followed the spec. > I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. -Alan From james.laskey at oracle.com Mon Nov 7 13:17:58 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 09:17:58 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> Message-ID: Right. From SignatureFileVerifier.java /** * Utility method used by JarVerifier and JarSigner * to determine the signature file names and PKCS7 block * files names that are supported * * @param s file name * @return true if the input file name is a supported * Signature File or PKCS7 block file name */ public static boolean isBlockOrSF(String s) { // we currently only support DSA and RSA PKCS7 blocks return s.endsWith(".SF") || s.endsWith(".DSA") || s.endsWith(".RSA") || s.endsWith(".EC"); } /** * Yet another utility method used by JarVerifier and JarSigner * to determine what files are signature related, which includes * the MANIFEST, SF files, known signature block files, and other * unknown signature related files (those starting with SIG- with * an optional [A-Z0-9]{1,3} extension right inside META-INF). * * @param name file name * @return true if the input file name is signature related */ public static boolean isSigningRelated(String name) { name = name.toUpperCase(Locale.ENGLISH); if (!name.startsWith("META-INF/")) { return false; } name = name.substring(9); if (name.indexOf('/') != -1) { return false; } if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { return true; } else if (name.startsWith("SIG-")) { // check filename extension // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures // for what filename extensions are legal int extIndex = name.lastIndexOf('.'); if (extIndex != -1) { String ext = name.substring(extIndex + 1); // validate length first if (ext.length() > 3 || ext.length() < 1) { return false; } // then check chars, must be in [a-zA-Z0-9] per the jar spec for (int index = 0; index < ext.length(); index++) { char cc = ext.charAt(index); // chars are promoted to uppercase so skip lowercase checks if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return false; } } } return true; // no extension is OK } return false; } > On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: > > On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: > >> Thank you. Regarding SIG- I was just followed the spec. >> > I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. > > -Alan From james.laskey at oracle.com Mon Nov 7 13:26:21 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 09:26:21 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> Message-ID: <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> Revising to String name = entry.name().toUpperCase(Locale.ENGLISH); return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") || name.endsWith(".RSA") || name.endsWith(".EC") || name.startsWith("META-INF/SIG-") ); > On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) wrote: > > Right. From SignatureFileVerifier.java > > > /** > * Utility method used by JarVerifier and JarSigner > * to determine the signature file names and PKCS7 block > * files names that are supported > * > * @param s file name > * @return true if the input file name is a supported > * Signature File or PKCS7 block file name > */ > public static boolean isBlockOrSF(String s) { > // we currently only support DSA and RSA PKCS7 blocks > return s.endsWith(".SF") > || s.endsWith(".DSA") > || s.endsWith(".RSA") > || s.endsWith(".EC"); > } > > /** > * Yet another utility method used by JarVerifier and JarSigner > * to determine what files are signature related, which includes > * the MANIFEST, SF files, known signature block files, and other > * unknown signature related files (those starting with SIG- with > * an optional [A-Z0-9]{1,3} extension right inside META-INF). > * > * @param name file name > * @return true if the input file name is signature related > */ > public static boolean isSigningRelated(String name) { > name = name.toUpperCase(Locale.ENGLISH); > if (!name.startsWith("META-INF/")) { > return false; > } > name = name.substring(9); > if (name.indexOf('/') != -1) { > return false; > } > if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { > return true; > } else if (name.startsWith("SIG-")) { > // check filename extension > // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures > // for what filename extensions are legal > int extIndex = name.lastIndexOf('.'); > if (extIndex != -1) { > String ext = name.substring(extIndex + 1); > // validate length first > if (ext.length() > 3 || ext.length() < 1) { > return false; > } > // then check chars, must be in [a-zA-Z0-9] per the jar spec > for (int index = 0; index < ext.length(); index++) { > char cc = ext.charAt(index); > // chars are promoted to uppercase so skip lowercase checks > if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { > return false; > } > } > } > return true; // no extension is OK > } > return false; > } > > > > > >> On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: >> >> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >> >>> Thank you. Regarding SIG- I was just followed the spec. >>> >> I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. >> >> -Alan > From james.laskey at oracle.com Mon Nov 7 13:48:46 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 09:48:46 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> Message-ID: Apologies for the poor links earlier. http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8159393 > On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) wrote: > > Revising to > > String name = entry.name().toUpperCase(Locale.ENGLISH); > > return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( > name.endsWith(".SF") || > name.endsWith(".DSA") || > name.endsWith(".RSA") || > name.endsWith(".EC") || > name.startsWith("META-INF/SIG-") > ); > > >> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) wrote: >> >> Right. From SignatureFileVerifier.java >> >> >> /** >> * Utility method used by JarVerifier and JarSigner >> * to determine the signature file names and PKCS7 block >> * files names that are supported >> * >> * @param s file name >> * @return true if the input file name is a supported >> * Signature File or PKCS7 block file name >> */ >> public static boolean isBlockOrSF(String s) { >> // we currently only support DSA and RSA PKCS7 blocks >> return s.endsWith(".SF") >> || s.endsWith(".DSA") >> || s.endsWith(".RSA") >> || s.endsWith(".EC"); >> } >> >> /** >> * Yet another utility method used by JarVerifier and JarSigner >> * to determine what files are signature related, which includes >> * the MANIFEST, SF files, known signature block files, and other >> * unknown signature related files (those starting with SIG- with >> * an optional [A-Z0-9]{1,3} extension right inside META-INF). >> * >> * @param name file name >> * @return true if the input file name is signature related >> */ >> public static boolean isSigningRelated(String name) { >> name = name.toUpperCase(Locale.ENGLISH); >> if (!name.startsWith("META-INF/")) { >> return false; >> } >> name = name.substring(9); >> if (name.indexOf('/') != -1) { >> return false; >> } >> if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { >> return true; >> } else if (name.startsWith("SIG-")) { >> // check filename extension >> // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >> // for what filename extensions are legal >> int extIndex = name.lastIndexOf('.'); >> if (extIndex != -1) { >> String ext = name.substring(extIndex + 1); >> // validate length first >> if (ext.length() > 3 || ext.length() < 1) { >> return false; >> } >> // then check chars, must be in [a-zA-Z0-9] per the jar spec >> for (int index = 0; index < ext.length(); index++) { >> char cc = ext.charAt(index); >> // chars are promoted to uppercase so skip lowercase checks >> if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { >> return false; >> } >> } >> } >> return true; // no extension is OK >> } >> return false; >> } >> >> >> >> >> >>> On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: >>> >>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>> >>>> Thank you. Regarding SIG- I was just followed the spec. >>>> >>> I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. >>> >>> -Alan >> > From weijun.wang at oracle.com Mon Nov 7 14:06:11 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 7 Nov 2016 22:06:11 +0800 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> Message-ID: The code block below checking if a jar file was signed is correct. There is one thing I don't understand, the --strip-signing-information option. It looks like you will remove the signature-related files if this option is set. But, where are they stripped? Thanks Max On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: > Apologies for the poor links earlier. > > http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8159393 > > >> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) wrote: >> >> Revising to >> >> String name = entry.name().toUpperCase(Locale.ENGLISH); >> >> return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( >> name.endsWith(".SF") || >> name.endsWith(".DSA") || >> name.endsWith(".RSA") || >> name.endsWith(".EC") || >> name.startsWith("META-INF/SIG-") >> ); >> >> >>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) wrote: >>> >>> Right. From SignatureFileVerifier.java >>> >>> >>> /** >>> * Utility method used by JarVerifier and JarSigner >>> * to determine the signature file names and PKCS7 block >>> * files names that are supported >>> * >>> * @param s file name >>> * @return true if the input file name is a supported >>> * Signature File or PKCS7 block file name >>> */ >>> public static boolean isBlockOrSF(String s) { >>> // we currently only support DSA and RSA PKCS7 blocks >>> return s.endsWith(".SF") >>> || s.endsWith(".DSA") >>> || s.endsWith(".RSA") >>> || s.endsWith(".EC"); >>> } >>> >>> /** >>> * Yet another utility method used by JarVerifier and JarSigner >>> * to determine what files are signature related, which includes >>> * the MANIFEST, SF files, known signature block files, and other >>> * unknown signature related files (those starting with SIG- with >>> * an optional [A-Z0-9]{1,3} extension right inside META-INF). >>> * >>> * @param name file name >>> * @return true if the input file name is signature related >>> */ >>> public static boolean isSigningRelated(String name) { >>> name = name.toUpperCase(Locale.ENGLISH); >>> if (!name.startsWith("META-INF/")) { >>> return false; >>> } >>> name = name.substring(9); >>> if (name.indexOf('/') != -1) { >>> return false; >>> } >>> if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { >>> return true; >>> } else if (name.startsWith("SIG-")) { >>> // check filename extension >>> // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>> // for what filename extensions are legal >>> int extIndex = name.lastIndexOf('.'); >>> if (extIndex != -1) { >>> String ext = name.substring(extIndex + 1); >>> // validate length first >>> if (ext.length() > 3 || ext.length() < 1) { >>> return false; >>> } >>> // then check chars, must be in [a-zA-Z0-9] per the jar spec >>> for (int index = 0; index < ext.length(); index++) { >>> char cc = ext.charAt(index); >>> // chars are promoted to uppercase so skip lowercase checks >>> if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { >>> return false; >>> } >>> } >>> } >>> return true; // no extension is OK >>> } >>> return false; >>> } >>> >>> >>> >>> >>> >>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: >>>> >>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>> >>>>> Thank you. Regarding SIG- I was just followed the spec. >>>>> >>>> I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. >>>> >>>> -Alan >>> >> > From Alan.Bateman at oracle.com Mon Nov 7 14:11:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Nov 2016 14:11:34 +0000 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> Message-ID: <24fa9e36-8dc3-f42a-b004-422693a49834@oracle.com> On 07/11/2016 13:26, Jim Laskey (Oracle) wrote: > Revising to > > String name = entry.name().toUpperCase(Locale.ENGLISH); > > return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( > name.endsWith(".SF") || > name.endsWith(".DSA") || > name.endsWith(".RSA") || > name.endsWith(".EC") || > name.startsWith("META-INF/SIG-") > ); > > Good, I think this is right now but I'm sure Sean or Max will jump in at some point to say for sure. -Alan From james.laskey at oracle.com Mon Nov 7 14:11:34 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 10:11:34 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> Message-ID: <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> The security entries are (have been) ignored when building the image. At some future date (post-9), we need to decide how to sign an image. ? Jim > On Nov 7, 2016, at 10:06 AM, Wang Weijun wrote: > > The code block below checking if a jar file was signed is correct. > > There is one thing I don't understand, the --strip-signing-information option. It looks like you will remove the signature-related files if this option is set. But, where are they stripped? > > Thanks > Max > > On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >> Apologies for the poor links earlier. >> >> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8159393 >> >> >>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) wrote: >>> >>> Revising to >>> >>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>> >>> return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( >>> name.endsWith(".SF") || >>> name.endsWith(".DSA") || >>> name.endsWith(".RSA") || >>> name.endsWith(".EC") || >>> name.startsWith("META-INF/SIG-") >>> ); >>> >>> >>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) wrote: >>>> >>>> Right. From SignatureFileVerifier.java >>>> >>>> >>>> /** >>>> * Utility method used by JarVerifier and JarSigner >>>> * to determine the signature file names and PKCS7 block >>>> * files names that are supported >>>> * >>>> * @param s file name >>>> * @return true if the input file name is a supported >>>> * Signature File or PKCS7 block file name >>>> */ >>>> public static boolean isBlockOrSF(String s) { >>>> // we currently only support DSA and RSA PKCS7 blocks >>>> return s.endsWith(".SF") >>>> || s.endsWith(".DSA") >>>> || s.endsWith(".RSA") >>>> || s.endsWith(".EC"); >>>> } >>>> >>>> /** >>>> * Yet another utility method used by JarVerifier and JarSigner >>>> * to determine what files are signature related, which includes >>>> * the MANIFEST, SF files, known signature block files, and other >>>> * unknown signature related files (those starting with SIG- with >>>> * an optional [A-Z0-9]{1,3} extension right inside META-INF). >>>> * >>>> * @param name file name >>>> * @return true if the input file name is signature related >>>> */ >>>> public static boolean isSigningRelated(String name) { >>>> name = name.toUpperCase(Locale.ENGLISH); >>>> if (!name.startsWith("META-INF/")) { >>>> return false; >>>> } >>>> name = name.substring(9); >>>> if (name.indexOf('/') != -1) { >>>> return false; >>>> } >>>> if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { >>>> return true; >>>> } else if (name.startsWith("SIG-")) { >>>> // check filename extension >>>> // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>> // for what filename extensions are legal >>>> int extIndex = name.lastIndexOf('.'); >>>> if (extIndex != -1) { >>>> String ext = name.substring(extIndex + 1); >>>> // validate length first >>>> if (ext.length() > 3 || ext.length() < 1) { >>>> return false; >>>> } >>>> // then check chars, must be in [a-zA-Z0-9] per the jar spec >>>> for (int index = 0; index < ext.length(); index++) { >>>> char cc = ext.charAt(index); >>>> // chars are promoted to uppercase so skip lowercase checks >>>> if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { >>>> return false; >>>> } >>>> } >>>> } >>>> return true; // no extension is OK >>>> } >>>> return false; >>>> } >>>> >>>> >>>> >>>> >>>> >>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: >>>>> >>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>> >>>>>> Thank you. Regarding SIG- I was just followed the spec. >>>>>> >>>>> I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. >>>>> >>>>> -Alan >>>> >>> >> From james.laskey at oracle.com Mon Nov 7 14:13:59 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 10:13:59 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> Message-ID: <1209169F-79FB-4AAB-860E-60078BE0CD30@oracle.com> The bug https://bugs.openjdk.java.net/browse/JDK-8159393 is really about warning developers that their image does not support signing. If they are okay with that then they can override with --strip-signing-information. ? Jim > On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle) wrote: > > The security entries are (have been) ignored when building the image. At some future date (post-9), we need to decide how to sign an image. > > ? Jim > > >> On Nov 7, 2016, at 10:06 AM, Wang Weijun wrote: >> >> The code block below checking if a jar file was signed is correct. >> >> There is one thing I don't understand, the --strip-signing-information option. It looks like you will remove the signature-related files if this option is set. But, where are they stripped? >> >> Thanks >> Max >> >> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >>> Apologies for the poor links earlier. >>> >>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>> >>> >>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) wrote: >>>> >>>> Revising to >>>> >>>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>>> >>>> return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( >>>> name.endsWith(".SF") || >>>> name.endsWith(".DSA") || >>>> name.endsWith(".RSA") || >>>> name.endsWith(".EC") || >>>> name.startsWith("META-INF/SIG-") >>>> ); >>>> >>>> >>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) wrote: >>>>> >>>>> Right. From SignatureFileVerifier.java >>>>> >>>>> >>>>> /** >>>>> * Utility method used by JarVerifier and JarSigner >>>>> * to determine the signature file names and PKCS7 block >>>>> * files names that are supported >>>>> * >>>>> * @param s file name >>>>> * @return true if the input file name is a supported >>>>> * Signature File or PKCS7 block file name >>>>> */ >>>>> public static boolean isBlockOrSF(String s) { >>>>> // we currently only support DSA and RSA PKCS7 blocks >>>>> return s.endsWith(".SF") >>>>> || s.endsWith(".DSA") >>>>> || s.endsWith(".RSA") >>>>> || s.endsWith(".EC"); >>>>> } >>>>> >>>>> /** >>>>> * Yet another utility method used by JarVerifier and JarSigner >>>>> * to determine what files are signature related, which includes >>>>> * the MANIFEST, SF files, known signature block files, and other >>>>> * unknown signature related files (those starting with SIG- with >>>>> * an optional [A-Z0-9]{1,3} extension right inside META-INF). >>>>> * >>>>> * @param name file name >>>>> * @return true if the input file name is signature related >>>>> */ >>>>> public static boolean isSigningRelated(String name) { >>>>> name = name.toUpperCase(Locale.ENGLISH); >>>>> if (!name.startsWith("META-INF/")) { >>>>> return false; >>>>> } >>>>> name = name.substring(9); >>>>> if (name.indexOf('/') != -1) { >>>>> return false; >>>>> } >>>>> if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { >>>>> return true; >>>>> } else if (name.startsWith("SIG-")) { >>>>> // check filename extension >>>>> // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>>> // for what filename extensions are legal >>>>> int extIndex = name.lastIndexOf('.'); >>>>> if (extIndex != -1) { >>>>> String ext = name.substring(extIndex + 1); >>>>> // validate length first >>>>> if (ext.length() > 3 || ext.length() < 1) { >>>>> return false; >>>>> } >>>>> // then check chars, must be in [a-zA-Z0-9] per the jar spec >>>>> for (int index = 0; index < ext.length(); index++) { >>>>> char cc = ext.charAt(index); >>>>> // chars are promoted to uppercase so skip lowercase checks >>>>> if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { >>>>> return false; >>>>> } >>>>> } >>>>> } >>>>> return true; // no extension is OK >>>>> } >>>>> return false; >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: >>>>>> >>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>>> >>>>>>> Thank you. Regarding SIG- I was just followed the spec. >>>>>>> >>>>>> I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. >>>>>> >>>>>> -Alan >>>>> >>>> >>> > From weijun.wang at oracle.com Mon Nov 7 14:33:12 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 7 Nov 2016 22:33:12 +0800 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> Message-ID: Great. I asked the question because you will need the exact same check to determine what files should be ignored and I thought they should appear in the same webrev. If it's already done somewhere else please make sure it is the same. Thanks Max > ? 2016?11?7??22:11?Jim Laskey (Oracle) ??? > > The security entries are (have been) ignored when building the image. At some future date (post-9), we need to decide how to sign an image. > > ? Jim > > >> On Nov 7, 2016, at 10:06 AM, Wang Weijun wrote: >> >> The code block below checking if a jar file was signed is correct. >> >> There is one thing I don't understand, the --strip-signing-information option. It looks like you will remove the signature-related files if this option is set. But, where are they stripped? >> >> Thanks >> Max >> >>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >>> Apologies for the poor links earlier. >>> >>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>> >>> >>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) wrote: >>>> >>>> Revising to >>>> >>>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>>> >>>> return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( >>>> name.endsWith(".SF") || >>>> name.endsWith(".DSA") || >>>> name.endsWith(".RSA") || >>>> name.endsWith(".EC") || >>>> name.startsWith("META-INF/SIG-") >>>> ); >>>> >>>> >>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) wrote: >>>>> >>>>> Right. From SignatureFileVerifier.java >>>>> >>>>> >>>>> /** >>>>> * Utility method used by JarVerifier and JarSigner >>>>> * to determine the signature file names and PKCS7 block >>>>> * files names that are supported >>>>> * >>>>> * @param s file name >>>>> * @return true if the input file name is a supported >>>>> * Signature File or PKCS7 block file name >>>>> */ >>>>> public static boolean isBlockOrSF(String s) { >>>>> // we currently only support DSA and RSA PKCS7 blocks >>>>> return s.endsWith(".SF") >>>>> || s.endsWith(".DSA") >>>>> || s.endsWith(".RSA") >>>>> || s.endsWith(".EC"); >>>>> } >>>>> >>>>> /** >>>>> * Yet another utility method used by JarVerifier and JarSigner >>>>> * to determine what files are signature related, which includes >>>>> * the MANIFEST, SF files, known signature block files, and other >>>>> * unknown signature related files (those starting with SIG- with >>>>> * an optional [A-Z0-9]{1,3} extension right inside META-INF). >>>>> * >>>>> * @param name file name >>>>> * @return true if the input file name is signature related >>>>> */ >>>>> public static boolean isSigningRelated(String name) { >>>>> name = name.toUpperCase(Locale.ENGLISH); >>>>> if (!name.startsWith("META-INF/")) { >>>>> return false; >>>>> } >>>>> name = name.substring(9); >>>>> if (name.indexOf('/') != -1) { >>>>> return false; >>>>> } >>>>> if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { >>>>> return true; >>>>> } else if (name.startsWith("SIG-")) { >>>>> // check filename extension >>>>> // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>>> // for what filename extensions are legal >>>>> int extIndex = name.lastIndexOf('.'); >>>>> if (extIndex != -1) { >>>>> String ext = name.substring(extIndex + 1); >>>>> // validate length first >>>>> if (ext.length() > 3 || ext.length() < 1) { >>>>> return false; >>>>> } >>>>> // then check chars, must be in [a-zA-Z0-9] per the jar spec >>>>> for (int index = 0; index < ext.length(); index++) { >>>>> char cc = ext.charAt(index); >>>>> // chars are promoted to uppercase so skip lowercase checks >>>>> if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { >>>>> return false; >>>>> } >>>>> } >>>>> } >>>>> return true; // no extension is OK >>>>> } >>>>> return false; >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: >>>>>> >>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>>> >>>>>>> Thank you. Regarding SIG- I was just followed the spec. >>>>>>> >>>>>> I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. >>>>>> >>>>>> -Alan >>>>> >>>> >>> > From james.laskey at oracle.com Mon Nov 7 14:37:34 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 10:37:34 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> Message-ID: <736211F9-E395-4D73-B056-42E557961B64@oracle.com> It?s the lack of inclusion as oppose to exclusion. > On Nov 7, 2016, at 10:33 AM, Wang Weijun wrote: > > Great. I asked the question because you will need the exact same check to determine what files should be ignored and I thought they should appear in the same webrev. If it's already done somewhere else please make sure it is the same. > > Thanks > Max > >> ? 2016?11?7??22:11?Jim Laskey (Oracle) ??? >> >> The security entries are (have been) ignored when building the image. At some future date (post-9), we need to decide how to sign an image. >> >> ? Jim >> >> >>> On Nov 7, 2016, at 10:06 AM, Wang Weijun wrote: >>> >>> The code block below checking if a jar file was signed is correct. >>> >>> There is one thing I don't understand, the --strip-signing-information option. It looks like you will remove the signature-related files if this option is set. But, where are they stripped? >>> >>> Thanks >>> Max >>> >>>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >>>> Apologies for the poor links earlier. >>>> >>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >>>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>>> >>>> >>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) wrote: >>>>> >>>>> Revising to >>>>> >>>>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>>>> >>>>> return name.startsWith("META-INF/") && name.indexOf('/', 9) == -1 && ( >>>>> name.endsWith(".SF") || >>>>> name.endsWith(".DSA") || >>>>> name.endsWith(".RSA") || >>>>> name.endsWith(".EC") || >>>>> name.startsWith("META-INF/SIG-") >>>>> ); >>>>> >>>>> >>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) wrote: >>>>>> >>>>>> Right. From SignatureFileVerifier.java >>>>>> >>>>>> >>>>>> /** >>>>>> * Utility method used by JarVerifier and JarSigner >>>>>> * to determine the signature file names and PKCS7 block >>>>>> * files names that are supported >>>>>> * >>>>>> * @param s file name >>>>>> * @return true if the input file name is a supported >>>>>> * Signature File or PKCS7 block file name >>>>>> */ >>>>>> public static boolean isBlockOrSF(String s) { >>>>>> // we currently only support DSA and RSA PKCS7 blocks >>>>>> return s.endsWith(".SF") >>>>>> || s.endsWith(".DSA") >>>>>> || s.endsWith(".RSA") >>>>>> || s.endsWith(".EC"); >>>>>> } >>>>>> >>>>>> /** >>>>>> * Yet another utility method used by JarVerifier and JarSigner >>>>>> * to determine what files are signature related, which includes >>>>>> * the MANIFEST, SF files, known signature block files, and other >>>>>> * unknown signature related files (those starting with SIG- with >>>>>> * an optional [A-Z0-9]{1,3} extension right inside META-INF). >>>>>> * >>>>>> * @param name file name >>>>>> * @return true if the input file name is signature related >>>>>> */ >>>>>> public static boolean isSigningRelated(String name) { >>>>>> name = name.toUpperCase(Locale.ENGLISH); >>>>>> if (!name.startsWith("META-INF/")) { >>>>>> return false; >>>>>> } >>>>>> name = name.substring(9); >>>>>> if (name.indexOf('/') != -1) { >>>>>> return false; >>>>>> } >>>>>> if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) { >>>>>> return true; >>>>>> } else if (name.startsWith("SIG-")) { >>>>>> // check filename extension >>>>>> // see http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>>>> // for what filename extensions are legal >>>>>> int extIndex = name.lastIndexOf('.'); >>>>>> if (extIndex != -1) { >>>>>> String ext = name.substring(extIndex + 1); >>>>>> // validate length first >>>>>> if (ext.length() > 3 || ext.length() < 1) { >>>>>> return false; >>>>>> } >>>>>> // then check chars, must be in [a-zA-Z0-9] per the jar spec >>>>>> for (int index = 0; index < ext.length(); index++) { >>>>>> char cc = ext.charAt(index); >>>>>> // chars are promoted to uppercase so skip lowercase checks >>>>>> if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { >>>>>> return false; >>>>>> } >>>>>> } >>>>>> } >>>>>> return true; // no extension is OK >>>>>> } >>>>>> return false; >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman wrote: >>>>>>> >>>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>>>> >>>>>>>> Thank you. Regarding SIG- I was just followed the spec. >>>>>>>> >>>>>>> I hope Sean or Max can jump in on this, the other question is .EC as I believe the JDK allows this when signing too. >>>>>>> >>>>>>> -Alan >>>>>> >>>>> >>>> >> > From sean.mullan at oracle.com Mon Nov 7 16:06:00 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 7 Nov 2016 11:06:00 -0500 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: <1209169F-79FB-4AAB-860E-60078BE0CD30@oracle.com> References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> <1209169F-79FB-4AAB-860E-60078BE0CD30@oracle.com> Message-ID: On 11/7/16 9:13 AM, Jim Laskey (Oracle) wrote: > The bug https://bugs.openjdk.java.net/browse/JDK-8159393 > is really about > warning developers that their image does not support signing. If > they are okay with that then they can override with > --strip-signing-information. I find the option name --strip-signing-information a little bit confusing. To me this implies jlink might remove the signature information from the original signed modular JAR, which is not what you are doing, correct? Why not call it "--ignore-signing-information"? --Sean > > ? Jim > > > >> On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle) >> wrote: >> >> The security entries are (have been) ignored when building the >> image. At some future date (post-9), we need to decide how to sign >> an image. >> >> ? Jim >> >> >>> On Nov 7, 2016, at 10:06 AM, Wang Weijun >>> wrote: >>> >>> The code block below checking if a jar file was signed is >>> correct. >>> >>> There is one thing I don't understand, the >>> --strip-signing-information option. It looks like you will remove >>> the signature-related files if this option is set. But, where are >>> they stripped? >>> >>> Thanks Max >>> >>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >>>> Apologies for the poor links earlier. >>>> >>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >>>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>>> >>>> >>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) >>>>> wrote: >>>>> >>>>> Revising to >>>>> >>>>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>>>> >>>>> return name.startsWith("META-INF/") && name.indexOf('/', 9) >>>>> == -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") || >>>>> name.endsWith(".RSA") || name.endsWith(".EC") || >>>>> name.startsWith("META-INF/SIG-") ); >>>>> >>>>> >>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) >>>>>> wrote: >>>>>> >>>>>> Right. From SignatureFileVerifier.java >>>>>> >>>>>> >>>>>> /** * Utility method used by JarVerifier and JarSigner * to >>>>>> determine the signature file names and PKCS7 block * files >>>>>> names that are supported * * @param s file name * @return >>>>>> true if the input file name is a supported * >>>>>> Signature File or PKCS7 block file name */ public static >>>>>> boolean isBlockOrSF(String s) { // we currently only >>>>>> support DSA and RSA PKCS7 blocks return s.endsWith(".SF") >>>>>> || s.endsWith(".DSA") || s.endsWith(".RSA") || >>>>>> s.endsWith(".EC"); } >>>>>> >>>>>> /** * Yet another utility method used by JarVerifier and >>>>>> JarSigner * to determine what files are signature related, >>>>>> which includes * the MANIFEST, SF files, known signature >>>>>> block files, and other * unknown signature related files >>>>>> (those starting with SIG- with * an optional [A-Z0-9]{1,3} >>>>>> extension right inside META-INF). * * @param name file >>>>>> name * @return true if the input file name is signature >>>>>> related */ public static boolean isSigningRelated(String >>>>>> name) { name = name.toUpperCase(Locale.ENGLISH); if >>>>>> (!name.startsWith("META-INF/")) { return false; } name = >>>>>> name.substring(9); if (name.indexOf('/') != -1) { return >>>>>> false; } if (isBlockOrSF(name) || >>>>>> name.equals("MANIFEST.MF")) { return true; } else if >>>>>> (name.startsWith("SIG-")) { // check filename extension // >>>>>> see >>>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>>>> >>>>>> // for what filename extensions are legal >>>>>> int extIndex = name.lastIndexOf('.'); if (extIndex != -1) >>>>>> { String ext = name.substring(extIndex + 1); // validate >>>>>> length first if (ext.length() > 3 || ext.length() < 1) { >>>>>> return false; } // then check chars, must be in [a-zA-Z0-9] >>>>>> per the jar spec for (int index = 0; index < ext.length(); >>>>>> index++) { char cc = ext.charAt(index); // chars are >>>>>> promoted to uppercase so skip lowercase checks if ((cc < >>>>>> 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return >>>>>> false; } } } return true; // no extension is OK } return >>>>>> false; } >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman >>>>>>> wrote: >>>>>>> >>>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>>>> >>>>>>>> Thank you. Regarding SIG- I was just followed the >>>>>>>> spec. >>>>>>>> >>>>>>> I hope Sean or Max can jump in on this, the other >>>>>>> question is .EC as I believe the JDK allows this when >>>>>>> signing too. >>>>>>> >>>>>>> -Alan >>>>>> >>>>> >>>> >> > From james.laskey at oracle.com Mon Nov 7 16:16:39 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 12:16:39 -0400 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> <1209169F-79FB-4AAB-860E-60078BE0CD30@oracle.com> Message-ID: <5AEFE5BC-DF27-4376-A854-8BF7B74A93CA@oracle.com> Suits me. > On Nov 7, 2016, at 12:06 PM, Sean Mullan wrote: > > On 11/7/16 9:13 AM, Jim Laskey (Oracle) wrote: >> The bug https://bugs.openjdk.java.net/browse/JDK-8159393 >> is really about >> warning developers that their image does not support signing. If >> they are okay with that then they can override with >> --strip-signing-information. > > I find the option name --strip-signing-information a little bit confusing. To me this implies jlink might remove the signature information from the original signed modular JAR, which is not what you are doing, correct? Why not call it "--ignore-signing-information"? > > --Sean > >> >> ? Jim >> >> >> >>> On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle) >>> wrote: >>> >>> The security entries are (have been) ignored when building the >>> image. At some future date (post-9), we need to decide how to sign >>> an image. >>> >>> ? Jim >>> >>> >>>> On Nov 7, 2016, at 10:06 AM, Wang Weijun >>>> wrote: >>>> >>>> The code block below checking if a jar file was signed is >>>> correct. >>>> >>>> There is one thing I don't understand, the >>>> --strip-signing-information option. It looks like you will remove >>>> the signature-related files if this option is set. But, where are >>>> they stripped? >>>> >>>> Thanks Max >>>> >>>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >>>>> Apologies for the poor links earlier. >>>>> >>>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >>>>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>>>> >>>>> >>>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) >>>>>> wrote: >>>>>> >>>>>> Revising to >>>>>> >>>>>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>>>>> >>>>>> return name.startsWith("META-INF/") && name.indexOf('/', 9) >>>>>> == -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") || >>>>>> name.endsWith(".RSA") || name.endsWith(".EC") || >>>>>> name.startsWith("META-INF/SIG-") ); >>>>>> >>>>>> >>>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) >>>>>>> wrote: >>>>>>> >>>>>>> Right. From SignatureFileVerifier.java >>>>>>> >>>>>>> >>>>>>> /** * Utility method used by JarVerifier and JarSigner * to >>>>>>> determine the signature file names and PKCS7 block * files >>>>>>> names that are supported * * @param s file name * @return >>>>>>> true if the input file name is a supported * >>>>>>> Signature File or PKCS7 block file name */ public static >>>>>>> boolean isBlockOrSF(String s) { // we currently only >>>>>>> support DSA and RSA PKCS7 blocks return s.endsWith(".SF") >>>>>>> || s.endsWith(".DSA") || s.endsWith(".RSA") || >>>>>>> s.endsWith(".EC"); } >>>>>>> >>>>>>> /** * Yet another utility method used by JarVerifier and >>>>>>> JarSigner * to determine what files are signature related, >>>>>>> which includes * the MANIFEST, SF files, known signature >>>>>>> block files, and other * unknown signature related files >>>>>>> (those starting with SIG- with * an optional [A-Z0-9]{1,3} >>>>>>> extension right inside META-INF). * * @param name file >>>>>>> name * @return true if the input file name is signature >>>>>>> related */ public static boolean isSigningRelated(String >>>>>>> name) { name = name.toUpperCase(Locale.ENGLISH); if >>>>>>> (!name.startsWith("META-INF/")) { return false; } name = >>>>>>> name.substring(9); if (name.indexOf('/') != -1) { return >>>>>>> false; } if (isBlockOrSF(name) || >>>>>>> name.equals("MANIFEST.MF")) { return true; } else if >>>>>>> (name.startsWith("SIG-")) { // check filename extension // >>>>>>> see >>>>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>>>>> >>>>>>> > // for what filename extensions are legal >>>>>>> int extIndex = name.lastIndexOf('.'); if (extIndex != -1) >>>>>>> { String ext = name.substring(extIndex + 1); // validate >>>>>>> length first if (ext.length() > 3 || ext.length() < 1) { >>>>>>> return false; } // then check chars, must be in [a-zA-Z0-9] >>>>>>> per the jar spec for (int index = 0; index < ext.length(); >>>>>>> index++) { char cc = ext.charAt(index); // chars are >>>>>>> promoted to uppercase so skip lowercase checks if ((cc < >>>>>>> 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return >>>>>>> false; } } } return true; // no extension is OK } return >>>>>>> false; } >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>>>>> >>>>>>>>> Thank you. Regarding SIG- I was just followed the >>>>>>>>> spec. >>>>>>>>> >>>>>>>> I hope Sean or Max can jump in on this, the other >>>>>>>> question is .EC as I believe the JDK allows this when >>>>>>>> signing too. >>>>>>>> >>>>>>>> -Alan >>>>>>> >>>>>> >>>>> >>> >> From sundararajan.athijegannathan at oracle.com Mon Nov 7 16:21:07 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 7 Nov 2016 21:51:07 +0530 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> <1209169F-79FB-4AAB-860E-60078BE0CD30@oracle.com> Message-ID: Looks good to me. PS. jmods, jars are not modified by jlink. Only a new image directory is generated. So, strip-signing-info confusion is unlikely. -Sundar On 11/7/2016 9:36 PM, Sean Mullan wrote: > On 11/7/16 9:13 AM, Jim Laskey (Oracle) wrote: >> The bug https://bugs.openjdk.java.net/browse/JDK-8159393 >> is really about >> warning developers that their image does not support signing. If >> they are okay with that then they can override with >> --strip-signing-information. > > I find the option name --strip-signing-information a little bit > confusing. To me this implies jlink might remove the signature > information from the original signed modular JAR, which is not what > you are doing, correct? Why not call it "--ignore-signing-information"? > > --Sean > >> >> ? Jim >> >> >> >>> On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle) >>> wrote: >>> >>> The security entries are (have been) ignored when building the >>> image. At some future date (post-9), we need to decide how to sign >>> an image. >>> >>> ? Jim >>> >>> >>>> On Nov 7, 2016, at 10:06 AM, Wang Weijun >>>> wrote: >>>> >>>> The code block below checking if a jar file was signed is >>>> correct. >>>> >>>> There is one thing I don't understand, the >>>> --strip-signing-information option. It looks like you will remove >>>> the signature-related files if this option is set. But, where are >>>> they stripped? >>>> >>>> Thanks Max >>>> >>>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >>>>> Apologies for the poor links earlier. >>>>> >>>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >>>>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>>>> >>>>> >>>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) >>>>>> wrote: >>>>>> >>>>>> Revising to >>>>>> >>>>>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>>>>> >>>>>> return name.startsWith("META-INF/") && name.indexOf('/', 9) >>>>>> == -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") || >>>>>> name.endsWith(".RSA") || name.endsWith(".EC") || >>>>>> name.startsWith("META-INF/SIG-") ); >>>>>> >>>>>> >>>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) >>>>>>> wrote: >>>>>>> >>>>>>> Right. From SignatureFileVerifier.java >>>>>>> >>>>>>> >>>>>>> /** * Utility method used by JarVerifier and JarSigner * to >>>>>>> determine the signature file names and PKCS7 block * files >>>>>>> names that are supported * * @param s file name * @return >>>>>>> true if the input file name is a supported * >>>>>>> Signature File or PKCS7 block file name */ public static >>>>>>> boolean isBlockOrSF(String s) { // we currently only >>>>>>> support DSA and RSA PKCS7 blocks return s.endsWith(".SF") >>>>>>> || s.endsWith(".DSA") || s.endsWith(".RSA") || >>>>>>> s.endsWith(".EC"); } >>>>>>> >>>>>>> /** * Yet another utility method used by JarVerifier and >>>>>>> JarSigner * to determine what files are signature related, >>>>>>> which includes * the MANIFEST, SF files, known signature >>>>>>> block files, and other * unknown signature related files >>>>>>> (those starting with SIG- with * an optional [A-Z0-9]{1,3} >>>>>>> extension right inside META-INF). * * @param name file >>>>>>> name * @return true if the input file name is signature >>>>>>> related */ public static boolean isSigningRelated(String >>>>>>> name) { name = name.toUpperCase(Locale.ENGLISH); if >>>>>>> (!name.startsWith("META-INF/")) { return false; } name = >>>>>>> name.substring(9); if (name.indexOf('/') != -1) { return >>>>>>> false; } if (isBlockOrSF(name) || >>>>>>> name.equals("MANIFEST.MF")) { return true; } else if >>>>>>> (name.startsWith("SIG-")) { // check filename extension // >>>>>>> see >>>>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>>>>> >>>>>>> >>>>>>> > // for what filename extensions are legal >>>>>>> int extIndex = name.lastIndexOf('.'); if (extIndex != -1) >>>>>>> { String ext = name.substring(extIndex + 1); // validate >>>>>>> length first if (ext.length() > 3 || ext.length() < 1) { >>>>>>> return false; } // then check chars, must be in [a-zA-Z0-9] >>>>>>> per the jar spec for (int index = 0; index < ext.length(); >>>>>>> index++) { char cc = ext.charAt(index); // chars are >>>>>>> promoted to uppercase so skip lowercase checks if ((cc < >>>>>>> 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return >>>>>>> false; } } } return true; // no extension is OK } return >>>>>>> false; } >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>>>>> >>>>>>>>> Thank you. Regarding SIG- I was just followed the >>>>>>>>> spec. >>>>>>>>> >>>>>>>> I hope Sean or Max can jump in on this, the other >>>>>>>> question is .EC as I believe the JDK allows this when >>>>>>>> signing too. >>>>>>>> >>>>>>>> -Alan >>>>>>> >>>>>> >>>>> >>> >> From sean.mullan at oracle.com Mon Nov 7 16:31:29 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 7 Nov 2016 11:31:29 -0500 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> <0A7593E4-A447-4A42-BA35-C11DCFA1DA34@oracle.com> <1209169F-79FB-4AAB-860E-60078BE0CD30@oracle.com> Message-ID: <64bd4142-45f0-c173-7126-2b2c42e8ada1@oracle.com> On 11/7/16 11:21 AM, Sundararajan Athijegannathan wrote: > Looks good to me. > > PS. jmods, jars are not modified by jlink. Only a new image directory is > generated. So, strip-signing-info confusion is unlikely. I still find it confusing. If I saw that option, I would hesitate to use it until I was sure it would not strip the signature from my JAR file. Best to rename it to avoid confusion. --Sean > > -Sundar > > > On 11/7/2016 9:36 PM, Sean Mullan wrote: >> On 11/7/16 9:13 AM, Jim Laskey (Oracle) wrote: >>> The bug https://bugs.openjdk.java.net/browse/JDK-8159393 >>> is really about >>> warning developers that their image does not support signing. If >>> they are okay with that then they can override with >>> --strip-signing-information. >> >> I find the option name --strip-signing-information a little bit >> confusing. To me this implies jlink might remove the signature >> information from the original signed modular JAR, which is not what >> you are doing, correct? Why not call it "--ignore-signing-information"? >> >> --Sean >> >>> >>> ? Jim >>> >>> >>> >>>> On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle) >>>> wrote: >>>> >>>> The security entries are (have been) ignored when building the >>>> image. At some future date (post-9), we need to decide how to sign >>>> an image. >>>> >>>> ? Jim >>>> >>>> >>>>> On Nov 7, 2016, at 10:06 AM, Wang Weijun >>>>> wrote: >>>>> >>>>> The code block below checking if a jar file was signed is >>>>> correct. >>>>> >>>>> There is one thing I don't understand, the >>>>> --strip-signing-information option. It looks like you will remove >>>>> the signature-related files if this option is set. But, where are >>>>> they stripped? >>>>> >>>>> Thanks Max >>>>> >>>>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote: >>>>>> Apologies for the poor links earlier. >>>>>> >>>>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html >>>>>> https://bugs.openjdk.java.net/browse/JDK-8159393 >>>>>> >>>>>> >>>>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) >>>>>>> wrote: >>>>>>> >>>>>>> Revising to >>>>>>> >>>>>>> String name = entry.name().toUpperCase(Locale.ENGLISH); >>>>>>> >>>>>>> return name.startsWith("META-INF/") && name.indexOf('/', 9) >>>>>>> == -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") || >>>>>>> name.endsWith(".RSA") || name.endsWith(".EC") || >>>>>>> name.startsWith("META-INF/SIG-") ); >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) >>>>>>>> wrote: >>>>>>>> >>>>>>>> Right. From SignatureFileVerifier.java >>>>>>>> >>>>>>>> >>>>>>>> /** * Utility method used by JarVerifier and JarSigner * to >>>>>>>> determine the signature file names and PKCS7 block * files >>>>>>>> names that are supported * * @param s file name * @return >>>>>>>> true if the input file name is a supported * >>>>>>>> Signature File or PKCS7 block file name */ public static >>>>>>>> boolean isBlockOrSF(String s) { // we currently only >>>>>>>> support DSA and RSA PKCS7 blocks return s.endsWith(".SF") >>>>>>>> || s.endsWith(".DSA") || s.endsWith(".RSA") || >>>>>>>> s.endsWith(".EC"); } >>>>>>>> >>>>>>>> /** * Yet another utility method used by JarVerifier and >>>>>>>> JarSigner * to determine what files are signature related, >>>>>>>> which includes * the MANIFEST, SF files, known signature >>>>>>>> block files, and other * unknown signature related files >>>>>>>> (those starting with SIG- with * an optional [A-Z0-9]{1,3} >>>>>>>> extension right inside META-INF). * * @param name file >>>>>>>> name * @return true if the input file name is signature >>>>>>>> related */ public static boolean isSigningRelated(String >>>>>>>> name) { name = name.toUpperCase(Locale.ENGLISH); if >>>>>>>> (!name.startsWith("META-INF/")) { return false; } name = >>>>>>>> name.substring(9); if (name.indexOf('/') != -1) { return >>>>>>>> false; } if (isBlockOrSF(name) || >>>>>>>> name.equals("MANIFEST.MF")) { return true; } else if >>>>>>>> (name.startsWith("SIG-")) { // check filename extension // >>>>>>>> see >>>>>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures >>>>>>>> >>>>>>>> >>>>>>>> >> // for what filename extensions are legal >>>>>>>> int extIndex = name.lastIndexOf('.'); if (extIndex != -1) >>>>>>>> { String ext = name.substring(extIndex + 1); // validate >>>>>>>> length first if (ext.length() > 3 || ext.length() < 1) { >>>>>>>> return false; } // then check chars, must be in [a-zA-Z0-9] >>>>>>>> per the jar spec for (int index = 0; index < ext.length(); >>>>>>>> index++) { char cc = ext.charAt(index); // chars are >>>>>>>> promoted to uppercase so skip lowercase checks if ((cc < >>>>>>>> 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return >>>>>>>> false; } } } return true; // no extension is OK } return >>>>>>>> false; } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote: >>>>>>>>> >>>>>>>>>> Thank you. Regarding SIG- I was just followed the >>>>>>>>>> spec. >>>>>>>>>> >>>>>>>>> I hope Sean or Max can jump in on this, the other >>>>>>>>> question is .EC as I believe the JDK allows this when >>>>>>>>> signing too. >>>>>>>>> >>>>>>>>> -Alan >>>>>>>> >>>>>>> >>>>>> >>>> >>> > From mandy.chung at oracle.com Mon Nov 7 16:58:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 7 Nov 2016 08:58:22 -0800 Subject: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned In-Reply-To: References: <8B5624B0-CC36-4A11-8E1D-F84BFA0D71E3@oracle.com> <494aea68-feed-f66e-a50f-b14d7c1f4486@oracle.com> <9D08A71A-597E-42D8-A2C1-440F05700BB4@oracle.com> Message-ID: <928BAB72-9799-47F4-B399-9A6F3CDE9BB5@oracle.com> > On Nov 7, 2016, at 5:48 AM, Jim Laskey (Oracle) wrote: > > http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html I notice that this webrev has been updated with the new -?ignore-signing-information option, which is fine. The following creates the image with IGNORE_SIGNING_DEFAULT confused me initially. Is the createImage method calling these lines still needed? 256 ImageProvider imageProvider = createImageProvider(finder, 257 config.getModules(), 258 config.getLimitmods(), 259 config.getByteOrder(), 260 null, 261 IGNORE_SIGNING_DEFAULT); 507 System.err.println(taskHelper.getMessage("warn.signing", path)); It?d be good to include ?Warning: ? prefix in the warning message. Perhaps add a new warn method for future use. test/tools/jlink/JLinkSigningTest.java Nit: it?d be good to keep @modules sorted. This test can use java.util.spi.ToolProvider instead of using the internal APIs to invoke javac, jlink etc. See test/tools/jlink/basic/BasicTest.java. Mandy From james.laskey at oracle.com Mon Nov 7 17:43:18 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Nov 2016 13:43:18 -0400 Subject: RFR: JDK-8155756 - Better context for some jlink exceptions Message-ID: <6F49F2E0-282E-40F0-BCFD-982219514BE9@oracle.com> Only 2 of 3 examples still present. http://cr.openjdk.java.net/~jlaskey/8155756/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8155756 From mandy.chung at oracle.com Mon Nov 7 17:52:38 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 7 Nov 2016 09:52:38 -0800 Subject: RFR: JDK-8155756 - Better context for some jlink exceptions In-Reply-To: <6F49F2E0-282E-40F0-BCFD-982219514BE9@oracle.com> References: <6F49F2E0-282E-40F0-BCFD-982219514BE9@oracle.com> Message-ID: > On Nov 7, 2016, at 9:43 AM, Jim Laskey (Oracle) wrote: > > Only 2 of 3 examples still present. > > http://cr.openjdk.java.net/~jlaskey/8155756/webrev/index.html Looks okay to me. Mandy From mandy.chung at oracle.com Mon Nov 7 19:49:18 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Nov 2016 19:49:18 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611071949.uA7JnINq008666@aojmv0008.oracle.com> Changeset: 133257f8d51f Author: redestad Date: 2016-11-07 00:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/133257f8d51f Update SystemModuleDescriptorPlugin to emit provider lists as List.of() Reviewed-by: mchung, alanb ! 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/SystemModulesTest.java Changeset: 78172067c785 Author: mchung Date: 2016-11-07 11:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/78172067c785 Minor cleanup ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java From mandy.chung at oracle.com Mon Nov 7 21:37:43 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Nov 2016 21:37:43 +0000 Subject: hg: jigsaw/jake/jdk: Add qualified opens from java.desktop to jconsole Message-ID: <201611072137.uA7LbinC010185@aojmv0008.oracle.com> Changeset: 7c9c0659c6e0 Author: mchung Date: 2016-11-07 13:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7c9c0659c6e0 Add qualified opens from java.desktop to jconsole ! make/launcher/Launcher-jdk.jconsole.gmk ! src/java.desktop/share/classes/module-info.java From mandy.chung at oracle.com Mon Nov 7 22:52:00 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Nov 2016 22:52:00 +0000 Subject: hg: jigsaw/jake/langtools: 16 new changesets Message-ID: <201611072252.uA7Mq1xd003485@aojmv0008.oracle.com> Changeset: f7187b5fe9e2 Author: rfield Date: 2016-10-24 19:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f7187b5fe9e2 8166649: jshell tool: missing --add-modules and --module-path 8167462: jshell tool: /help /reload is wrong about re-executing commands 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 ! test/jdk/jshell/ToolBasicTest.java Changeset: 32444e1ad88a Author: tbell Date: 2016-10-25 08:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/32444e1ad88a 8168369: fix for langtools intermittent failures needs to check PRODUCT_HOME Reviewed-by: erikj ! test/Makefile Changeset: 18d9a9e14262 Author: sadayapalam Date: 2016-10-26 11:22 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/18d9a9e14262 8166367: Missing ExceptionTable attribute in anonymous class constructors Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/AnonymousClass/AnonymousCtorExceptionTest.java Changeset: a94763e89674 Author: mcimadamore Date: 2016-10-26 12:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a94763e89674 8168134: Inference: javac incorrectly propagating inner constraint with primitive target Summary: Check for propagation doesn't take into account primitive type constraints Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8168134/T8168134.java Changeset: 6a79477df95d Author: mcimadamore Date: 2016-10-26 15:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6a79477df95d 8168774: Polymorhic signature method check crashes javac Summary: Check for polysig method assumes arity is greater than zero Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/meth/BadPolySig.java Changeset: edad5f2365b6 Author: lana Date: 2016-10-27 21:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/edad5f2365b6 Merge Changeset: 6bb6785c2329 Author: rfield Date: 2016-10-27 17:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6bb6785c2329 8167643: JShell: silently ignore access modifiers (as semantically irrelevant) Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! test/jdk/jshell/ClassesTest.java ! test/jdk/jshell/ErrorTranslationTest.java ! test/jdk/jshell/IgnoreTest.java ! test/jdk/jshell/KullaTesting.java ! test/jdk/jshell/MethodsTest.java ! test/jdk/jshell/ModifiersTest.java ! test/jdk/jshell/ToolBasicTest.java Changeset: e0798bbe23da Author: alanb Date: 2016-10-28 10:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e0798bbe23da 8168789: ModuleReader.list and ModuleFinder.of update Reviewed-by: mchung ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java Changeset: 117bd6e52035 Author: mchung Date: 2016-10-31 18:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/117bd6e52035 8167057: jdeps option to list modules and internal APIs for @modules for test dev Reviewed-by: dfuchs ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsFilter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleGraphBuilder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! test/tools/jdeps/lib/JdepsRunner.java + test/tools/jdeps/listdeps/ListModuleDeps.java + test/tools/jdeps/listdeps/src/lib/Lib.java + test/tools/jdeps/listdeps/src/z/Bar.java + test/tools/jdeps/listdeps/src/z/Foo.java + test/tools/jdeps/listdeps/src/z/UseUnsafe.java Changeset: 11ab0f581f11 Author: vromero Date: 2016-11-01 10:14 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/11ab0f581f11 8132562: javac fails with CLASSPATH with double-quotes as an environment variable Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java + test/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java Changeset: 85a8bfb00296 Author: vromero Date: 2016-11-01 10:51 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/85a8bfb00296 8167431: javac takes too long time to resolve interface dependency Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java Changeset: 68754738ba9c Author: smarks Date: 2016-11-01 11:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/68754738ba9c 8165646: (jdeprscan) adjust tool output to improve clarity Reviewed-by: jjg, psandoz ! 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/readme.md ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/scan/Scan.java ! test/tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java Changeset: d44acab5b0ab Author: darcy Date: 2016-11-01 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d44acab5b0ab 8169025: Problem list ClassPathWithDoubleQuotesTest.java until JDK-8169005 is fixed Reviewed-by: ksrini ! test/ProblemList.txt Changeset: 6ef8a1453577 Author: jlahoda Date: 2016-11-02 07:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6ef8a1453577 8131019: jshell tool: access javadoc from tool Summary: Adding internal support to resolve {@inheritDoc} and format javadoc to plain text for use by jdk.jshell and jdk.scripting.nashorn.shell, enhancing Shift- documentation in JShell with ability to show javadoc. Reviewed-by: jjg, rfield ! src/jdk.compiler/share/classes/com/sun/tools/doclint/Entity.java + src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java + src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java + src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! 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/jdk/jshell/JShell.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + test/jdk/internal/shellsupport/doc/JavadocFormatterTest.java + test/jdk/internal/shellsupport/doc/JavadocHelperTest.java ! test/jdk/jshell/CompletionSuggestionTest.java + test/jdk/jshell/JavadocTest.java ! test/jdk/jshell/KullaTesting.java Changeset: eabfa20e38fd Author: lana Date: 2016-11-04 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eabfa20e38fd Added tag jdk-9+143 for changeset 6ef8a1453577 ! .hgtags Changeset: b0d7c4fed00c Author: mchung Date: 2016-11-07 14:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b0d7c4fed00c Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/module-info.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 ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleGraphBuilder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/Makefile ! test/ProblemList.txt ! test/jdk/jshell/CompletionSuggestionTest.java From mandy.chung at oracle.com Mon Nov 7 23:21:57 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Nov 2016 23:21:57 +0000 Subject: hg: jigsaw/jake/nashorn: Add module javadoc to nashorn modules to workaround build error Message-ID: <201611072321.uA7NLv5f012956@aojmv0008.oracle.com> Changeset: 2c70a0485b7c Author: mchung Date: 2016-11-07 15:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2c70a0485b7c Add module javadoc to nashorn modules to workaround build error ! src/jdk.dynalink/share/classes/module-info.java ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/module-info.java From mandy.chung at oracle.com Tue Nov 8 00:10:32 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Nov 2016 00:10:32 +0000 Subject: hg: jigsaw/jake/hotspot: Update jake for the fix for JDK-6479237 Message-ID: <201611080010.uA80AWei027541@aojmv0008.oracle.com> Changeset: 0778dd3211ac Author: mchung Date: 2016-11-07 16:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0778dd3211ac Update jake for the fix for JDK-6479237 ! make/symbols/symbols-unix ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h From mandy.chung at oracle.com Tue Nov 8 00:10:41 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Nov 2016 00:10:41 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611080010.uA80AfmP027802@aojmv0008.oracle.com> Changeset: 2ce9c7477e52 Author: sdrach Date: 2016-10-31 10:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2ce9c7477e52 Add a warning message to jar tool when unexpected entry is found in versioned directory. Reviewed-by: mchung Contributed-by: steve.drach at oracle.com ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Changeset: 20ddc65986b2 Author: mchung Date: 2016-11-07 16:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/20ddc65986b2 Update jake for the fix for JDK-6479237 ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjava/reorder-sparc ! make/mapfiles/libjava/reorder-sparcv9 ! make/mapfiles/libjava/reorder-x86 ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/StackFrameInfo.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/Throwable.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.base/share/native/include/jvm.h - src/java.base/share/native/libjava/StackFrameInfo.c + src/java.base/share/native/libjava/StackTraceElement.c ! src/java.base/share/native/libjava/Throwable.c ! test/java/lang/StackTraceElement/PublicConstructor.java ! test/java/lang/StackTraceElement/SerialTest.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java From sundararajan.athijegannathan at oracle.com Tue Nov 8 03:35:54 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 8 Nov 2016 09:05:54 +0530 Subject: RFR: JDK-8155756 - Better context for some jlink exceptions In-Reply-To: <6F49F2E0-282E-40F0-BCFD-982219514BE9@oracle.com> References: <6F49F2E0-282E-40F0-BCFD-982219514BE9@oracle.com> Message-ID: +1 -Sundar On 11/7/2016 11:13 PM, Jim Laskey (Oracle) wrote: > Only 2 of 3 examples still present. > > http://cr.openjdk.java.net/~jlaskey/8155756/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8155756 > From denis.kononenko at oracle.com Tue Nov 8 13:17:54 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Tue, 8 Nov 2016 05:17:54 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: <260cd370-a550-4403-89a3-6255b6106cbe@default> Hi, The new version of changes. - Switched back to jdk/test/testlibrary to avoid unwanted dependencies (JImageToolTest.java); - Verified tests on smallest possible JDK build. WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 Thank you, Denis. > Denis, > > I can see that you have switched to the top level test library with > this change. With that you are getting more module dependencies than > just java.base. First of all, it would probably make sense to build > only the classes you needed (which would be > jdk.test.lib.process.ProcessTools, I assume), but even if you only > build that, jdk.test.lib.process.ProcessTools has dependencies outside > java.base module. > > You either have to declare @modules in your test or go back to the > jdk/test/lib/testlibrary. Then, of course, unneeded module > dependencies are questionable. > > Shura > > > > On Nov 3, 2016, at 6:29 AM, Denis Kononenko > wrote: > > > > Hi, > > > > I've done some rework accordingly to Alan's and Shura's comments: > > > > 1) removed overlapped tests from JImageToolTest.java; > > > > 2) added new tests JImageVerifyTest.java for jimage verify; > > > > 3) reorganized jtreg's tags; > > > > The new WEBREV can be found here: > http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > > > Thank you, > > Denis. > > > > On 06.10.2016 19:37, Denis Kononenko wrote: > >> Hi, > >> > >> Could someone please review these new tests for jimage utility. > >> > >> There're 5 new files containing tests to cover use cases for > 'info', 'list', 'extract' and other options. No new tests for > 'verify'. > >> > >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > >> > >> > >> Thank you, > >> Denis. > > From erik.joelsson at oracle.com Tue Nov 8 13:40:38 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 08 Nov 2016 13:40:38 +0000 Subject: hg: jigsaw/jake: When importing modules, look in modules_src_jake for jake specific module-info.java files Message-ID: <201611081340.uA8Decvo015881@aojmv0008.oracle.com> Changeset: 07c57a17121e Author: erikj Date: 2016-11-08 14:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/07c57a17121e When importing modules, look in modules_src_jake for jake specific module-info.java files ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! make/Javadoc.gmk From andrey.x.nazarov at oracle.com Tue Nov 8 14:04:55 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 8 Nov 2016 17:04:55 +0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <260cd370-a550-4403-89a3-6255b6106cbe@default> References: <260cd370-a550-4403-89a3-6255b6106cbe@default> Message-ID: <56800DAF-B1AE-4E16-BE85-4566BB067F38@oracle.com> Hi, Looks OK to me. I can suggest two more cases. A directory and file symlink can be passed in options where tool requires a file path. ?Andrey > On 8 Nov 2016, at 16:17, Denis Kononenko wrote: > > > Hi, > > The new version of changes. > > - Switched back to jdk/test/testlibrary to avoid unwanted dependencies (JImageToolTest.java); > - Verified tests on smallest possible JDK build. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > Thank you, > Denis. > >> Denis, >> >> I can see that you have switched to the top level test library with >> this change. With that you are getting more module dependencies than >> just java.base. First of all, it would probably make sense to build >> only the classes you needed (which would be >> jdk.test.lib.process.ProcessTools, I assume), but even if you only >> build that, jdk.test.lib.process.ProcessTools has dependencies outside >> java.base module. >> >> You either have to declare @modules in your test or go back to the >> jdk/test/lib/testlibrary. Then, of course, unneeded module >> dependencies are questionable. >> >> Shura >> >> >>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko >> wrote: >>> >>> Hi, >>> >>> I've done some rework accordingly to Alan's and Shura's comments: >>> >>> 1) removed overlapped tests from JImageToolTest.java; >>> >>> 2) added new tests JImageVerifyTest.java for jimage verify; >>> >>> 3) reorganized jtreg's tags; >>> >>> The new WEBREV can be found here: >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ >>> >>> Thank you, >>> Denis. >>> >>> On 06.10.2016 19:37, Denis Kononenko wrote: >>>> Hi, >>>> >>>> Could someone please review these new tests for jimage utility. >>>> >>>> There're 5 new files containing tests to cover use cases for >> 'info', 'list', 'extract' and other options. No new tests for >> 'verify'. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >>>> >>>> >>>> Thank you, >>>> Denis. >>> From sundararajan.athijegannathan at oracle.com Tue Nov 8 15:08:27 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 8 Nov 2016 20:38:27 +0530 Subject: RFR 8160359: Improve jlink logging for cases when a plugin throws exception Message-ID: <3dd9b26a-8c85-76c8-0636-e2ecec4f8dd8@oracle.com> Please review for http://cr.openjdk.java.net/~sundar/8160359/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8160359 Thanks, -Sundar From claes.redestad at oracle.com Tue Nov 8 15:51:12 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Nov 2016 16:51:12 +0100 Subject: RFR 8160359: Improve jlink logging for cases when a plugin throws exception In-Reply-To: <3dd9b26a-8c85-76c8-0636-e2ecec4f8dd8@oracle.com> References: <3dd9b26a-8c85-76c8-0636-e2ecec4f8dd8@oracle.com> Message-ID: <5821F470.5070702@oracle.com> Hi, I think this looks good as-is, but: Many times I've had the need to enable this kind of logging when building the JDK (as jlink plugins are now essential to creating the standard images), and having to hack the makefiles to add -J-Djlink.debug=true(?) to the right place seems a bit awkward. Should we simply make this added verbosity the default in the build? Thanks! /Claes On 2016-11-08 16:08, Sundararajan Athijegannathan wrote: > Please review for http://cr.openjdk.java.net/~sundar/8160359/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8160359 > > Thanks, > > -Sundar > From erik.joelsson at oracle.com Tue Nov 8 16:01:20 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 08 Nov 2016 16:01:20 +0000 Subject: hg: jigsaw/jake: Parse module-info.java.extra in java build tool instead of makefile Message-ID: <201611081601.uA8G1KcG029342@aojmv0008.oracle.com> Changeset: 9795bd5076ec Author: erikj Date: 2016-11-08 17:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9795bd5076ec Parse module-info.java.extra in java build tool instead of makefile ! make/GensrcModuleInfo.gmk From erik.joelsson at oracle.com Tue Nov 8 16:02:10 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 08 Nov 2016 16:02:10 +0000 Subject: hg: jigsaw/jake/jdk: Parse module-info.java.extra in java build tool instead of makefile Message-ID: <201611081602.uA8G2AUE029669@aojmv0008.oracle.com> Changeset: 65473330550b Author: erikj Date: 2016-11-08 17:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/65473330550b Parse module-info.java.extra in java build tool instead of makefile ! make/src/classes/build/tools/module/GenModuleInfoSource.java From jan.lahoda at oracle.com Tue Nov 8 17:16:31 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 08 Nov 2016 17:16:31 +0000 Subject: hg: jigsaw/jake/langtools: Minor cleanup. Message-ID: <201611081716.uA8HGVqk022394@aojmv0008.oracle.com> Changeset: 2dcedde260f8 Author: jlahoda Date: 2016-11-08 18:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2dcedde260f8 Minor cleanup. ! 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/source/tree/ModuleTree.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/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java From stephan.herrmann at berlin.de Tue Nov 8 18:28:43 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 8 Nov 2016 19:28:43 +0100 Subject: Compiling Java 9 Message-ID: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> I'm wondering what will be expected from a compiler for Java 9. I hope this is a suitable place to ask this kind of questions. The first thing we know: a compiler has to be able to translate module-info.java (or whatever that file's name may be - btw: in absence of a definite rule, is a compiler expected to find module declarations in files of any possible name?). My first question concerns the grammar of module declarations: I don't think the definition of "restricted keywords" and javac speak the same language. The only thing I can definitely infer from lang-vm.html is: restricted keywords are keywords only inside a module declaration (btw: how does the parser know, it's inside a module declaration?). By contrast javac implements a much more permissive strategy, almost s.t. like: "they are only keywords when they are keywords, otherwise they are identifiers". To wit, javac's parser happily accepts this declaration: module module { // second word is an identifier requires requires; // second word is an identifier exports to to exports; // words #2 and #4 are identifiers uses module; // second word is an identifier provides uses with to; // words #2 and #4 are identifiers } This is not only very weird, there are lots of terminals in a module declaration where a restricted keyword is accepted as an identifier. It also breaks with standard compiler technology: it doesn't seem to be possible to use a traditional pipeline of scanner & parser, if the scanner cannot decide the kind of a token without consulting the parser (or keeping part of the parser state in the scanner itself). This is to say: the strategy implemented by javac will affect all tool providers, not only compilers, but also editors etc. In absence of a stateless scanner, even syntax highlighting may not be possible without a full parser. Parsing in the presence of syntax errors (to offer IDE functionality on work-in-progress files) becomes close to impossible. Have these consequences been carefully weighed? The next area where compilers will have to change is the new semantics of "accessible". Clearly, rules like JLS 6.6.1. (Determining Accessibility) and JLS 8.4.8.1. (Overriding (by Instance Methods)) need to be changed. Has any of this work started yet? Can we have a look at any drafts? Next, I wonder, how much additional static validation compilers should perform. For one, SOTMS speaks of "reliable configurations". Are compilers expected to check these rules? If so, have they been spelled out in checkable form somewhere (e.g., what is the meaning of "interfere" in the sentence "modules defining identically-named packages do not interfere with each other")? Secondly, the concept of modules makes it possible to create new forms of "API leaks": expose a type, whose public signatures mention inaccessible types - maybe inaccessible only to some consumers. If you add overloading to the mix, this can create ugly effects, which may defeat benefits of modularity. Is it planned that tools will help users to avoid such bogus situations? Or at least gracefully handle the case when it occurs? Obviously, some validity constraints can be checked by tools other than the compiler, like linker or VM, but defining a module system as part of the language bears the unique opportunity to provide the most immediate feedback to users. Will this opportunity be used? Other concerns are more of an organizational kind: What modules must be present to compile a given module? Is the set of (implied) readable dependencies sufficient, or is the compiler required to look at the full transitive closure? Users coming from a plain-classpath world, may not expect much sophistication, but introducing a module system bears the unique opportunity to avoid the situation where building just one module triggers the download of huge amounts of transitive dependencies ("downloading the internet"). Which is to say: Java 9 has the chance to significantly reduce the resource requirements (bandwidth, storage, main memory, compile time) for compiling any given module. Any attempts in this direction seem to require a fresh look specifically at the interaction of accessibility and overloading. Has anything been planned/discussed in this direction? In Java 8, any package-qualified type name is sufficient for identifying a type during compilation. Will the same assumption also hold for compiling Java 9, or is a compiler required to distinguish identically named types from different modules? While this seems to be a question of compiler implementation only, it also seems the answer depends on answering most of the above questions, like additional static validation, the need to look at the transitive closure of module dependencies etc. Most importantly, for implementing a compiler for Java 9 this question implies a very fundamental design decision, that should be made before any other changes towards Java 9. Changing a compiler implementation from package.type names to module.package.type names is a huge change that cannot be implemented as a quick after thought. Have any amendments to JLS chapter 6 been drafted to define the new requirements for a compiler regarding qualified names? regards, Stephan From mandy.chung at oracle.com Tue Nov 8 20:00:42 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Nov 2016 20:00:42 +0000 Subject: hg: jigsaw/jake/jdk: Update GenModuleInfoSource to filter qualified exports/open for known modules Message-ID: <201611082000.uA8K0gP4011328@aojmv0008.oracle.com> Changeset: 8cb1876c41b8 Author: mchung Date: 2016-11-08 11:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8cb1876c41b8 Update GenModuleInfoSource to filter qualified exports/open for known modules ! make/src/classes/build/tools/module/GenModuleInfoSource.java ! src/jdk.jdi/windows/classes/module-info.java.extra From mandy.chung at oracle.com Tue Nov 8 20:42:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Nov 2016 12:42:22 -0800 Subject: RFR 8160359: Improve jlink logging for cases when a plugin throws exception In-Reply-To: <5821F470.5070702@oracle.com> References: <3dd9b26a-8c85-76c8-0636-e2ecec4f8dd8@oracle.com> <5821F470.5070702@oracle.com> Message-ID: <025424AE-A7FE-4492-97A1-E43A3BA83ACA@oracle.com> Sundar, Have you considered for plugins to throw different type of exceptions to differentiate if jlink should gracefully exit with no stack trace. For example if it?s an user-error e.g. invalid option or duplicated entries then jlink can simply print the error message. For unexpected error such as IOException, the stack trace would be useful for troubleshooting. Mandy On Nov 8, 2016, at 7:51 AM, Claes Redestad wrote: > > Hi, > > I think this looks good as-is, but: > > Many times I've had the need to enable this kind of logging when > building the JDK (as jlink plugins are now essential to creating the > standard images), and having to hack the makefiles to add > -J-Djlink.debug=true(?) to the right place seems a bit awkward. > > Should we simply make this added verbosity the default in the build? > > Thanks! > > /Claes > > On 2016-11-08 16:08, Sundararajan Athijegannathan wrote: >> Please review for http://cr.openjdk.java.net/~sundar/8160359/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8160359 >> >> Thanks, >> >> -Sundar >> From mandy.chung at oracle.com Tue Nov 8 22:14:55 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Nov 2016 22:14:55 +0000 Subject: hg: jigsaw/jake/jdk: test/sun/security/krb5/tools/KtabZero.java failing Message-ID: <201611082214.uA8MEtcZ015556@aojmv0008.oracle.com> Changeset: ad992df4769b Author: mchung Date: 2016-11-08 14:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ad992df4769b test/sun/security/krb5/tools/KtabZero.java failing ! test/sun/security/krb5/tools/KtabZero.java From mandy.chung at oracle.com Tue Nov 8 22:18:22 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Nov 2016 22:18:22 +0000 Subject: hg: jigsaw/jake/langtools: Fix test/jdk/jshell/JavadocTest.java failing Message-ID: <201611082218.uA8MIMnS016606@aojmv0008.oracle.com> Changeset: 77b8374f80e8 Author: mchung Date: 2016-11-08 14:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/77b8374f80e8 Fix test/jdk/jshell/JavadocTest.java failing ! test/jdk/jshell/JavadocTest.java From sundararajan.athijegannathan at oracle.com Wed Nov 9 03:43:47 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 9 Nov 2016 09:13:47 +0530 Subject: RFR 8160359: Improve jlink logging for cases when a plugin throws exception In-Reply-To: <025424AE-A7FE-4492-97A1-E43A3BA83ACA@oracle.com> References: <3dd9b26a-8c85-76c8-0636-e2ecec4f8dd8@oracle.com> <5821F470.5070702@oracle.com> <025424AE-A7FE-4492-97A1-E43A3BA83ACA@oracle.com> Message-ID: <1187bee2-a128-5eb5-c21c-2c425adb5366@oracle.com> Mandy, The exceptions caught are propagated to caller - JlinkTask - which does print getMessage from exception and exits. So, if a plugin throws illegal argument exception from "configure", jlink will print message and exit - as expected. Catching PluginException (and IllegalArgumentException in the case of configure) at precise location is a debugging aid. Plugin name, actual arguments map passed are dumped in addition to stack trace - only if system property is defined. -Sundar On 11/9/2016 2:12 AM, Mandy Chung wrote: > Sundar, > > Have you considered for plugins to throw different type of exceptions to differentiate if jlink should gracefully exit with no stack trace. For example if it?s an user-error e.g. invalid option or duplicated entries then jlink can simply print the error message. > > For unexpected error such as IOException, the stack trace would be useful for troubleshooting. > > Mandy > > On Nov 8, 2016, at 7:51 AM, Claes Redestad wrote: >> Hi, >> >> I think this looks good as-is, but: >> >> Many times I've had the need to enable this kind of logging when >> building the JDK (as jlink plugins are now essential to creating the >> standard images), and having to hack the makefiles to add >> -J-Djlink.debug=true(?) to the right place seems a bit awkward. >> >> Should we simply make this added verbosity the default in the build? >> >> Thanks! >> >> /Claes >> >> On 2016-11-08 16:08, Sundararajan Athijegannathan wrote: >>> Please review for http://cr.openjdk.java.net/~sundar/8160359/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8160359 >>> >>> Thanks, >>> >>> -Sundar >>> From sean.coffey at oracle.com Wed Nov 9 13:25:55 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 9 Nov 2016 13:25:55 +0000 Subject: RFR 8160359: Improve jlink logging for cases when a plugin throws exception In-Reply-To: <1187bee2-a128-5eb5-c21c-2c425adb5366@oracle.com> References: <3dd9b26a-8c85-76c8-0636-e2ecec4f8dd8@oracle.com> <5821F470.5070702@oracle.com> <025424AE-A7FE-4492-97A1-E43A3BA83ACA@oracle.com> <1187bee2-a128-5eb5-c21c-2c425adb5366@oracle.com> Message-ID: <582323E3.2070708@oracle.com> I'm wondering if we could improve the information provided in the exception message. I don't think end users should have to turn on debug flags in all scenarios if the information could easily be inserted into the exception message. e.g. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java > if (JlinkTask.DEBUG) { > + System.err.println("IOException while reading resource: " + res.path()); > ex.printStackTrace(); > } > throw new PluginException(ex); Why not move this new message to the non-debug code ? + throw new PluginException("IOException while reading resource: " + res.path(), ex); On the other hand, some messages might be deemed too verbose for exception message inclusion. Do end users mind how large an exception message is ? e.g src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java + System.err.println("Plugin " + plugin.getName() + " threw exception with config: " + config); Including the config Map in an exception message might be deemed overkill for above. Regards, Sean. On 09/11/16 03:43, Sundararajan Athijegannathan wrote: > Mandy, > > The exceptions caught are propagated to caller - JlinkTask - which does > print getMessage from exception and exits. So, if a plugin throws > illegal argument exception from "configure", jlink will print message > and exit - as expected. > > Catching PluginException (and IllegalArgumentException in the case of > configure) at precise location is a debugging aid. Plugin name, actual > arguments map passed are dumped in addition to stack trace - only if > system property is defined. > > -Sundar > > > On 11/9/2016 2:12 AM, Mandy Chung wrote: >> Sundar, >> >> Have you considered for plugins to throw different type of exceptions to differentiate if jlink should gracefully exit with no stack trace. For example if it?s an user-error e.g. invalid option or duplicated entries then jlink can simply print the error message. >> >> For unexpected error such as IOException, the stack trace would be useful for troubleshooting. >> >> Mandy >> >> On Nov 8, 2016, at 7:51 AM, Claes Redestad wrote: >>> Hi, >>> >>> I think this looks good as-is, but: >>> >>> Many times I've had the need to enable this kind of logging when >>> building the JDK (as jlink plugins are now essential to creating the >>> standard images), and having to hack the makefiles to add >>> -J-Djlink.debug=true(?) to the right place seems a bit awkward. >>> >>> Should we simply make this added verbosity the default in the build? >>> >>> Thanks! >>> >>> /Claes >>> >>> On 2016-11-08 16:08, Sundararajan Athijegannathan wrote: >>>> Please review for http://cr.openjdk.java.net/~sundar/8160359/webrev.00/ >>>> for https://bugs.openjdk.java.net/browse/JDK-8160359 >>>> >>>> Thanks, >>>> >>>> -Sundar >>>> From jan.lahoda at oracle.com Wed Nov 9 14:11:47 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 09 Nov 2016 14:11:47 +0000 Subject: hg: jigsaw/jake/langtools: Cleanup of deprecation warnings on modules in qualified exports. Message-ID: <201611091411.uA9EBllk013478@aojmv0008.oracle.com> Changeset: 1b2b41b41d73 Author: jlahoda Date: 2016-11-09 15:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1b2b41b41d73 Cleanup of deprecation warnings on modules in qualified exports. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.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 ! test/tools/javac/modules/AnnotationsOnModules.java From jan.lahoda at oracle.com Wed Nov 9 14:12:50 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 09 Nov 2016 14:12:50 +0000 Subject: hg: jigsaw/jake/jdk: Cleanup of deprecation warnings on modules in qualified exports, adjusting j.l.Deprecated javadoc. Message-ID: <201611091412.uA9ECoG4013788@aojmv0008.oracle.com> Changeset: a413852e34a8 Author: jlahoda Date: 2016-11-09 15:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a413852e34a8 Cleanup of deprecation warnings on modules in qualified exports, adjusting j.l.Deprecated javadoc. ! src/java.base/share/classes/java/lang/Deprecated.java ! src/java.base/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java From denis.kononenko at oracle.com Wed Nov 9 17:36:28 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Wed, 9 Nov 2016 09:36:28 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: Hi, After discussion with Andrey we decided to add more tests for corner cases. The new changes are available by the link below. WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 Thank you, Denis. > Hi, > > Looks OK to me. > I can suggest two more cases. A directory and file symlink can be > passed in options where tool requires a file path. > > ?Andrey > > > On 8 Nov 2016, at 16:17, Denis Kononenko > wrote: > > > > > > Hi, > > > > The new version of changes. > > > > - Switched back to jdk/test/testlibrary to avoid unwanted > dependencies (JImageToolTest.java); > > - Verified tests on smallest possible JDK build. > > > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > > Thank you, > > Denis. > > > >> Denis, > >> > >> I can see that you have switched to the top level test library > with > >> this change. With that you are getting more module dependencies > than > >> just java.base. First of all, it would probably make sense to > build > >> only the classes you needed (which would be > >> jdk.test.lib.process.ProcessTools, I assume), but even if you only > >> build that, jdk.test.lib.process.ProcessTools has dependencies > outside > >> java.base module. > >> > >> You either have to declare @modules in your test or go back to the > >> jdk/test/lib/testlibrary. Then, of course, unneeded module > >> dependencies are questionable. > >> > >> Shura > >> > >> > >>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko > >> wrote: > >>> > >>> Hi, > >>> > >>> I've done some rework accordingly to Alan's and Shura's comments: > >>> > >>> 1) removed overlapped tests from JImageToolTest.java; > >>> > >>> 2) added new tests JImageVerifyTest.java for jimage verify; > >>> > >>> 3) reorganized jtreg's tags; > >>> > >>> The new WEBREV can be found here: > >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > >>> > >>> Thank you, > >>> Denis. > >>> > >>> On 06.10.2016 19:37, Denis Kononenko wrote: > >>>> Hi, > >>>> > >>>> Could someone please review these new tests for jimage utility. > >>>> > >>>> There're 5 new files containing tests to cover use cases for > >> 'info', 'list', 'extract' and other options. No new tests for > >> 'verify'. > >>>> > >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >>>> WEBREV: > http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > >>>> > >>>> > >>>> Thank you, > >>>> Denis. > >>> From mandy.chung at oracle.com Wed Nov 9 17:57:26 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Nov 2016 17:57:26 +0000 Subject: hg: jigsaw/jake/jaxws: open classes passed to JAXB context for deep reflection Message-ID: <201611091757.uA9HvQPw011166@aojmv0008.oracle.com> Changeset: 6afd825302f0 Author: mchung Date: 2016-11-09 09:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/6afd825302f0 open classes passed to JAXB context for deep reflection ! src/java.xml.ws/share/classes/module-info.java From andrey.x.nazarov at oracle.com Wed Nov 9 18:55:24 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 9 Nov 2016 21:55:24 +0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: References: Message-ID: <4D19CF54-3CFA-41A3-A3AA-32DC7694F6E5@oracle.com> Hi, Looks OK. Is it 100% pass rate? ?Andrey > On 9 Nov 2016, at 20:36, Denis Kononenko wrote: > > > > Hi, > > After discussion with Andrey we decided to add more tests for corner cases. > The new changes are available by the link below. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > Thank you, > Denis. > >> Hi, >> >> Looks OK to me. >> I can suggest two more cases. A directory and file symlink can be >> passed in options where tool requires a file path. >> >> ?Andrey >> >>> On 8 Nov 2016, at 16:17, Denis Kononenko >> wrote: >>> >>> >>> Hi, >>> >>> The new version of changes. >>> >>> - Switched back to jdk/test/testlibrary to avoid unwanted >> dependencies (JImageToolTest.java); >>> - Verified tests on smallest possible JDK build. >>> >>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>> >>> Thank you, >>> Denis. >>> >>>> Denis, >>>> >>>> I can see that you have switched to the top level test library >> with >>>> this change. With that you are getting more module dependencies >> than >>>> just java.base. First of all, it would probably make sense to >> build >>>> only the classes you needed (which would be >>>> jdk.test.lib.process.ProcessTools, I assume), but even if you only >>>> build that, jdk.test.lib.process.ProcessTools has dependencies >> outside >>>> java.base module. >>>> >>>> You either have to declare @modules in your test or go back to the >>>> jdk/test/lib/testlibrary. Then, of course, unneeded module >>>> dependencies are questionable. >>>> >>>> Shura >>>> >>>> >>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've done some rework accordingly to Alan's and Shura's comments: >>>>> >>>>> 1) removed overlapped tests from JImageToolTest.java; >>>>> >>>>> 2) added new tests JImageVerifyTest.java for jimage verify; >>>>> >>>>> 3) reorganized jtreg's tags; >>>>> >>>>> The new WEBREV can be found here: >>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ >>>>> >>>>> Thank you, >>>>> Denis. >>>>> >>>>> On 06.10.2016 19:37, Denis Kononenko wrote: >>>>>> Hi, >>>>>> >>>>>> Could someone please review these new tests for jimage utility. >>>>>> >>>>>> There're 5 new files containing tests to cover use cases for >>>> 'info', 'list', 'extract' and other options. No new tests for >>>> 'verify'. >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>>>> WEBREV: >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >>>>>> >>>>>> >>>>>> Thank you, >>>>>> Denis. >>>>> From jan.lahoda at oracle.com Wed Nov 9 20:20:51 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 09 Nov 2016 20:20:51 +0000 Subject: hg: jigsaw/jake/langtools: Correcting reading of module-info.class with annotation with non-primitive attributes. Message-ID: <201611092020.uA9KKpm8024281@aojmv0008.oracle.com> Changeset: b3e533ec494a Author: jlahoda Date: 2016-11-09 21:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b3e533ec494a Correcting reading of module-info.class with annotation with non-primitive attributes. ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/tools/javac/modules/AnnotationsOnModules.java From denis.kononenko at oracle.com Thu Nov 10 10:40:57 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Thu, 10 Nov 2016 02:40:57 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: <4c733bd0-ecb3-4cb9-9521-df943becd146@default> Hi Andrey, No, it isn't. I submitted a new CR: https://bugs.openjdk.java.net/browse/JDK-8167384. Thank you, Denis. > Hi, > > Looks OK. Is it 100% pass rate? > > ?Andrey > > On 9 Nov 2016, at 20:36, Denis Kononenko > wrote: > > > > > > > > Hi, > > > > After discussion with Andrey we decided to add more tests for corner > cases. > > The new changes are available by the link below. > > > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > > > > Thank you, > > Denis. > > > >> Hi, > >> > >> Looks OK to me. > >> I can suggest two more cases. A directory and file symlink can be > >> passed in options where tool requires a file path. > >> > >> ?Andrey > >> > >>> On 8 Nov 2016, at 16:17, Denis Kononenko > >> wrote: > >>> > >>> > >>> Hi, > >>> > >>> The new version of changes. > >>> > >>> - Switched back to jdk/test/testlibrary to avoid unwanted > >> dependencies (JImageToolTest.java); > >>> - Verified tests on smallest possible JDK build. > >>> > >>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >>> > >>> Thank you, > >>> Denis. > >>> > >>>> Denis, > >>>> > >>>> I can see that you have switched to the top level test library > >> with > >>>> this change. With that you are getting more module dependencies > >> than > >>>> just java.base. First of all, it would probably make sense to > >> build > >>>> only the classes you needed (which would be > >>>> jdk.test.lib.process.ProcessTools, I assume), but even if you > only > >>>> build that, jdk.test.lib.process.ProcessTools has dependencies > >> outside > >>>> java.base module. > >>>> > >>>> You either have to declare @modules in your test or go back to > the > >>>> jdk/test/lib/testlibrary. Then, of course, unneeded module > >>>> dependencies are questionable. > >>>> > >>>> Shura > >>>> > >>>> > >>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I've done some rework accordingly to Alan's and Shura's > comments: > >>>>> > >>>>> 1) removed overlapped tests from JImageToolTest.java; > >>>>> > >>>>> 2) added new tests JImageVerifyTest.java for jimage verify; > >>>>> > >>>>> 3) reorganized jtreg's tags; > >>>>> > >>>>> The new WEBREV can be found here: > >>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > >>>>> > >>>>> Thank you, > >>>>> Denis. > >>>>> > >>>>> On 06.10.2016 19:37, Denis Kononenko wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Could someone please review these new tests for jimage > utility. > >>>>>> > >>>>>> There're 5 new files containing tests to cover use cases for > >>>> 'info', 'list', 'extract' and other options. No new tests for > >>>> 'verify'. > >>>>>> > >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >>>>>> WEBREV: > >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > >>>>>> > >>>>>> > >>>>>> Thank you, > >>>>>> Denis. > >>>>> From mandy.chung at oracle.com Thu Nov 10 22:34:28 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Nov 2016 22:34:28 +0000 Subject: hg: jigsaw/jake: 7 new changesets Message-ID: <201611102234.uAAMYSuR009468@aojmv0008.oracle.com> Changeset: bf83e4c950e0 Author: rfield Date: 2016-11-02 16:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/bf83e4c950e0 8168974: Editor support: include properties file in image Reviewed-by: jlahoda ! make/CompileJavaModules.gmk Changeset: fe1e5f27b071 Author: alexsch Date: 2016-11-01 12:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/fe1e5f27b071 8167176: Exported elements referring to inaccessible types in java.desktop Reviewed-by: prr, serb ! make/CompileJavaModules.gmk Changeset: e41be20156e6 Author: ddehaven Date: 2016-11-03 13:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e41be20156e6 Merge ! make/CompileJavaModules.gmk Changeset: 1beb4d0e537a Author: lana Date: 2016-11-04 17:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1beb4d0e537a Merge Changeset: 9ae47deec185 Author: erikj Date: 2016-11-07 13:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9ae47deec185 8168108: lib/classlist should be packaged in java.base.jmod Reviewed-by: mchung ! common/autoconf/spec.gmk.in ! make/CreateJmods.gmk + make/GenerateLinkOptData.gmk ! make/Images.gmk ! make/InterimImage.gmk ! make/Main.gmk Changeset: 8d337fd6333e Author: erikj Date: 2016-11-07 14:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8d337fd6333e 8160491: tar.gz bundles missing files containing $ Reviewed-by: ihse ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! make/Bundles.gmk ! make/Images.gmk ! make/common/MakeBase.gmk ! test/make/TestJavaCompilation.gmk ! test/make/TestMakeBase.gmk Changeset: 08410c9350a0 Author: mchung Date: 2016-11-10 14:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/08410c9350a0 Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/CompileJavaModules.gmk ! make/CreateJmods.gmk ! make/Images.gmk ! make/Main.gmk ! make/common/MakeBase.gmk ! test/make/TestJavaCompilation.gmk From mandy.chung at oracle.com Thu Nov 10 22:34:43 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Nov 2016 22:34:43 +0000 Subject: hg: jigsaw/jake/hotspot: 3 new changesets Message-ID: <201611102234.uAAMYhln009568@aojmv0008.oracle.com> Changeset: 48fce55afe71 Author: mchung Date: 2016-11-03 18:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/48fce55afe71 6479237: (cl) Add support for classloader names Reviewed-by: alanb, bchristi, coleenp, dfuchs, lfoltan, psandoz, sspitsyn ! make/symbols/symbols-unix ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 6187b582d02a Author: lana Date: 2016-11-04 17:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6187b582d02a Merge Changeset: 7b3e1ec5ac47 Author: mchung Date: 2016-11-10 14:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7b3e1ec5ac47 Merge ! make/symbols/symbols-unix ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h - test/runtime/modules/JVMCanReadModule.java - test/runtime/modules/JVMIsExportedToModule.java From mandy.chung at oracle.com Thu Nov 10 22:36:59 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Nov 2016 22:36:59 +0000 Subject: hg: jigsaw/jake/jdk: 40 new changesets Message-ID: <201611102237.uAAMb0nv010304@aojmv0008.oracle.com> Changeset: 0fa4b5647f3e Author: igerasim Date: 2016-11-02 18:45 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0fa4b5647f3e 8168923: Use unsigned random long in a temp directory name Reviewed-by: bpb, alanb ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/nio/file/TempFileHelper.java Changeset: 50dd63d47f2d Author: igerasim Date: 2016-11-02 20:53 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/50dd63d47f2d 8168921: Inconsistent Annotation.toString() Reviewed-by: darcy, redestad ! src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! test/java/lang/annotation/AnnotationToStringTest.java Changeset: 88d82306b232 Author: rriggs Date: 2016-11-02 13:42 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88d82306b232 8158963: RMI server-side multiplex protocol should be disabled Summary: add sun.rmi.transport.tcp.enableMultiplexProtocol to enable RMI multiplex protocol Reviewed-by: smarks ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPTransport.java Changeset: 1396fb6d0279 Author: rfield Date: 2016-11-02 16:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1396fb6d0279 8168972: Editor support: move built-in and external editor support to the jdk repo 8167639: jshell tool: Edit Pad has readability issues Reviewed-by: jlahoda + src/jdk.editpad/share/classes/jdk/editpad/EditPad.java + src/jdk.editpad/share/classes/jdk/editpad/EditPadProvider.java + src/jdk.editpad/share/classes/jdk/editpad/resources/l10n.properties + src/jdk.editpad/share/classes/module-info.java + src/jdk.internal.ed/share/classes/jdk/internal/editor/external/ExternalEditor.java + src/jdk.internal.ed/share/classes/jdk/internal/editor/spi/BuildInEditorProvider.java + src/jdk.internal.ed/share/classes/module-info.java + test/jdk/editpad/EditPadTest.java Changeset: feca8d2621c0 Author: amlu Date: 2016-11-03 09:44 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/feca8d2621c0 8151511: Test case in CollectionAndMapModifyStreamTest for LinkedHashMap overrides that for HashMap Reviewed-by: chegar, psandoz - test/java/util/stream/bootlib/java.base/java/util/stream/ThowableHelper.java + test/java/util/stream/bootlib/java.base/java/util/stream/ThrowableHelper.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectAndSummaryStatisticsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IterateTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamCloseTest.java Changeset: fa69be51bf46 Author: xiaofeya Date: 2016-11-02 18:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa69be51bf46 8156504: java/net/URLPermission/nstest/lookup.sh fails intermittently Reviewed-by: chegar, dfuchs ! test/java/net/URLPermission/nstest/LookupTest.java - test/java/net/URLPermission/nstest/lookup.sh Changeset: 742e99d3aa32 Author: amlu Date: 2016-11-03 15:40 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/742e99d3aa32 8143097: java/net/ipv6tests/UdpTest.java fails intermittently with "checkTime failed: got 1998 expected 4000" Reviewed-by: chegar ! test/java/net/ipv6tests/Tests.java ! test/java/net/ipv6tests/UdpTest.java Changeset: b5c6cc183ebb Author: rriggs Date: 2016-11-03 12:29 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b5c6cc183ebb 8169055: [TESTBUG] java/io/Serializable/serialFilter/ tests have undeclared dependency on java.compiler module Summary: Change serialFilter test to use type in java.base Reviewed-by: dfuchs, chegar, skovalev ! test/java/io/Serializable/serialFilter/SerialFilterTest.java Changeset: 90dd858e9303 Author: lancea Date: 2016-11-03 13:34 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/90dd858e9303 8169020: Add since element to JDBC deprecated methods Reviewed-by: darcy ! src/java.sql/share/classes/java/sql/CallableStatement.java ! src/java.sql/share/classes/java/sql/Date.java ! src/java.sql/share/classes/java/sql/DriverManager.java ! src/java.sql/share/classes/java/sql/PreparedStatement.java ! src/java.sql/share/classes/java/sql/ResultSet.java ! src/java.sql/share/classes/java/sql/Time.java ! src/java.sql/share/classes/java/sql/Timestamp.java Changeset: 7c61ce6d7852 Author: skovalev Date: 2016-11-03 16:19 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7c61ce6d7852 8169002: Several java/net/httpclient have undeclared dependency on java.logging module Reviewed-by: chegar, rriggs, dfuchs ! test/java/net/httpclient/APIErrors.java ! test/java/net/httpclient/ManyRequests.java ! test/java/net/httpclient/RequestBodyTest.java ! test/java/net/httpclient/SmokeTest.java ! test/java/net/httpclient/security/Driver.java ! test/java/net/httpclient/security/Security.java Changeset: 52d732262bfa Author: darcy Date: 2016-11-03 13:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/52d732262bfa 8168681: Correct deprecation text for Class.newInstance Reviewed-by: mchung ! src/java.base/share/classes/java/lang/Class.java Changeset: aae3690e53e3 Author: avstepan Date: 2016-10-20 14:21 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aae3690e53e3 8159454: [TEST_BUG] javax/swing/ToolTipManager/7123767/bug7123767.java: number of checked graphics configurations should be limited Reviewed-by: serb, yan ! test/javax/swing/ToolTipManager/7123767/bug7123767.java Changeset: c505e725b85b Author: bpb Date: 2016-10-24 13:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c505e725b85b 8168498: ExifGPSTagSet and ExifTIFFTagSet should use string literals for String constants Summary: Change new String(byte[],CharSet) to a string literal. Reviewed-by: prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java Changeset: 96153792172a Author: prr Date: 2016-10-25 09:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96153792172a 8168288: Dubious FontMetrics values from NullFontScaler Reviewed-by: serb, bpb ! src/java.desktop/share/classes/sun/font/NullFontScaler.java Changeset: 4a8fee1f2953 Author: prr Date: 2016-10-25 10:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a8fee1f2953 8168364: [macosx] Delete unused class NSPrintinfo Reviewed-by: serb, vadim ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java - src/java.desktop/macosx/classes/sun/lwawt/macosx/NSPrintInfo.java Changeset: e54829fa51a3 Author: bpb Date: 2016-10-25 17:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e54829fa51a3 8168367: Table in javax.imageio package description does not mention TIFF Summary: Add row for TIFF and reorder rows into alphabetical order by format Reviewed-by: jdv, prr ! src/java.desktop/share/classes/javax/imageio/package.html Changeset: 544828ab2a9b Author: aghaisas Date: 2016-10-26 10:51 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/544828ab2a9b 8168470: [TEST_BUG] @test missed in java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java Reviewed-by: serb, ssadetsky, arapte ! test/java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java Changeset: eeb8b31afed6 Author: pkbalakr Date: 2016-10-27 10:49 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eeb8b31afed6 8168292: [TESTBUG] [macosx] Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X Reviewed-by: psadhukhan, aghaisas ! test/java/awt/TrayIcon/DragEventSource/DragEventSource.java Changeset: b82c04707671 Author: psadhukhan Date: 2016-10-27 17:24 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b82c04707671 8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. Reviewed-by: prr, jdv ! src/java.desktop/macosx/classes/sun/java2d/OSXSurfaceData.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m + test/java/awt/print/PrinterJob/LinearGradientPrintingTest.java + test/java/awt/print/PrinterJob/RadialGradientPrintingTest.java Changeset: 807349334f32 Author: bpb Date: 2016-10-27 09:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/807349334f32 8165981: Consider making some classes in javax.imageio.plugins.tiff final Summary: Make the classes TIFFField and TIFFImageReadParam final. Reviewed-by: serb, prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFImageReadParam.java Changeset: 3bf26b1c7c7e Author: prr Date: 2016-10-27 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bf26b1c7c7e Merge - src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java - src/java.base/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java - src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java - src/java.base/windows/native/libnet/icmp.h - test/sun/net/www/protocol/https/HttpsClient/OriginServer.java - test/sun/reflect/ReflectionFactory/NewConstructorForSerialization.java - test/sun/security/tools/jarsigner/ts.sh Changeset: 6e8788feb253 Author: jdv Date: 2016-10-28 12:23 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e8788feb253 8168609: No link to BMP specification in javax.imageio package documentation Reviewed-by: prr, bpb ! src/java.desktop/share/classes/javax/imageio/package.html Changeset: 22c146c486ca Author: ssadetsky Date: 2016-10-28 12:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/22c146c486ca 8075904: The regression-swing case failed as Ctrl-F4 can't work with the special options"-client -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel" Reviewed-by: alexsch, serb ! src/java.desktop/share/classes/sun/swing/plaf/GTKKeybindings.java Changeset: 329b1a617404 Author: aniyogi Date: 2016-10-31 12:10 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/329b1a617404 8168540: [TEST_BUG] On Unity, need a delay before screenshot taking to avoid animation Reviewed-by: psadhukhan, yan ! test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 5445b9413d9d Author: serb Date: 2016-10-31 14:50 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5445b9413d9d 8167615: Opensource unit/regression tests for JavaSound Reviewed-by: amenkov ! test/ProblemList.txt + test/javax/sound/midi/Devices/ClosedReceiver.java + test/javax/sound/midi/Devices/IOLoop.java + test/javax/sound/midi/Devices/MidiDeviceGetReceivers.java + test/javax/sound/midi/Devices/MidiIO.java + test/javax/sound/midi/Devices/MidiOutGetMicrosecondPositionBug.java + test/javax/sound/midi/Devices/OpenClose.java + test/javax/sound/midi/Devices/ReceiverTransmitterAvailable.java + test/javax/sound/midi/Devices/Reopen.java + test/javax/sound/midi/File/SMFCp037.java + test/javax/sound/midi/File/SMFParserBreak.java + test/javax/sound/midi/File/WriteRealTimeMessageNPE.java + test/javax/sound/midi/MetaMessage/MetaMessageClone.java + test/javax/sound/midi/MidiSystem/6411624/Test6411624.java + test/javax/sound/midi/MidiSystem/6411624/bug6411624.java + test/javax/sound/midi/MidiSystem/DefaultDevices.java + test/javax/sound/midi/MidiSystem/DefaultProperties.java + test/javax/sound/midi/MidiSystem/GetSequencer.java + test/javax/sound/midi/MidiSystem/MidiFileTypeUniqueness.java + test/javax/sound/midi/MidiSystem/ProviderCacheing.java + test/javax/sound/midi/MidiSystem/testdata/conf/sound.properties + test/javax/sound/midi/Sequence/GetMicrosecondLength.java + test/javax/sound/midi/Sequence/MidiSMPTE.java + test/javax/sound/midi/Sequence/SMPTEDuration.java + test/javax/sound/midi/Sequencer/LoopIAE.java + test/javax/sound/midi/Sequencer/Looping.java + test/javax/sound/midi/Sequencer/MetaCallback.java + test/javax/sound/midi/Sequencer/Recording.java + test/javax/sound/midi/Sequencer/SeqRecordDoesNotCopy.java + test/javax/sound/midi/Sequencer/SeqRecordsRealTimeEvents.java + test/javax/sound/midi/Sequencer/SeqStartRecording.java + test/javax/sound/midi/Sequencer/SequencerCacheValues.java + test/javax/sound/midi/Sequencer/SequencerSetMuteSolo.java + test/javax/sound/midi/Sequencer/SequencerState.java + test/javax/sound/midi/Sequencer/SetTickPosition.java + test/javax/sound/midi/Sequencer/TickLength.java + test/javax/sound/midi/ShortMessage/FastShortMessage.java + test/javax/sound/midi/ShortMessage/FastShortMessage2.java + test/javax/sound/midi/Soundbanks/ExtraCharInSoundbank.java + test/javax/sound/midi/Soundbanks/GetSoundBankIOException.java + test/javax/sound/midi/Synthesizer/AsynchronousMidiChannel.java + test/javax/sound/midi/Synthesizer/Receiver/bug6186488.java + test/javax/sound/midi/Synthesizer/SynthesizerGetLatency.java + test/javax/sound/midi/Synthesizer/bug4685396.java + test/javax/sound/midi/Track/TrackAddSameTick.java + test/javax/sound/midi/Track/bug6416024.java + test/javax/sound/midi/Transmitter/bug6415669.java + test/javax/sound/sampled/AudioFileFormat/AudioFileFormatToString.java + test/javax/sound/sampled/AudioFileFormat/Properties.java + test/javax/sound/sampled/AudioFileFormat/TypeEquals.java + test/javax/sound/sampled/AudioFormat/AudioFormatBitSize.java + test/javax/sound/sampled/AudioFormat/EncodingEquals.java + test/javax/sound/sampled/AudioFormat/Properties.java + test/javax/sound/sampled/AudioInputStream/AISReadFraction.java + test/javax/sound/sampled/AudioInputStream/bug6188860.java + test/javax/sound/sampled/AudioSystem/AudioFileTypes/AudioFileTypeUniqueness.java + test/javax/sound/sampled/AudioSystem/AudioFileTypes/ShowAudioFileTypes.java + test/javax/sound/sampled/AudioSystem/DefaultMixers.java + test/javax/sound/sampled/AudioSystem/DefaultProperties.java + test/javax/sound/sampled/AudioSystem/ProviderCacheing.java + test/javax/sound/sampled/AudioSystem/testdata/conf/sound.properties + test/javax/sound/sampled/Clip/ClipCloseLoss.java + test/javax/sound/sampled/Clip/ClipFlushCrash.java + test/javax/sound/sampled/Clip/Drain/ClipDrain.java + test/javax/sound/sampled/Clip/Duration/ClipDuration.java + test/javax/sound/sampled/Clip/Endpoint/ClipSetEndPoint.java + test/javax/sound/sampled/Clip/Open/ClipOpenBug.java + test/javax/sound/sampled/Clip/bug5070081.java + test/javax/sound/sampled/Clip/bug6251460.java + test/javax/sound/sampled/Controls/CompoundControl/ToString.java + test/javax/sound/sampled/Controls/FloatControl/FloatControlBug.java + test/javax/sound/sampled/DataLine/DataLineInfoNegBufferSize.java + test/javax/sound/sampled/DataLine/LineDefFormat.java + test/javax/sound/sampled/DataLine/LongFramePosition.java + test/javax/sound/sampled/DirectAudio/TickAtEndOfPlay.java + test/javax/sound/sampled/DirectAudio/bug6372428.java + test/javax/sound/sampled/FileTypeExtension/FileTypeExtensionTest.java + test/javax/sound/sampled/LineEvent/LineInfoNPE.java + test/javax/sound/sampled/Lines/16and32KHz/Has16and32KHz.java + test/javax/sound/sampled/Lines/BufferSizeCheck.java + test/javax/sound/sampled/Lines/ChangingBuffer.java + test/javax/sound/sampled/Lines/ClickInPlay/ClickInPlay.java + test/javax/sound/sampled/Lines/ClickInPlay/Test4218609.java + test/javax/sound/sampled/Lines/ClipOpenException.java + test/javax/sound/sampled/Lines/FrameSize/FrameSizeTest.java + test/javax/sound/sampled/Lines/GetLine.java + test/javax/sound/sampled/Lines/SDLwrite.java + test/javax/sound/sampled/Lines/SourceDataLineDefaultBufferSizeCrash.java + test/javax/sound/sampled/Lines/StopStart.java + test/javax/sound/sampled/LinuxBlock/PlaySine.java + test/javax/sound/sampled/LinuxCrash/ClipLinuxCrash.java + test/javax/sound/sampled/LinuxCrash/ClipLinuxCrash2.java + test/javax/sound/sampled/LinuxCrash/SDLLinuxCrash.java + test/javax/sound/sampled/Mixers/BogusMixers.java + test/javax/sound/sampled/Mixers/BothEndiansAndSigns.java + test/javax/sound/sampled/Mixers/DirectSoundRepeatingBuffer/DirectSoundRepeatingBuffer.java + test/javax/sound/sampled/Mixers/DirectSoundRepeatingBuffer/Test4997635.java + test/javax/sound/sampled/Mixers/DirectSoundUnderrunSilence/DirectSoundUnderrunSilence.java + test/javax/sound/sampled/Mixers/DirectSoundUnderrunSilence/Test5032020.java + test/javax/sound/sampled/Mixers/DisabledAssertionCrash.java + test/javax/sound/sampled/Mixers/NoSimpleInputDevice.java + test/javax/sound/sampled/Mixers/PhantomMixers.java + test/javax/sound/sampled/Mixers/PlugHwMonoAnd8bitAvailable.java + test/javax/sound/sampled/Mixers/UnexpectedIAE.java + test/javax/sound/sampled/Recording/TargetDataLineFlush.java + test/javax/sound/sampled/spi/AudioFileReader/AIFFCp037.java + test/javax/sound/sampled/spi/AudioFileReader/AIFFLargeHeader.java + test/javax/sound/sampled/spi/AudioFileReader/Aiff12bit.java + test/javax/sound/sampled/spi/AudioFileReader/AuNotSpecified.java + test/javax/sound/sampled/spi/AudioFileReader/AuZeroLength.java + test/javax/sound/sampled/spi/AudioFileReader/OpenWaveFile.java + test/javax/sound/sampled/spi/AudioFileWriter/AUwithULAW.java + test/javax/sound/sampled/spi/AudioFileWriter/AiffSampleRate.java + test/javax/sound/sampled/spi/AudioFileWriter/RIFFHeader.java + test/javax/sound/sampled/spi/AudioFileWriter/WaveBigEndian.java + test/javax/sound/sampled/spi/AudioFileWriter/WriteAuUnspecifiedLength.java + test/javax/sound/sampled/spi/FormatConversionProvider/AlawUlaw.java Changeset: f970d80b7a55 Author: ddehaven Date: 2016-10-31 10:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f970d80b7a55 Merge - src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java ! test/ProblemList.txt - test/java/lang/module/ModuleReader/MultiReleaseJarTest.java - test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/MyResources_ja_JP.properties Changeset: d13621cb40df Author: alexsch Date: 2016-11-01 12:38 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d13621cb40df 8168899: java.nio.file.InvalidPathException if click button in JFileChooser demo of SwingSet2 Reviewed-by: ssadetsky, serb Contributed-by: Alok Kumar Sharma ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! test/java/awt/FileDialog/8017487/bug8017487.java Changeset: 3bddef7033e5 Author: alexsch Date: 2016-11-01 12:56 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bddef7033e5 8167176: Exported elements referring to inaccessible types in java.desktop Reviewed-by: prr, serb ! src/java.desktop/share/classes/javax/swing/JRootPane.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollBarUI.java Changeset: eef9f927659d Author: ddehaven Date: 2016-11-03 13:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eef9f927659d Merge - src/java.desktop/macosx/classes/sun/lwawt/macosx/NSPrintInfo.java Changeset: 40620d84d55d Author: jnimeh Date: 2016-11-03 15:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/40620d84d55d 8133632: javax.net.ssl.SSLEngine does not properly handle received SSL fatal alerts Summary: Upon receiving a fatal alert, make sure the input and output queues are closed and the engine is in the NOT_HANDSHAKING state. Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java + test/javax/net/ssl/SSLEngine/EngineCloseOnAlert.java Changeset: b1d58146df13 Author: mchung Date: 2016-11-03 18:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b1d58146df13 6479237: (cl) Add support for classloader names Reviewed-by: alanb, bchristi, coleenp, dfuchs, lfoltan, psandoz, sspitsyn ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjava/reorder-sparc ! make/mapfiles/libjava/reorder-sparcv9 ! make/mapfiles/libjava/reorder-x86 ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/StackFrameInfo.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/Throwable.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.base/share/native/include/jvm.h - src/java.base/share/native/libjava/StackFrameInfo.c + src/java.base/share/native/libjava/StackTraceElement.c ! src/java.base/share/native/libjava/Throwable.c ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! test/java/lang/StackTraceElement/PublicConstructor.java + test/java/lang/StackTraceElement/SerialTest.java + test/java/lang/StackTraceElement/WithClassLoaderName.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/StackTraceElement/src/p/ThrowException.java ! test/java/lang/StackWalker/VerifyStackTrace.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java ! test/java/net/URLClassLoader/NullURLTest.java Changeset: 000fe525272d Author: amlu Date: 2016-11-04 22:33 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/000fe525272d 8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output Reviewed-by: dfuchs, rriggs ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: b46fb3d66cf4 Author: lana Date: 2016-11-04 17:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b46fb3d66cf4 Merge - src/java.base/share/native/libjava/StackFrameInfo.c - src/java.desktop/macosx/classes/sun/lwawt/macosx/NSPrintInfo.java ! test/ProblemList.txt - test/java/net/URLPermission/nstest/lookup.sh - test/java/util/stream/bootlib/java.base/java/util/stream/ThowableHelper.java Changeset: 93e7c16fd885 Author: smarks Date: 2016-11-04 14:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93e7c16fd885 8156079: consider making empty instances singletons 8169222: minor immutable collections optimizations Reviewed-by: forax, redestad, alanb ! 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 Changeset: 7ee327a10059 Author: mchung Date: 2016-11-04 15:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ee327a10059 8169231: Fix tests to add @compile --add-modules to workaround jtreg bug Reviewed-by: jjg ! test/ProblemList.txt ! test/com/sun/jndi/dns/Parser.java ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java ! test/sun/security/ec/TestEC.java ! test/sun/security/mscapi/IsSunMSCAPIAvailable.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/tools/launcher/MiscTests.java Changeset: 06195d1ca9ce Author: sundar Date: 2016-11-07 11:33 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/06195d1ca9ce 8166286: jmod fails on symlink to directory Reviewed-by: jlaskey, alanb ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/tools/jmod/JmodTest.java + test/tools/jmod/src/apa/jdk/test/apa/Apa.java + test/tools/jmod/src/apa/module-info.java Changeset: 736a5f3085b2 Author: erikj Date: 2016-11-07 13:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/736a5f3085b2 8168108: lib/classlist should be packaged in java.base.jmod Reviewed-by: mchung - make/GenerateClasslist.gmk Changeset: 53d76efc6fdc Author: erikj Date: 2016-11-07 14:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/53d76efc6fdc 8160491: tar.gz bundles missing files containing $ Reviewed-by: ihse ! make/rmic/Rmic-java.rmi.gmk Changeset: efa71dc820eb Author: jlaskey Date: 2016-11-07 13:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/efa71dc820eb 8159393: jlink should print a warning that a signed modular JAR will be treated as unsigned Reviewed-by: alanb, sundar, mullan, weijun ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.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/jlink/resources/jlink.properties + test/tools/jlink/JLinkSigningTest.java Changeset: 82aef4ec4ab0 Author: mchung Date: 2016-11-10 14:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/82aef4ec4ab0 Merge ! make/mapfiles/libjava/mapfile-vers ! 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/StackTraceElement.java ! src/java.base/share/classes/java/lang/Throwable.java - src/java.base/share/classes/java/lang/module/Dependence.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.base/share/native/include/jvm.h ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.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/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/ProblemList.txt ! test/com/sun/jndi/dns/Parser.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/StackTraceElement/PublicConstructor.java ! test/java/lang/StackTraceElement/SerialTest.java ! test/java/lang/StackTraceElement/WithClassLoaderName.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 ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.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/Basic.java - test/java/util/ServiceLoader/FooProvider1.java - test/java/util/ServiceLoader/FooProvider2.java - test/java/util/ServiceLoader/FooProvider3.java - test/java/util/ServiceLoader/FooService.java - test/java/util/ServiceLoader/Load.java - test/java/util/ServiceLoader/basic.sh - 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/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/security/mscapi/IsSunMSCAPIAvailable.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/tools/jmod/JmodTest.java ! test/tools/launcher/MiscTests.java From mandy.chung at oracle.com Thu Nov 10 22:37:10 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Nov 2016 22:37:10 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201611102237.uAAMbAQC010388@aojmv0008.oracle.com> Changeset: a7f21ee6ed30 Author: hannesw Date: 2016-11-07 14:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a7f21ee6ed30 8156619: Unimplemented ES6 features should result in clear Error being thrown Reviewed-by: sundar, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/es6/class.js + test/script/basic/es6/class.js.EXPECTED + test/script/basic/es6/destructuring.js + test/script/basic/es6/destructuring.js.EXPECTED + test/script/basic/es6/generator.js + test/script/basic/es6/generator.js.EXPECTED + test/script/basic/es6/restparam.js + test/script/basic/es6/restparam.js.EXPECTED + test/script/basic/es6/spread.js + test/script/basic/es6/spread.js.EXPECTED + test/script/basic/es6/super.js + test/script/basic/es6/super.js.EXPECTED Changeset: def222987a23 Author: mchung Date: 2016-11-10 14:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/def222987a23 Merge From jonathan.gibbons at oracle.com Fri Nov 11 00:01:03 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Nov 2016 00:01:03 +0000 Subject: hg: jigsaw/jake/langtools: 17 new changesets Message-ID: <201611110001.uAB014LV001901@aojmv0008.oracle.com> Changeset: d3dde3f775b8 Author: jlahoda Date: 2016-11-02 16:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d3dde3f775b8 8166538: Improve error reporting for compiling against unexported package Summary: When a type cannot be found, look into other modules, search for possible viable types, and report them conveniently to the user. Reviewed-by: mcimadamore, jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.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/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/PackageClassAmbiguity/util.out ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235a.out ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T5003235/T5003235b.out ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/NotDefAccessClassIntfCantAccessReason.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api1/api1/Api.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api1/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api2/api2/Api.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api2/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/impl/impl/Impl.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/impl/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/NotDefAccessClassIntfCantAccessReason.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api1/api1/Api.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api1/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api2/api2/Api.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api2/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/impl/impl/Impl.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/impl/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/NotDefAccessClassPackageCantAccess.java - test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/p1/C1.java - test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/p2/C2.java + test/tools/javac/diags/examples/NotDefAccessDoesNotRead/NotDefAccessDoesNotRead.java + test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/api/api/Api.java + test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/api/module-info.java + test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/impl/impl/Impl.java + test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/impl/module-info.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/NotDefAccessDoesNotReadFromUnnamed.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/modulepath/api/api/Api.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/modulepath/api/module-info.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/NotDefAccessDoesNotReadUnnamed.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/classpath/api/Api.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/auxiliary/auxiliary/Auxiliary.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/auxiliary/module-info.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/impl/impl/Impl.java + test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/impl/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExported/NotDefAccessNotExported.java + test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/api/api/Api.java + test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/api/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/impl/impl/Impl.java + test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/impl/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExportedFromUnnamed/NotDefAccessNotExportedFromUnnamed.java + test/tools/javac/diags/examples/NotDefAccessNotExportedFromUnnamed/modulepath/api/api/Api.java + test/tools/javac/diags/examples/NotDefAccessNotExportedFromUnnamed/modulepath/api/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/NotDefAccessNotExportedToModule.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/api/api/Api.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/api/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/impl/impl/Impl.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/impl/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/other/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/NotDefAccessNotExportedToModuleFromUnnamed.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/modulepath/api/api/Api.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/modulepath/api/module-info.java + test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/modulepath/other/module-info.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/modules/AutomaticModules.java + test/tools/javac/modules/ConvenientAccessErrorsTest.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/PackageMultipleModules.java ! test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/ResolveTest.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/modules/XModuleTest.java Changeset: 1fc501869aa8 Author: jlahoda Date: 2016-11-02 20:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1fc501869aa8 8169074: Build is failing after JDK-8166538 Summary: Reverting d3dde3f775b8 Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.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/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/PackageClassAmbiguity/util.out ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235a.out ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T5003235/T5003235b.out ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples.not-yet.txt - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/NotDefAccessClassIntfCantAccessReason.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api1/api1/Api.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api1/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api2/api2/Api.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api2/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/impl/impl/Impl.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/impl/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/NotDefAccessClassIntfCantAccessReason.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api1/api1/Api.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api1/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api2/api2/Api.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api2/module-info.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/impl/impl/Impl.java - test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/impl/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/NotDefAccessClassPackageCantAccess.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/p1/C1.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/p2/C2.java - test/tools/javac/diags/examples/NotDefAccessDoesNotRead/NotDefAccessDoesNotRead.java - test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/api/api/Api.java - test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/api/module-info.java - test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/impl/impl/Impl.java - test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/impl/module-info.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/NotDefAccessDoesNotReadFromUnnamed.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/modulepath/api/api/Api.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/modulepath/api/module-info.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/NotDefAccessDoesNotReadUnnamed.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/classpath/api/Api.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/auxiliary/auxiliary/Auxiliary.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/auxiliary/module-info.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/impl/impl/Impl.java - test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/impl/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExported/NotDefAccessNotExported.java - test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/api/api/Api.java - test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/api/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/impl/impl/Impl.java - test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/impl/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExportedFromUnnamed/NotDefAccessNotExportedFromUnnamed.java - test/tools/javac/diags/examples/NotDefAccessNotExportedFromUnnamed/modulepath/api/api/Api.java - test/tools/javac/diags/examples/NotDefAccessNotExportedFromUnnamed/modulepath/api/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/NotDefAccessNotExportedToModule.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/api/api/Api.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/api/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/impl/impl/Impl.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/impl/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModule/modulesourcepath/other/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/NotDefAccessNotExportedToModuleFromUnnamed.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/modulepath/api/api/Api.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/modulepath/api/module-info.java - test/tools/javac/diags/examples/NotDefAccessNotExportedToModuleFromUnnamed/modulepath/other/module-info.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/modules/AutomaticModules.java - test/tools/javac/modules/ConvenientAccessErrorsTest.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/PackageMultipleModules.java ! test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/ResolveTest.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/modules/XModuleTest.java Changeset: 035532fe695b Author: smarks Date: 2016-11-02 14:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/035532fe695b 8169078: add bug IDs to jdeprscan tests Reviewed-by: jjg ! test/tools/jdeprscan/tests/jdk/jdeprscan/TestLoad.java ! test/tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java Changeset: afaafd7267cc Author: rfield Date: 2016-11-02 16:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/afaafd7267cc 8167636: jshell tool: Edit Pad should be in its own module Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditPad.java - 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 ! src/jdk.jshell/share/classes/module-info.java - test/jdk/jshell/EditorPadTest.java Changeset: 692418f52877 Author: jlahoda Date: 2016-11-03 11:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/692418f52877 8166635: getEnclosedElements() on package causes BadClassFile error Summary: Properly reading typevars from enclosing scopes for local classes. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/processing/model/nestedTypeVars/NestedTypeVars.java + test/tools/javac/processing/model/nestedTypeVars/NestedTypeVars.out Changeset: 08e3ce8305c9 Author: ksrini Date: 2016-11-02 15:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/08e3ce8305c9 8166857: langtools build.xml broken on windows Reviewed-by: jjg, jlahoda, mcimadamore ! make/build.xml Changeset: 46f2219faf5a Author: rfield Date: 2016-11-03 09:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/46f2219faf5a 8161969: jshell tool: /var value is not truncated per feedback setting 8166637: jshell tool: confusing truncation of long result values 8154513: JShell tool: welcome message should match feedback mode 8167552: jshell tool: Typo in jshell command '/? /reload' description Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.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/ToolFormatTest.java ! test/jdk/jshell/ToolRetainTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 80b576bd3631 Author: jjg Date: 2016-11-03 13:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/80b576bd3631 8167975: align javac --add-* modules options with launcher Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.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/AbstractDiagnosticFormatter.java ! test/tools/doclint/moduleTests/bad/module-info.java ! test/tools/doclint/moduleTests/good/module-info.java ! test/tools/javac/T6403466.java + test/tools/javac/diags/examples/BadNameForOption.java - test/tools/javac/diags/examples/CantFindModule/CantFindModule.java + test/tools/javac/diags/examples/ModuleForOptionNotFound.java - test/tools/javac/diags/examples/XaddexportsMalformedEntry.java - test/tools/javac/diags/examples/XaddexportsTooMany.java - test/tools/javac/diags/examples/XaddreadsMalformedEntry.java - test/tools/javac/diags/examples/XaddreadsTooMany.java + test/tools/javac/modules/AddExportsTest.java + test/tools/javac/modules/AddModulesTest.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java ! test/tools/javac/modules/EdgeCases.java + test/tools/javac/modules/LimitModulesTest.java ! test/tools/javac/modules/ModuleTestBase.java ! test/tools/javac/modules/XModuleTest.java Changeset: 74a391527c2c Author: lana Date: 2016-11-04 17:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/74a391527c2c Merge - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditPad.java - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java - test/jdk/jshell/EditorPadTest.java - test/tools/javac/diags/examples/CantFindModule/CantFindModule.java - test/tools/javac/diags/examples/XaddexportsMalformedEntry.java - test/tools/javac/diags/examples/XaddexportsTooMany.java - test/tools/javac/diags/examples/XaddreadsMalformedEntry.java - test/tools/javac/diags/examples/XaddreadsTooMany.java Changeset: 16f0cf12da2d Author: rfield Date: 2016-11-04 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/16f0cf12da2d 8129559: JShell: compilation fails if class, method or field is annotated and has modifiers 8080354: JShell: Runtime visible annotations cannot be retrieved Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/MaskCommentsAndModifiers.java ! test/jdk/jshell/ClassMembersTest.java ! test/jdk/jshell/ClassesTest.java ! test/jdk/jshell/CompletenessTest.java ! test/jdk/jshell/IgnoreTest.java ! test/jdk/jshell/ModifiersTest.java Changeset: 5892a55c7bf9 Author: rfield Date: 2016-11-06 22:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5892a55c7bf9 8161983: JShell API: Clean-up following 8160127 et. al. 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/JDIEventHandler.java - src/jdk.jshell/share/classes/jdk/jshell/execution/JDIExecutionControl.java - src/jdk.jshell/share/classes/jdk/jshell/execution/JDIInitiator.java + src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java + src/jdk.jshell/share/classes/jdk/jshell/execution/JdiEventHandler.java + src/jdk.jshell/share/classes/jdk/jshell/execution/JdiExecutionControl.java + src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java ! test/jdk/jshell/FailOverExecutionControlTest.java - test/jdk/jshell/JDILaunchingExecutionControlTest.java - test/jdk/jshell/JDIListeningExecutionControlTest.java - test/jdk/jshell/JDIListeningLocalhostExecutionControlTest.java + test/jdk/jshell/JdiLaunchingExecutionControlTest.java + test/jdk/jshell/JdiListeningExecutionControlTest.java + test/jdk/jshell/JdiListeningLocalhostExecutionControlTest.java - test/jdk/jshell/UserJDIUserRemoteTest.java + test/jdk/jshell/UserJdiUserRemoteTest.java Changeset: 82a50c8d9a43 Author: mcimadamore Date: 2016-11-07 11:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/82a50c8d9a43 8168854: javac erroneously reject a a service interface inner class in a provides clause Summary: Java SE 9 proposed spec changes do not explicitly forbid a service interface to be an inner class - javac should follow Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/ServiceDefinitionInner/ServiceDefinitionInner.java - test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/module-info.java - test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/p1/C1.java - test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/p2/C2.java ! test/tools/javac/modules/ProvidesTest.java + test/tools/javac/modules/T8168854/module-info.java + test/tools/javac/modules/T8168854/pack1/Outer.java + test/tools/javac/modules/T8168854/pack1/Outer1.java Changeset: 47871e348144 Author: mcimadamore Date: 2016-11-07 16:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/47871e348144 8169093: Generics, javac not matching actual and formal arguments. Summary: Make diagnostic for type-args arity mismatch consistent with the class case Reviewed-by: vromero ! 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/WrongNumberTypeArgsFragment.java Changeset: ed2e9ef4ce42 Author: ksrini Date: 2016-11-08 12:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ed2e9ef4ce42 8166379: IAE while invoking javadoc with --patch-module Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! test/jdk/javadoc/tool/modules/Modules.java Changeset: d4deb115da83 Author: jlahoda Date: 2016-11-10 17:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d4deb115da83 8166700: NPE during invoking getEnclosedElements() on javax.lang.model.element.Element instance representing a package Summary: Should not strip first parameter of a local class constructor for local classes in initializers. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/processing/model/LocalClasses/LocalClassesModel.java + test/tools/javac/processing/model/LocalClasses/LocalClassesModel.out + test/tools/javac/processing/model/LocalClasses/LocalTest$1Local.jcod + test/tools/javac/processing/model/LocalClasses/LocalTest$2Local.jcod + test/tools/javac/processing/model/LocalClasses/LocalTest$3Local.jcod + test/tools/javac/processing/model/LocalClasses/LocalTest$4Local.jcod + test/tools/javac/processing/model/LocalClasses/LocalTest$5Local.jcod + test/tools/javac/processing/model/LocalClasses/LocalTest.jcod + test/tools/javac/processing/model/LocalClasses/LocalTest.orign Changeset: 6afd59d40256 Author: jjg Date: 2016-11-10 13:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6afd59d40256 8169447: javac should detect/reject repeated use of --patch-module on command line Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/modules/PatchModulesTest.java Changeset: cdb8c9dd402f Author: jjg Date: 2016-11-10 15:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cdb8c9dd402f Merge ! make/build.xml ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.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/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.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.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditPad.java - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java - src/jdk.jshell/share/classes/jdk/jshell/execution/JDIDefaultExecutionControl.java - src/jdk.jshell/share/classes/jdk/jshell/execution/JDIEventHandler.java - src/jdk.jshell/share/classes/jdk/jshell/execution/JDIExecutionControl.java - src/jdk.jshell/share/classes/jdk/jshell/execution/JDIInitiator.java ! src/jdk.jshell/share/classes/module-info.java ! test/jdk/javadoc/tool/modules/Modules.java - test/jdk/jshell/EditorPadTest.java - test/jdk/jshell/JDILaunchingExecutionControlTest.java - test/jdk/jshell/JDIListeningExecutionControlTest.java - test/jdk/jshell/JDIListeningLocalhostExecutionControlTest.java ! test/jdk/jshell/ToolFormatTest.java - test/jdk/jshell/UserJDIUserRemoteTest.java ! test/tools/javac/T6403466.java ! test/tools/javac/diags/Example.java - test/tools/javac/diags/examples/CantFindModule/CantFindModule.java - test/tools/javac/diags/examples/ServiceDefinitionInner/ServiceDefinitionInner.java - test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/module-info.java - test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/p1/C1.java - test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/p2/C2.java - test/tools/javac/diags/examples/XaddexportsMalformedEntry.java - test/tools/javac/diags/examples/XaddexportsTooMany.java - test/tools/javac/diags/examples/XaddreadsMalformedEntry.java - test/tools/javac/diags/examples/XaddreadsTooMany.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/ModuleTestBase.java ! test/tools/javac/modules/PackageMultipleModules.java ! test/tools/javac/modules/PatchModulesTest.java ! test/tools/javac/modules/ProvidesTest.java ! test/tools/javac/modules/RequiresTransitiveTest.java ! test/tools/javac/modules/ResolveTest.java + test/tools/javac/modules/T8168854/pack1/Outer.java + test/tools/javac/modules/T8168854/pack1/Outer1.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/modules/XModuleTest.java + test/tools/javac/processing/model/LocalClasses/LocalClassesModel.java From mandy.chung at oracle.com Fri Nov 11 06:07:37 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:07:37 +0000 Subject: hg: jigsaw/jake: 2 new changesets Message-ID: <201611110607.uAB67bIV005025@aojmv0008.oracle.com> Changeset: 7493bf3d3459 Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7493bf3d3459 Added tag jdk-9+144 for changeset 8d337fd6333e ! .hgtags Changeset: 5e14a784c3e9 Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5e14a784c3e9 Merge From mandy.chung at oracle.com Fri Nov 11 06:07:42 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:07:42 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201611110607.uAB67g3d005083@aojmv0008.oracle.com> Changeset: a44b156ae7f0 Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a44b156ae7f0 Added tag jdk-9+144 for changeset d4f1dae17409 ! .hgtags Changeset: 78bef2c5feaa Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/78bef2c5feaa Merge From mandy.chung at oracle.com Fri Nov 11 06:07:51 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:07:51 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201611110607.uAB67peB005137@aojmv0008.oracle.com> Changeset: 61e7ea563123 Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/61e7ea563123 Added tag jdk-9+144 for changeset 6187b582d02a ! .hgtags Changeset: 0f9e92e45931 Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0f9e92e45931 Merge ! .hgtags - test/runtime/modules/JVMCanReadModule.java - test/runtime/modules/JVMIsExportedToModule.java From mandy.chung at oracle.com Fri Nov 11 06:08:03 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:08:03 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201611110608.uAB683Vh005274@aojmv0008.oracle.com> Changeset: 71558b38bad7 Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/71558b38bad7 Added tag jdk-9+144 for changeset 99be33734ff6 ! .hgtags Changeset: f4a78af5217d Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f4a78af5217d Merge From mandy.chung at oracle.com Fri Nov 11 06:08:06 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:08:06 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201611110608.uAB6866d005324@aojmv0008.oracle.com> Changeset: 29277a4e7307 Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/29277a4e7307 Added tag jdk-9+144 for changeset 92523c51d6a4 ! .hgtags Changeset: b00722c934c1 Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b00722c934c1 Merge From mandy.chung at oracle.com Fri Nov 11 06:08:14 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:08:14 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611110608.uAB68EAZ005429@aojmv0008.oracle.com> Changeset: b1fc95093f8c Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b1fc95093f8c Added tag jdk-9+144 for changeset efa71dc820eb ! .hgtags Changeset: 603b55db60a0 Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/603b55db60a0 Merge ! .hgtags - src/java.base/share/classes/java/lang/module/Dependence.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/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/Basic.java - test/java/util/ServiceLoader/FooProvider1.java - test/java/util/ServiceLoader/FooProvider2.java - test/java/util/ServiceLoader/FooProvider3.java - test/java/util/ServiceLoader/FooService.java - test/java/util/ServiceLoader/Load.java - test/java/util/ServiceLoader/basic.sh - 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 Fri Nov 11 06:10:53 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:10:53 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201611110610.uAB6ArST006435@aojmv0008.oracle.com> Changeset: 2ce7c1083dcb Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2ce7c1083dcb Added tag jdk-9+144 for changeset 47871e348144 ! .hgtags Changeset: 1520a026cd3e Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1520a026cd3e 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/diags/examples/LeaksNotAccessibleNotRequiredPublic/LeaksNotAccessibleNotRequiredPublic.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/api1/Api1.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/module-info.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/api2/Api2.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/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 Nov 11 06:11:25 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Nov 2016 06:11:25 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201611110611.uAB6BPpV007162@aojmv0008.oracle.com> Changeset: 37ac000ae6b1 Author: lana Date: 2016-11-11 05:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/37ac000ae6b1 Added tag jdk-9+144 for changeset a7f21ee6ed30 ! .hgtags Changeset: 9438e71128ed Author: mchung Date: 2016-11-10 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9438e71128ed Merge ! .hgtags From alan.bateman at oracle.com Fri Nov 11 08:46:44 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Nov 2016 08:46:44 +0000 Subject: hg: jigsaw/jake/corba: java.naming needs to open java.corba com/sun/jndi/cosnaming/jndiprovider.properties Message-ID: <201611110846.uAB8kin7011593@aojmv0008.oracle.com> Changeset: 5fa18142554d Author: alanb Date: 2016-11-11 08:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/5fa18142554d java.naming needs to open java.corba com/sun/jndi/cosnaming/jndiprovider.properties ! src/java.corba/share/classes/module-info.java From alan.bateman at oracle.com Fri Nov 11 10:22:53 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Nov 2016 10:22:53 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201611111022.uABAMrUl002969@aojmv0008.oracle.com> Changeset: 1901f58d996d Author: alanb Date: 2016-11-11 10:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1901f58d996d Temporarily exclude com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java ! test/ProblemList.txt Changeset: cfbc00374eae Author: alanb Date: 2016-11-11 10:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cfbc00374eae javadoc clarifications ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: cbd25b0d00cb Author: alanb Date: 2016-11-11 10:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cbd25b0d00cb Need tests for requires transitive static ! src/java.base/share/classes/java/lang/module/Resolver.java ! test/java/lang/module/ConfigurationTest.java From adinn at redhat.com Fri Nov 11 13:43:53 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Nov 2016 13:43:53 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <954422482.231078.1477958267342.JavaMail.zimbra@u-pem.fr> <59fc283b-9875-b3a7-bb63-9bb723cc5651@redhat.com> <3201F1EC-E0CF-46C7-AC79-383AAA84F479@oracle.com> <0c442448-8c73-14d0-f32e-b9425edc60f1@gmx.org> <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> Message-ID: Hi John, I'm reviving an old (by 2-3 weeks) conversation here because it seems the right place to ask about how to deal with a disparity I found between the use of reflection vs method handles. I'm have retained the cc to jigsaw-dev because i) the conversation started there and ii) it relates to the question of how well Lookups and MethdoHandles can stand in for reflection. Perhaps that's too tenuous to merit a CC but I'm adopting the excuse that those who are only interested in more direct Jigsaw content can simply ignore the rest of this thread. The disparity I am seeing looks like it might just be an argument for Maurizio's new reflection API more than anything else but it may just be that I am doing something wrong. I'll present the problem in as reduced form as I can manage to extract from the Byteman implementation. Byteman includes a test to ensure that the type checker allows duck typing when a compatible array type is passed as input to a method. So, we have a test method public class TestArrayArgTypeCheck extends Test { . . . public void testArrayCall(String[] args) { log("inside testArrayCall"); } } where log is defined by the parent class Test. I use a Byteman rule as follows RULE test array arg type check CLASS TestArrayArgTypeCheck METHOD testArrayCall AT ENTRY BIND test : Test = $this; IF TRUE DO test.log("args : " + java.util.Arrays.asList($args) ); ENDRULE This rule is 'injected' at the start of the code for method testArrayCall -- it's not actually executed as inline bytecode, rather a callout to the rule interpreter executes the rule (out of line bytecode execution is also an option but I don't [yet?] need to add that complexity to the mix). In case you are unfamiliar with how Byteman operates I'll summarise its operation. $this and $args name bindings for values passed into the interpreter, respectively: the instance of TestArrayArgTypeCheck fielding the call to the method (which Byteman knows is of type TestArrayArgTypeCheck) the argument to testArrayCall (which Byteman knows is of type String[]) the BIND clause binds a /rule-local/ variable test (of type Test) to the instance of TestArrayArgTypeCheck fielding the call to the method the DO clause passes $this to Arrays.asList() pastes the result into a String passes the String to Test.log So, the test ensures that Byteman's type checker accepts that the String[] argument passed to Arrays.asList(Object[]) is a legitimate argument without throwing a type exception. It doesn't really matter what the log output is but the test does check for an expected output and that is where the disparity arises. The call to the target method is made by the test code as follows . . . String[] ordinals = { "first", "second", "third" }; log("calling testArrayCall"); testArrayCall(ordinals); log("called testArrayCall"); . . . When this is run on JDK8[-] I see this output which matches expectation: calling testArrayCall args : [first, second, third] inside testArrayCall called testArrayCall When I run this on JDK9 using a modified version of Byteman that relies on MethodHandles I see this output: calling testArrayCall args : [[Ljava.lang.String;@36bc55de] inside testArrayCall called testArrayCall So, the String[] array appears to have been wrapped in an Object[] before being passed on to Arrays.asList(). On JDK8[-] I use reflection to execute the method call. So, essentially the code looks like this class MethodExpression { Method method; Expression recipient; List arguments; . . . Object interpret(...) . . . Object recipientValue = (recipient != null ? recipient.interpret(...) : null); int argCount = arguments.size(); Object[] argValues = new Object[argCount]; for (int i = 0; i < argCount; i++) { argValues[i] = arguments.get(i).interpret(...); } . . . return method.invoke(recipientValue, argValues); The essential differences in the code that gets executed on JDK9 (ignoring that I am inlining code here from different branches) are as follows: class MethodExpression { Method method; MethodHandle handle = getMethodHandle(method); List arguments; . . . Object interpret(...) . . . Object recipientValue = (recipient != null ? recipient.interpret(...) : null); int argCount = arguments.size(); Object[] argValues = new Object[argCount]; for (int i = 0; i < argCount; i++) { argValues[i] = arguments.get(i).interpret(helper); } . . . if (recipient == null) { handle.invoke(argValues); } else { handle.invokeWithArguments(recipientValue, argValues); } The key point is how I construct that method handle. In essence it is as follows Lookup theLookup = ...; MethodHandle getMethodHandle(Method method) { try { MethodType methodType = MethodType.methodType(method.getReturnType(), method.getParameterTypes()); isStatic = Modifier.isStatic(method.getModifiers()); if (isStatic) { handle = theLookup.findStatic(method.getDeclaringClass(), method.getName(), methodType); } else { MethodHandle h = theLookup.findVirtual(method.getDeclaringClass(), method.getName(), methodType); handle = h.asSpreader(1, Object[].class, method.getParameterCount()); } return handle; } catch (...) { throw new RuntimeException(...) } } [n.b. theLookup is a suitable MethodHandles.Lookup that I finagle out of class Lookup -- it's provenance doesn't really matter just now] The problem appears to relate to the argument coercing that is done under the handle.invoke call. Clearly a String[] argument does not match the Object[].class parameter type occurring in the parameters returned by method.getParameterTypes() and passed to findStatic. I have tried varying this by applying an explicit spreader if (isStatic) { MethodHandle h = theLookup.findStaticmethod.getDeclaringClass(), method.getName(), methodType); handle = h.asSpreader(0, Object[].class, method.getParameterCount()); } else { . . . } and using handle.invokeWithArguments in place of handle.invoke but that produces the same result (indeed looking at the code I think the original invoke call is already treated as a spread call. I'm not really sure why this is operating the way it does by wrapping the String[] input in an Object[]. It seems that it may perhaps be an artefact of trying to combine inexact invocation with duck typing for generics. Am I doing something wrong in the method handle lookup or in the invocation? Or is this a corner case where invoke is performing the wrong type of coercion? 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 forax at univ-mlv.fr Fri Nov 11 15:09:35 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 11 Nov 2016 16:09:35 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> Message-ID: <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> Hi Andrew, welcome to the jungle of the java.lang.invoke API ! ----- Mail original ----- > De: "Andrew Dinn" > ?: "John Rose" > Cc: "Remi Forax" , jigsaw-dev at openjdk.java.net > Envoy?: Vendredi 11 Novembre 2016 14:43:53 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages > Hi John, > > I'm reviving an old (by 2-3 weeks) conversation here because it seems > the right place to ask about how to deal with a disparity I found > between the use of reflection vs method handles. I'm have retained the > cc to jigsaw-dev because i) the conversation started there and ii) it > relates to the question of how well Lookups and MethdoHandles can stand > in for reflection. Perhaps that's too tenuous to merit a CC but I'm > adopting the excuse that those who are only interested in more direct > Jigsaw content can simply ignore the rest of this thread. > > The disparity I am seeing looks like it might just be an argument for > Maurizio's new reflection API more than anything else but it may just be > that I am doing something wrong. I'll present the problem in as reduced > form as I can manage to extract from the Byteman implementation. > > Byteman includes a test to ensure that the type checker allows duck > typing when a compatible array type is passed as input to a method. So, > we have a test method > > public class TestArrayArgTypeCheck extends Test { > . . . > public void testArrayCall(String[] args) > { > log("inside testArrayCall"); > } > } > > where log is defined by the parent class Test. > > I use a Byteman rule as follows > > RULE test array arg type check > CLASS TestArrayArgTypeCheck > METHOD testArrayCall > AT ENTRY > BIND test : Test = $this; > IF TRUE > DO test.log("args : " + java.util.Arrays.asList($args) ); > ENDRULE > > This rule is 'injected' at the start of the code for method > testArrayCall -- it's not actually executed as inline bytecode, rather a > callout to the rule interpreter executes the rule (out of line bytecode > execution is also an option but I don't [yet?] need to add that > complexity to the mix). In case you are unfamiliar with how Byteman > operates I'll summarise its operation. > > $this and $args name bindings for values passed into the interpreter, > respectively: > the instance of TestArrayArgTypeCheck fielding the call to the > method (which Byteman knows is of type TestArrayArgTypeCheck) > the argument to testArrayCall (which Byteman knows is of type String[]) > > the BIND clause binds a /rule-local/ variable test (of type Test) to > the instance of TestArrayArgTypeCheck fielding the call to the method > > the DO clause > passes $this to Arrays.asList() > pastes the result into a String > passes the String to Test.log > > So, the test ensures that Byteman's type checker accepts that the > String[] argument passed to Arrays.asList(Object[]) is a legitimate > argument without throwing a type exception. It doesn't really matter > what the log output is but the test does check for an expected output > and that is where the disparity arises. > > The call to the target method is made by the test code as follows > > . . . > String[] ordinals = { "first", "second", "third" }; > log("calling testArrayCall"); > testArrayCall(ordinals); > log("called testArrayCall"); > . . . > > When this is run on JDK8[-] I see this output which matches expectation: > > > calling testArrayCall > args : [first, second, third] > inside testArrayCall > called testArrayCall > > > When I run this on JDK9 using a modified version of Byteman that relies > on MethodHandles I see this output: > > > calling testArrayCall > args : [[Ljava.lang.String;@36bc55de] > inside testArrayCall > called testArrayCall > > > So, the String[] array appears to have been wrapped in an Object[] > before being passed on to Arrays.asList(). > > > On JDK8[-] I use reflection to execute the method call. So, essentially > the code looks like this > > class MethodExpression { > Method method; > Expression recipient; > List arguments; > . . . > Object interpret(...) > . . . > Object recipientValue = > (recipient != null > ? recipient.interpret(...) > : null); > int argCount = arguments.size(); > Object[] argValues = new Object[argCount]; > for (int i = 0; i < argCount; i++) { > argValues[i] = arguments.get(i).interpret(...); > } > . . . > return method.invoke(recipientValue, argValues); > > The essential differences in the code that gets executed on JDK9 > (ignoring that I am inlining code here from different branches) are as > follows: > > class MethodExpression { > Method method; > MethodHandle handle = getMethodHandle(method); > List arguments; > . . . > Object interpret(...) > . . . > Object recipientValue = > (recipient != null > ? recipient.interpret(...) > : null); > int argCount = arguments.size(); > Object[] argValues = new Object[argCount]; > for (int i = 0; i < argCount; i++) { > argValues[i] = arguments.get(i).interpret(helper); > } > . . . > if (recipient == null) { > handle.invoke(argValues); > } else { > handle.invokeWithArguments(recipientValue, argValues); > } MH.invokeWithArguments doesn't work like Method.invoke, a MethodHandle is a function so any invoke* on a method handle is a function call, there is no method on a method handle that separates the receiver (what you call the recipientValue) from the arguments when performing a call. MH.invokeWithArguments takes an array of arguments but because it is specified as a varargs you may think that it works like Method.invoke, but it is a trap, it takes the receiver and the arguments altogether into the same array. so with a Stream it's something like: Object[] argValues = Stream.concat( Optional.ofNullable(recipient).map(r -> r.interpret(helper)).stream(), Arrays.stream(arguments).map(r -> r.interpret(helper)) ).toArray(Object[]::new); . . . handle.invokeWithArguments(argValues); > > regards, > > > Andrew Dinn regards, R?mi > ----------- > 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 john.r.rose at oracle.com Sat Nov 12 03:23:13 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 11 Nov 2016 19:23:13 -0800 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> References: <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> Message-ID: On Nov 11, 2016, at 7:09 AM, forax at univ-mlv.fr wrote: > MH.invokeWithArguments takes an array of arguments but because it is specified as a varargs you may think that it works like Method.invoke, but it is a trap, > it takes the receiver and the arguments altogether into the same array. Thanks, Remi. That should fix the problem. We thought a little bit about adding more overloadings to invokeWithArguments, such as one that works like Method.invoke (one prepended argument). The general case would be making invokeWithArguments be signature-polymorphic, with an on-the-fly asSpreader transform on the way through. But, such extra generality would simplify only a few use cases, and on the other hand it would probably create plenty of confusion whenever the target method is *also* a varargs method. ? John From forax at univ-mlv.fr Sat Nov 12 10:56:16 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 12 Nov 2016 11:56:16 +0100 (CET) Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> Message-ID: <1349280043.2378619.1478948176034.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "R?mi Forax" > Cc: "Andrew Dinn" , jigsaw-dev at openjdk.java.net > Envoy?: Samedi 12 Novembre 2016 04:23:13 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & > open packages > On Nov 11, 2016, at 7:09 AM, forax at univ-mlv.fr wrote: >> MH.invokeWithArguments takes an array of arguments but because it is specified >> as a varargs you may think that it works like Method.invoke, but it is a trap, >> it takes the receiver and the arguments altogether into the same array. > Thanks, Remi. That should fix the problem. > We thought a little bit about adding more overloadings to invokeWithArguments, > such as one that works like Method.invoke (one prepended argument). > The general case would be making invokeWithArguments be signature-polymorphic, > with an on-the-fly asSpreader transform on the way through. > But, such extra generality would simplify only a few use cases, and on the > other hand it would probably create plenty of confusion whenever the target > method is *also* a varargs method. The other solution is to have another non-polymorphic invoke method, invokeVirtualWithArguments that takes an instance and an array of objects like Method.invoke. But in my opinion, Method.invoke is a weird legacy format for a method call, separating the receiver from the other arguments is not natural for the VM, so this format should not have its own invoker. That said, it may help to rewrite the implementation of the reflection API to use method handles under the hood in order to remove the dedicated bytecode generator used by the current implementation. > ? John R?mi From stephen.felts at oracle.com Sat Nov 12 13:42:20 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Sat, 12 Nov 2016 05:42:20 -0800 (PST) Subject: javassist broken on Jake In-Reply-To: <1349280043.2378619.1478948176034.JavaMail.zimbra@u-pem.fr> References: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> <1349280043.2378619.1478948176034.JavaMail.zimbra@u-pem.fr> Message-ID: <7361bf48-b0db-411f-8710-ae0b4c30acf7@default> I've been trying to get a javassist that works in all environments. For a while, I created a multi release jar file that used Javassist 3.20 for pre-jdk9 and Javassist 3.21 for JDK9/Jake. The JDK team wasn't happy about this use of multi release jar files but it worked great. Then 3.22.0-CR1 was released and I thought the problem was solved. This is working for pre-JDK9 and JDK-9 but it's now failing on Jake (build 143). java.lang.NoSuchMethodError: java.lang.reflect.Layer.parent()Ljava/util/Optional; [exec] at javassist.ModuleClassPath.(ModuleClassPath.java:54) [exec] at javassist.ModuleClassPath.(ModuleClassPath.java:40) [exec] at javassist.LoaderClassPath.(LoaderClassPath.java:82) [exec] at javassist.ClassPoolTail.appendSystemPath(ClassPoolTail.java:248) [exec] at javassist.ClassPool.appendSystemPath(ClassPool.java:944) [exec] at javassist.ClassPool.(ClassPool.java:179) [exec] at org.glassfish.hk2.xml.tools.Hk2XmlGenerator.initializeHk2XmlGenerator(Hk2XmlGenerator.java:86) [exec] at org.glassfish.hk2.xml.tools.Hk2XmlGenerator.process(Hk2XmlGenerator.java:140) [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(JavacProcessingEnvironment.java:106) [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1182) [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1290) [exec] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1260) [exec] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:939) [exec] at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:304) [exec] at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:160) [exec] at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:55) [exec] at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:41) I guess I will need to go back to my 3.2021 for now. From claes.redestad at oracle.com Sat Nov 12 13:53:31 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 12 Nov 2016 14:53:31 +0100 Subject: javassist broken on Jake In-Reply-To: <7361bf48-b0db-411f-8710-ae0b4c30acf7@default> References: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> <1349280043.2378619.1478948176034.JavaMail.zimbra@u-pem.fr> <7361bf48-b0db-411f-8710-ae0b4c30acf7@default> Message-ID: <58271EDB.4060103@oracle.com> Hi, this appears to be due to the implementation of #NonHierarchicalLayers proposal which is now in jake: http://openjdk.java.net/projects/jigsaw/spec/issues/#NonHierarchicalLayers In short Optional Layer.parent() has been replaced by List Layer.parents() /Claes On 2016-11-12 14:42, Stephen Felts wrote: > I've been trying to get a javassist that works in all environments. > > For a while, I created a multi release jar file that used Javassist 3.20 for pre-jdk9 and Javassist 3.21 for JDK9/Jake. The JDK team wasn't happy about this use of multi release jar files but it worked great. > Then 3.22.0-CR1 was released and I thought the problem was solved. This is working for pre-JDK9 and JDK-9 but it's now failing on Jake (build 143). > > java.lang.NoSuchMethodError: java.lang.reflect.Layer.parent()Ljava/util/Optional; > [exec] at javassist.ModuleClassPath.(ModuleClassPath.java:54) > [exec] at javassist.ModuleClassPath.(ModuleClassPath.java:40) > [exec] at javassist.LoaderClassPath.(LoaderClassPath.java:82) > [exec] at javassist.ClassPoolTail.appendSystemPath(ClassPoolTail.java:248) > [exec] at javassist.ClassPool.appendSystemPath(ClassPool.java:944) > [exec] at javassist.ClassPool.(ClassPool.java:179) > [exec] at org.glassfish.hk2.xml.tools.Hk2XmlGenerator.initializeHk2XmlGenerator(Hk2XmlGenerator.java:86) > [exec] at org.glassfish.hk2.xml.tools.Hk2XmlGenerator.process(Hk2XmlGenerator.java:140) > [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) > [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) > [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(JavacProcessingEnvironment.java:106) > [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1182) > [exec] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1290) > [exec] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1260) > [exec] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:939) > [exec] at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:304) > [exec] at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:160) > [exec] at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:55) > [exec] at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:41) > > I guess I will need to go back to my 3.2021 for now. > From Alan.Bateman at oracle.com Sat Nov 12 14:17:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Nov 2016 14:17:23 +0000 Subject: javassist broken on Jake In-Reply-To: <7361bf48-b0db-411f-8710-ae0b4c30acf7@default> References: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> <1349280043.2378619.1478948176034.JavaMail.zimbra@u-pem.fr> <7361bf48-b0db-411f-8710-ae0b4c30acf7@default> Message-ID: On 12/11/2016 13:42, Stephen Felts wrote: > I've been trying to get a javassist that works in all environments. > > For a while, I created a multi release jar file that used Javassist 3.20 for pre-jdk9 and Javassist 3.21 for JDK9/Jake. The JDK team wasn't happy about this use of multi release jar files but it worked great. > Then 3.22.0-CR1 was released and I thought the problem was solved. This is working for pre-JDK9 and JDK-9 but it's now failing on Jake (build 143). > As Claes noted, this is a new API in JDK 9 that is not final yet so some churn is expected. It will be easier for Javassist once the API changes in jake get to JDK 9. In the mean-time, here is the issue in Javassist JIRA tracking this Mandy created it a few days ago): https://issues.jboss.org/browse/JASSIST-264 -Alan. From stephen.felts at oracle.com Sat Nov 12 14:42:46 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Sat, 12 Nov 2016 06:42:46 -0800 (PST) Subject: javassist broken on Jake In-Reply-To: References: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> <1349280043.2378619.1478948176034.JavaMail.zimbra@u-pem.fr> <7361bf48-b0db-411f-8710-ae0b4c30acf7@default> Message-ID: <4d5e068a-8a1b-491f-a133-932f6d88e42c@default> It turns out that the trick of using 3.21 doesn't work for Jake any more. So I guess there is no work-around for me on that platform and I won't be working on it. -----Original Message----- From: Alan Bateman Sent: Saturday, November 12, 2016 9:17 AM To: Stephen Felts; jigsaw-dev at openjdk.java.net Subject: Re: javassist broken on Jake On 12/11/2016 13:42, Stephen Felts wrote: > I've been trying to get a javassist that works in all environments. > > For a while, I created a multi release jar file that used Javassist 3.20 for pre-jdk9 and Javassist 3.21 for JDK9/Jake. The JDK team wasn't happy about this use of multi release jar files but it worked great. > Then 3.22.0-CR1 was released and I thought the problem was solved. This is working for pre-JDK9 and JDK-9 but it's now failing on Jake (build 143). > As Claes noted, this is a new API in JDK 9 that is not final yet so some churn is expected. It will be easier for Javassist once the API changes in jake get to JDK 9. In the mean-time, here is the issue in Javassist JIRA tracking this Mandy created it a few days ago): https://issues.jboss.org/browse/JASSIST-264 -Alan. From Alan.Bateman at oracle.com Sat Nov 12 18:07:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Nov 2016 18:07:21 +0000 Subject: javassist broken on Jake In-Reply-To: <4d5e068a-8a1b-491f-a133-932f6d88e42c@default> References: <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> <1349280043.2378619.1478948176034.JavaMail.zimbra@u-pem.fr> <7361bf48-b0db-411f-8710-ae0b4c30acf7@default> <4d5e068a-8a1b-491f-a133-932f6d88e42c@default> Message-ID: <28895be7-a5dd-27c2-48bc-709462233f5a@oracle.com> On 12/11/2016 14:42, Stephen Felts wrote: > It turns out that the trick of using 3.21 doesn't work for Jake any more. So I guess there is no work-around for me on that platform and I won't be working on it. > You may find that older versions (maybe 3.20 and older) will work okay with the jake builds, it's just the recent code where they are using APIs under development that will need updates until those APIs are final. Probably a topic for the Javassist mailing list rather than here. -Alan From alan.bateman at oracle.com Mon Nov 14 12:36:41 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Nov 2016 12:36:41 +0000 Subject: hg: jigsaw/jake/jdk: More javadoc fixes/clarifications Message-ID: <201611141236.uAECafWY004933@aojmv0008.oracle.com> Changeset: 9aa5eac9e756 Author: alanb Date: 2016-11-14 10:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9aa5eac9e756 More javadoc fixes/clarifications ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/reflect/Module.java From jan.lahoda at oracle.com Mon Nov 14 16:43:03 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 14 Nov 2016 16:43:03 +0000 Subject: hg: jigsaw/jake/langtools: Improving handling of resources in ClassFinder. Message-ID: <201611141643.uAEGh3kX004960@aojmv0008.oracle.com> Changeset: 6096c96e249a Author: jlahoda Date: 2016-11-14 17:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6096c96e249a Improving handling of resources in ClassFinder. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java From alex.buckley at oracle.com Mon Nov 14 23:20:27 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 14 Nov 2016 15:20:27 -0800 Subject: Compiling Java 9 In-Reply-To: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> Message-ID: <582A46BB.5060905@oracle.com> Hi Stephan, You have a lot of questions here, mainly not about the OpenJDK implementation of JSR 379 but rather about JSR 379 itself. I'm working on JLS text that will be presented alongside lang-vm.html in the next few weeks, but here are some quick points: - lang-vm.html does not say that restricted keywords are keywords only inside a module declaration; it says they are keywords _solely where they appear as terminals in ModuleDeclaration_. - Bear in mind that the JLS has always been very abstract about where source code comes from. For example, the storage of tokens matching CompilationUnit has never been mandated to be a file called XYZ on a hierarchical filesystem. (Note that JLS 7.6 merely allows the host system to _choose_ to enforce a particular rule.) Nor has a compiler been mandated to understand a "classpath", or a "sourcepath". With modules, the main JLS issue is that observability of compilation units is no longer the sole domain of the host system, or the same for all compilation units. For a compilation unit in a given module, the host system will be mandated to limit the compilation units which are observable based on the result of resolving the given module's dependencies with the Java Platform Module System. - Accessibility is a secondary issue because while it's changing in 6.6 to integrate modular exports, everything that relies on accessibility such as overload resolution in 15.12.2.1 then "just works". Yes, there are some references to 'public' which need to be qualified as 'public in an exported package', such as in 8.4.8[.*], but this is mostly mechanical. There are some technical changes to the scope of a top level package, but qualified names in general do not change their structure or meaning. Alex On 11/8/2016 10:28 AM, Stephan Herrmann wrote: > I'm wondering what will be expected from a compiler for Java 9. > I hope this is a suitable place to ask this kind of questions. > > > The first thing we know: a compiler has to be able to translate module-info.java (or whatever that file's name may be - btw: in absence of a definite rule, is a compiler expected to find module declarations in files of any possible name?). > > My first question concerns the grammar of module declarations: > I don't think the definition of "restricted keywords" and javac speak the same language. The only thing I can definitely infer from lang-vm.html is: restricted keywords are keywords only inside a module declaration (btw: how does the parser know, it's inside a module declaration?). By contrast javac implements a much more permissive strategy, almost s.t. like: "they are only keywords when they are keywords, otherwise they are identifiers". To wit, javac's parser happily accepts this declaration: > module module { // second word is an identifier > requires requires; // second word is an identifier > exports to to exports; // words #2 and #4 are identifiers > uses module; // second word is an identifier > provides uses with to; // words #2 and #4 are identifiers > } > This is not only very weird, there are lots of terminals in a module declaration where a restricted keyword is accepted as an identifier. It also breaks with standard compiler technology: it doesn't seem to be possible to use a traditional pipeline of scanner & parser, if the scanner cannot decide the kind of a token without consulting the parser (or keeping part of the parser state in the scanner itself). > This is to say: the strategy implemented by javac will affect all tool providers, not only compilers, but also editors etc. In absence of a stateless scanner, even syntax highlighting may not be possible without a full parser. Parsing in the presence of syntax errors (to offer IDE functionality on work-in-progress files) becomes close to impossible. > Have these consequences been carefully weighed? > > The next area where compilers will have to change is the new semantics of "accessible". Clearly, rules like JLS 6.6.1. (Determining Accessibility) and JLS 8.4.8.1. (Overriding (by Instance Methods)) need to be changed. > Has any of this work started yet? Can we have a look at any drafts? > > Next, I wonder, how much additional static validation compilers should perform. > For one, SOTMS speaks of "reliable configurations". Are compilers expected to check these rules? If so, have they been spelled out in checkable form somewhere (e.g., what is the meaning of "interfere" in the sentence "modules defining identically-named packages do not interfere with each other")? > Secondly, the concept of modules makes it possible to create new forms of "API leaks": expose a type, whose public signatures mention inaccessible types - maybe inaccessible only to some consumers. If you add overloading to the mix, this can create ugly effects, which may defeat benefits of modularity. > Is it planned that tools will help users to avoid such bogus situations? Or at least gracefully handle the case when it occurs? > Obviously, some validity constraints can be checked by tools other than the compiler, like linker or VM, but defining a module system as part of the language bears the unique opportunity to provide the most immediate feedback to users. Will this opportunity be used? > > > Other concerns are more of an organizational kind: > > What modules must be present to compile a given module? Is the set of (implied) readable dependencies sufficient, or is the compiler required to look at the full transitive closure? > Users coming from a plain-classpath world, may not expect much sophistication, but introducing a module system bears the unique opportunity to avoid the situation where building just one module triggers the download of huge amounts of transitive dependencies ("downloading the internet"). > Which is to say: Java 9 has the chance to significantly reduce the resource requirements (bandwidth, storage, main memory, compile time) for compiling any given module. > Any attempts in this direction seem to require a fresh look specifically at the interaction of accessibility and overloading. Has anything been planned/discussed in this direction? > > In Java 8, any package-qualified type name is sufficient for identifying a type during compilation. Will the same assumption also hold for compiling Java 9, or is a compiler required to distinguish identically named types from different modules? While this seems to be a question of compiler implementation only, it also seems the answer depends on answering most of the above questions, like additional static validation, the need to look at the transitive closure of module dependencies etc. > Most importantly, for implementing a compiler for Java 9 this question implies a very fundamental design decision, that should be made before any other changes towards Java 9. Changing a compiler implementation from package.type names to module.package.type names is a huge change that cannot be implemented as a quick after thought. > Have any amendments to JLS chapter 6 been drafted to define the new requirements for a compiler regarding qualified names? > > > regards, > Stephan > From stephan.herrmann at berlin.de Tue Nov 15 14:34:00 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 15 Nov 2016 15:34:00 +0100 Subject: Compiling Java 9 In-Reply-To: <582A46BB.5060905@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> Message-ID: <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> Hi Alex, On 11/15/2016 12:20 AM, Alex Buckley wrote: > You have a lot of questions here, mainly not about the OpenJDK implementation of JSR 379 but rather about JSR 379 itself. I'm > working on JLS text that will be presented alongside lang-vm.html in the next few weeks, but here are some quick points: I'm looking forward to the JLS text very much ... > - lang-vm.html does not say that restricted keywords are keywords only inside a module declaration; it says they are keywords > _solely where they appear as terminals in ModuleDeclaration_. Thanks, so for one this settles, that the compilation unit is irrelevant for the questions at hand, only the syntactical structure of the content is relevant, right? I'm still reluctant to believe the full consequences of what you seem to be saying. With ModuleDeclaration being a non-terminal in the grammar, is the definition of "restricted keywords" intended to mean: Whether or not a word is a keyword or identifier is decided *after* parsing has completed? Viz.: if a given text could be parsed as a ModuleDeclaration then exactly those words that have been used as keywords are keywords. It seems so, because before parsing we don't have any knowledge whether or not a given text *is* a ModuleDeclaration. Is it even justified to speak of "parsing" in this context? Syntax inference? The current grammar can be parsed, e.g., with a hand-written scannerless parser, but can we assume any regularities about the grammar now and in the future? If not, should all tool implementers be prepared to replace the parser with full pattern matching with back tracking, as to try all possible combinations of interpreting keyword candidates as keywords or identifiers? Thinking aloud about possible consequences, I wonder what happens in case of a syntax error. Strictly speaking a text that almost looks like a ModuleDeclaration but still cannot be fully accepted as such, contains no keywords at all (because we have no ModuleDeclaration), right? That's probably a fact which tools should carefully hide from users, to avoid producing utterly confusing error messages. Generally speaking, the only "correct" syntax error message seems to be: "the input text could not be matched as a ModuleDeclaration". Picking on words, I still hold that my example contains restricted keywords as terminals in a ModuleDeclaration where they are apparently interpreted (by javac) as identifiers: module module { // second word is an identifier requires requires; // second word is an identifier exports to to exports; // words #2 and #4 are identifiers uses module; // second word is an identifier provides uses with to; // words #2 and #4 are identifiers } So, am I possibly still barking up the wrong tree? Or should the definition really say "where they appear as _keywords_ in ModuleDeclaration" ? thanks, Stephan From james.laskey at oracle.com Tue Nov 15 14:39:07 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 15 Nov 2016 10:39:07 -0400 Subject: RFR: JDK-8169720 - jimage help message for --include option should be corrected Message-ID: http://cr.openjdk.java.net/~jlaskey/8169720/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8169720 From Alan.Bateman at oracle.com Tue Nov 15 14:42:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Nov 2016 14:42:25 +0000 Subject: RFR: JDK-8169720 - jimage help message for --include option should be corrected In-Reply-To: References: Message-ID: <70353126-3ff3-0242-7d33-912d989eea90@oracle.com> On 15/11/2016 14:39, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8169720/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8169720 > Looks fine. From sundararajan.athijegannathan at oracle.com Tue Nov 15 14:50:02 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 15 Nov 2016 20:20:02 +0530 Subject: RFR: JDK-8169720 - jimage help message for --include option should be corrected In-Reply-To: References: Message-ID: <2ed7d3ca-847c-aab2-7296-2ad8a110b46a@oracle.com> +1 On 11/15/2016 8:09 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8169720/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8169720 > From denis.kononenko at oracle.com Tue Nov 15 15:16:23 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Tue, 15 Nov 2016 07:16:23 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: Hi, Please do re-review for these changes. 1) tests for list --include were rewritten accordingly to https://bugs.openjdk.java.net/browse/JDK-8167384; 2) removed tests for '@filename', see https://bugs.openjdk.java.net/browse/JDK-8169720; 3) two new CRs were submitted: https://bugs.openjdk.java.net/browse/JDK-8169715, https://bugs.openjdk.java.net/browse/JDK-8169713; WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.04/ BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 Thank you, Denis. > Hi Andrey, > > No, it isn't. I submitted a new CR: > https://bugs.openjdk.java.net/browse/JDK-8167384. > > Thank you, > Denis. > > > Hi, > > > > Looks OK. Is it 100% pass rate? > > > > ?Andrey > > > On 9 Nov 2016, at 20:36, Denis Kononenko > > wrote: > > > > > > > > > > > > Hi, > > > > > > After discussion with Andrey we decided to add more tests for > corner > > cases. > > > The new changes are available by the link below. > > > > > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > > > > > > > Thank you, > > > Denis. > > > > > >> Hi, > > >> > > >> Looks OK to me. > > >> I can suggest two more cases. A directory and file symlink can > be > > >> passed in options where tool requires a file path. > > >> > > >> ?Andrey > > >> > > >>> On 8 Nov 2016, at 16:17, Denis Kononenko > > >> wrote: > > >>> > > >>> > > >>> Hi, > > >>> > > >>> The new version of changes. > > >>> > > >>> - Switched back to jdk/test/testlibrary to avoid unwanted > > >> dependencies (JImageToolTest.java); > > >>> - Verified tests on smallest possible JDK build. > > >>> > > >>> WEBREV: > http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > > >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > >>> > > >>> Thank you, > > >>> Denis. > > >>> > > >>>> Denis, > > >>>> > > >>>> I can see that you have switched to the top level test library > > >> with > > >>>> this change. With that you are getting more module > dependencies > > >> than > > >>>> just java.base. First of all, it would probably make sense to > > >> build > > >>>> only the classes you needed (which would be > > >>>> jdk.test.lib.process.ProcessTools, I assume), but even if you > > only > > >>>> build that, jdk.test.lib.process.ProcessTools has dependencies > > >> outside > > >>>> java.base module. > > >>>> > > >>>> You either have to declare @modules in your test or go back to > > the > > >>>> jdk/test/lib/testlibrary. Then, of course, unneeded module > > >>>> dependencies are questionable. > > >>>> > > >>>> Shura > > >>>> > > >>>> > > >>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko > > >>>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> I've done some rework accordingly to Alan's and Shura's > > comments: > > >>>>> > > >>>>> 1) removed overlapped tests from JImageToolTest.java; > > >>>>> > > >>>>> 2) added new tests JImageVerifyTest.java for jimage verify; > > >>>>> > > >>>>> 3) reorganized jtreg's tags; > > >>>>> > > >>>>> The new WEBREV can be found here: > > >>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > >>>>> > > >>>>> Thank you, > > >>>>> Denis. > > >>>>> > > >>>>> On 06.10.2016 19:37, Denis Kononenko wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> Could someone please review these new tests for jimage > > utility. > > >>>>>> > > >>>>>> There're 5 new files containing tests to cover use cases for > > >>>> 'info', 'list', 'extract' and other options. No new tests for > > >>>> 'verify'. > > >>>>>> > > >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > >>>>>> WEBREV: > > >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > > >>>>>> > > >>>>>> > > >>>>>> Thank you, > > >>>>>> Denis. > > >>>>> From james.laskey at oracle.com Tue Nov 15 15:29:10 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 15 Nov 2016 11:29:10 -0400 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: References: Message-ID: <57088D50-8B9C-417C-90A8-996AAA6EF44D@oracle.com> +1 Really nice, thank you. > On Nov 15, 2016, at 11:16 AM, Denis Kononenko wrote: > > > Hi, > > Please do re-review for these changes. > > 1) tests for list --include were rewritten accordingly to https://bugs.openjdk.java.net/browse/JDK-8167384; > 2) removed tests for '@filename', see https://bugs.openjdk.java.net/browse/JDK-8169720; > 3) two new CRs were submitted: https://bugs.openjdk.java.net/browse/JDK-8169715, https://bugs.openjdk.java.net/browse/JDK-8169713; > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.04/ > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > Thank you, > Denis. > > >> Hi Andrey, >> >> No, it isn't. I submitted a new CR: >> https://bugs.openjdk.java.net/browse/JDK-8167384. >> >> Thank you, >> Denis. >> >>> Hi, >>> >>> Looks OK. Is it 100% pass rate? >>> >>> ?Andrey >>>> On 9 Nov 2016, at 20:36, Denis Kononenko >>> wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> After discussion with Andrey we decided to add more tests for >> corner >>> cases. >>>> The new changes are available by the link below. >>>> >>>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>> >>>> >>>> Thank you, >>>> Denis. >>>> >>>>> Hi, >>>>> >>>>> Looks OK to me. >>>>> I can suggest two more cases. A directory and file symlink can >> be >>>>> passed in options where tool requires a file path. >>>>> >>>>> ?Andrey >>>>> >>>>>> On 8 Nov 2016, at 16:17, Denis Kononenko >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> The new version of changes. >>>>>> >>>>>> - Switched back to jdk/test/testlibrary to avoid unwanted >>>>> dependencies (JImageToolTest.java); >>>>>> - Verified tests on smallest possible JDK build. >>>>>> >>>>>> WEBREV: >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>>>> >>>>>> Thank you, >>>>>> Denis. >>>>>> >>>>>>> Denis, >>>>>>> >>>>>>> I can see that you have switched to the top level test library >>>>> with >>>>>>> this change. With that you are getting more module >> dependencies >>>>> than >>>>>>> just java.base. First of all, it would probably make sense to >>>>> build >>>>>>> only the classes you needed (which would be >>>>>>> jdk.test.lib.process.ProcessTools, I assume), but even if you >>> only >>>>>>> build that, jdk.test.lib.process.ProcessTools has dependencies >>>>> outside >>>>>>> java.base module. >>>>>>> >>>>>>> You either have to declare @modules in your test or go back to >>> the >>>>>>> jdk/test/lib/testlibrary. Then, of course, unneeded module >>>>>>> dependencies are questionable. >>>>>>> >>>>>>> Shura >>>>>>> >>>>>>> >>>>>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've done some rework accordingly to Alan's and Shura's >>> comments: >>>>>>>> >>>>>>>> 1) removed overlapped tests from JImageToolTest.java; >>>>>>>> >>>>>>>> 2) added new tests JImageVerifyTest.java for jimage verify; >>>>>>>> >>>>>>>> 3) reorganized jtreg's tags; >>>>>>>> >>>>>>>> The new WEBREV can be found here: >>>>>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Denis. >>>>>>>> >>>>>>>> On 06.10.2016 19:37, Denis Kononenko wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could someone please review these new tests for jimage >>> utility. >>>>>>>>> >>>>>>>>> There're 5 new files containing tests to cover use cases for >>>>>>> 'info', 'list', 'extract' and other options. No new tests for >>>>>>> 'verify'. >>>>>>>>> >>>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>>>>>>> WEBREV: >>>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Denis. >>>>>>>> From james.laskey at oracle.com Tue Nov 15 17:57:08 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 15 Nov 2016 13:57:08 -0400 Subject: RFR: JDK-8169505 - Update changes by JDK-8159393 to reflect CCC review Message-ID: http://cr.openjdk.java.net/~jlaskey/8169505/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8169505 From sundararajan.athijegannathan at oracle.com Wed Nov 16 08:30:17 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Nov 2016 14:00:17 +0530 Subject: RFR 8153038: The set of jlink plugins enabled by default should be the same via CLI or jlink API Message-ID: <582C1919.5000204@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8153038/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8153038 PS. Pre-existing IntegrationTest.java test already checks the Jlink API code path [so, no new test added]. Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Wed Nov 16 08:25:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Nov 2016 13:55:04 +0530 Subject: RFR: JDK-8169505 - Update changes by JDK-8159393 to reflect CCC review In-Reply-To: References: Message-ID: +1 -Sundar On 11/15/2016 11:27 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8169505/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8169505 > > From forax at univ-mlv.fr Wed Nov 16 09:48:19 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Nov 2016 10:48:19 +0100 (CET) Subject: uses is useless ? Message-ID: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> Hi guys, sorry for the pun in the title. Last week end, i've taken a big codebase and try to retrofit it to use jigsaw, obviously the code has several (two in fact) cyclic dependencies and in both cases, i was able to break those cycles by changing the code to use services. In one case, i have wanted to write a small code that uses the ServiceLoader like DriverManager.drivers() to expose the service but if i do that, it's the module that contains that small code that has to declare the directive 'uses' inside its own module-info instead of being the code that effectively uses the service, which seems wrong to me *. So i think where missing an API point on ServiceLoader that allow to write a method that will ask for a directive uses on the behalf of the ServiceLoader. I think it's a good idea to leverage Lookup class here and add a method load(Class, Lookup) that load a service on the behalf to the lookup class and requires the module of the lookup class to declare a directive uses. cheers, R?mi * it's definitevly wrong because when i wanted to use jlink on the code to generate a kind of light version of the application, i was not able to know which modules was using the service to pass them as root modules to jlink. From forax at univ-mlv.fr Wed Nov 16 09:53:58 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Nov 2016 10:53:58 +0100 (CET) Subject: jlink option --add-modules should be renamed to --add-root-modules Message-ID: <1983278401.1633394.1479290038924.JavaMail.zimbra@u-pem.fr> Hi all, it's a minor request, but the option --add-modules should be renamed to --add-root-modules because as the doc says it specifies the "Root modules to resolve". Several students of mine had trouble to see the difference between --add-modules and --module-path because of that (and yes they should have read the doc). regards, R?mi From Alan.Bateman at oracle.com Wed Nov 16 10:09:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2016 10:09:40 +0000 Subject: uses is useless ? In-Reply-To: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> Message-ID: <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> On 16/11/2016 09:48, Remi Forax wrote: > Hi guys, > sorry for the pun in the title. > > Last week end, i've taken a big codebase and try to retrofit it to use jigsaw, > obviously the code has several (two in fact) cyclic dependencies and in both cases, i was able to break those cycles by changing the code to use services. Good to hear this. > In one case, i have wanted to write a small code that uses the ServiceLoader like DriverManager.drivers() to expose the service but if i do that, > it's the module that contains that small code that has to declare the directive 'uses' inside its own module-info instead of being the code that effectively uses the service, > which seems wrong to me *. I assume you are looking for Module::addUses which is useful when libraries are using ServiceLoader on behalf of someone else. In these scenarios then someone needs to declare that the `uses` of course, otherwise the service provider modules won't be resolved. As regards the hygiene check in ServiceLoader then it is not strictly needed but it has been very useful to identify cases where `uses` is missing from the module declaration. > > So i think where missing an API point on ServiceLoader that allow to write a method that will ask for a directive uses on the behalf of the ServiceLoader. > > I think it's a good idea to leverage Lookup class here and add a method load(Class, Lookup) that load a service on the behalf to the lookup class and requires the module of the lookup class to declare a directive uses. > > cheers, > R?mi > > * it's definitevly wrong because when i wanted to use jlink on the code to generate a kind of light version of the application, i was not able to know which modules was using the service to pass them as root modules to jlink. > jlink does not do service binding and you'll see in JEP 282 that there is an open issue on whether to provide an option to help identify the service provider modules to link into the image. -Alan From Alan.Bateman at oracle.com Wed Nov 16 10:13:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2016 10:13:44 +0000 Subject: jlink option --add-modules should be renamed to --add-root-modules In-Reply-To: <1983278401.1633394.1479290038924.JavaMail.zimbra@u-pem.fr> References: <1983278401.1633394.1479290038924.JavaMail.zimbra@u-pem.fr> Message-ID: <68d00039-6dfa-860f-86f0-5dc520f45553@oracle.com> On 16/11/2016 09:53, Remi Forax wrote: > Hi all, > it's a minor request, but the option --add-modules should be renamed to --add-root-modules because as the doc says it specifies the "Root modules to resolve". Several students of mine had trouble to see the difference between --add-modules and --module-path because of that (and yes they should have read the doc). > --add-roots was suggested at one point. In any case, the options needs to be consistent (we can't rename the option in jlink without also changing it in javac and the java launcher for example). -Alan From forax at univ-mlv.fr Wed Nov 16 10:20:22 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 16 Nov 2016 11:20:22 +0100 (CET) Subject: jlink option --add-modules should be renamed to --add-root-modules In-Reply-To: <68d00039-6dfa-860f-86f0-5dc520f45553@oracle.com> References: <1983278401.1633394.1479290038924.JavaMail.zimbra@u-pem.fr> <68d00039-6dfa-860f-86f0-5dc520f45553@oracle.com> Message-ID: <1259891506.1681892.1479291622423.JavaMail.zimbra@u-pem.fr> yes ! R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "jigsaw-dev" > Envoy?: Mercredi 16 Novembre 2016 11:13:44 > Objet: Re: jlink option --add-modules should be renamed to --add-root-modules > On 16/11/2016 09:53, Remi Forax wrote: > >> Hi all, >> it's a minor request, but the option --add-modules should be renamed to >> --add-root-modules because as the doc says it specifies the "Root modules to >> resolve". Several students of mine had trouble to see the difference between >> --add-modules and --module-path because of that (and yes they should have read >> the doc). >> > --add-roots was suggested at one point. In any case, the options needs > to be consistent (we can't rename the option in jlink without also > changing it in javac and the java launcher for example). > > -Alan From alan.bateman at oracle.com Wed Nov 16 10:22:17 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 Nov 2016 10:22:17 +0000 Subject: hg: jigsaw/jake/hotspot: JDI/JDWP CanRead command not needed Message-ID: <201611161022.uAGAMHLC003729@aojmv0008.oracle.com> Changeset: 96d200831568 Author: alanb Date: 2016-11-16 10:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/96d200831568 JDI/JDWP CanRead command not needed Contributed-by: serguei.spitsyn at oracle.com ! test/serviceability/jdwp/AllModulesCommandTest.java - test/serviceability/jdwp/JdwpCanReadCmd.java - test/serviceability/jdwp/JdwpCanReadReply.java From alan.bateman at oracle.com Wed Nov 16 10:22:49 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 Nov 2016 10:22:49 +0000 Subject: hg: jigsaw/jake/jdk: JDI/JDWP CanRead command not needed Message-ID: <201611161022.uAGAMniQ003882@aojmv0008.oracle.com> Changeset: d6531596d65f Author: alanb Date: 2016-11-16 10:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6531596d65f JDI/JDWP CanRead command not needed Contributed-by: serguei.spitsyn at oracle.com ! make/data/jdwp/jdwp.spec ! src/jdk.jdi/share/classes/com/sun/jdi/ModuleReference.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ModuleReferenceImpl.java ! src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c ! test/com/sun/jdi/ModulesTest.java From forax at univ-mlv.fr Wed Nov 16 10:25:49 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 16 Nov 2016 11:25:49 +0100 (CET) Subject: uses is useless ? In-Reply-To: <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> Message-ID: <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" > Cc: "jigsaw-dev" > Envoy?: Mercredi 16 Novembre 2016 11:09:40 > Objet: Re: uses is useless ? > On 16/11/2016 09:48, Remi Forax wrote: > >> Hi guys, >> sorry for the pun in the title. >> >> Last week end, i've taken a big codebase and try to retrofit it to use jigsaw, >> obviously the code has several (two in fact) cyclic dependencies and in both >> cases, i was able to break those cycles by changing the code to use services. > Good to hear this. > >> In one case, i have wanted to write a small code that uses the ServiceLoader >> like DriverManager.drivers() to expose the service but if i do that, >> it's the module that contains that small code that has to declare the directive >> 'uses' inside its own module-info instead of being the code that effectively >> uses the service, >> which seems wrong to me *. > I assume you are looking for Module::addUses which is useful when > libraries are using ServiceLoader on behalf of someone else. In these > scenarios then someone needs to declare that the `uses` of course, > otherwise the service provider modules won't be resolved. > > As regards the hygiene check in ServiceLoader then it is not strictly > needed but it has been very useful to identify cases where `uses` is > missing from the module declaration. The whole point of uses is to enable a kind of static analysis on the service dependencies, if 'uses' is not required, if you can easily bypass it or it doesn't provide useful information, then it should be removed from the spec. > >> >> So i think where missing an API point on ServiceLoader that allow to write a >> method that will ask for a directive uses on the behalf of the ServiceLoader. >> >> I think it's a good idea to leverage Lookup class here and add a method >> load(Class, Lookup) that load a service on the behalf to the lookup class and >> requires the module of the lookup class to declare a directive uses. >> >> cheers, >> R?mi >> >> * it's definitevly wrong because when i wanted to use jlink on the code to >> generate a kind of light version of the application, i was not able to know >> which modules was using the service to pass them as root modules to jlink. >> > jlink does not do service binding and you'll see in JEP 282 that there > is an open issue on whether to provide an option to help identify the > service provider modules to link into the image. Yes, jlink doesn't do that, but my tool on top of jlink does it :) But as i said above, if the information given by 'uses' do not allow to do static analysis like finding the root modules (services included), it perhaps means that 'uses' doesn't worth its own weight. > > -Alan R?mi From Alan.Bateman at oracle.com Wed Nov 16 10:44:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2016 10:44:21 +0000 Subject: uses is useless ? In-Reply-To: <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> Message-ID: <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> On 16/11/2016 10:25, forax at univ-mlv.fr wrote: > : > The whole point of uses is to enable a kind of static analysis on the service dependencies, > if 'uses' is not required, if you can easily bypass it or it doesn't provide useful information, > then it should be removed from the spec. `uses` is used to link the consumers of services to the providers of services. If nobody `uses S` then the modules that `provides S with ...` will not be resolved (assuming nobody directly depends on these service provider modules). The scenario where a framework uses ServiceLoader on behalf of a consumer really needs the consumer to declare that it uses the service type, otherwise there is no guarantee that the modules that provide implementation of the service will be resolved. > : > Yes, jlink doesn't do that, but my tool on top of jlink does it :) > But as i said above, if the information given by 'uses' do not allow to do static analysis like finding the root modules (services included), it perhaps means that 'uses' doesn't worth its own weight. jlink could do service binding (s/resolveRequires/resolveRequiresAndUses) but all the initial feedback was that people wanted the minimum number of modules in the image. It's not hard to have jlink make some suggestions, it just hasn't been implemented (this is what the open issue in JEP 282 is about). -Alan From alan.bateman at oracle.com Wed Nov 16 11:42:28 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 Nov 2016 11:42:28 +0000 Subject: hg: jigsaw/jake/jdk: Move parsing of --patch-module to ModuleBootstrap Message-ID: <201611161142.uAGBgSRi021726@aojmv0008.oracle.com> Changeset: 89cca729dfc1 Author: alanb Date: 2016-11-16 10:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89cca729dfc1 Move parsing of --patch-module to ModuleBootstrap ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/Modules.java From james.laskey at oracle.com Wed Nov 16 12:45:08 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 16 Nov 2016 08:45:08 -0400 Subject: RFR 8153038: The set of jlink plugins enabled by default should be the same via CLI or jlink API In-Reply-To: <582C1919.5000204@oracle.com> References: <582C1919.5000204@oracle.com> Message-ID: <98DA663A-6AEA-4D65-B6A6-F385C71A1301@oracle.com> +1 > On Nov 16, 2016, at 4:30 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8153038/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8153038 > > PS. Pre-existing IntegrationTest.java test already checks the Jlink API code path [so, no new test added]. > > Thanks, > -Sundar From sander.mak at luminis.eu Wed Nov 16 13:29:41 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Wed, 16 Nov 2016 13:29:41 +0000 Subject: jlink option --add-modules should be renamed to --add-root-modules In-Reply-To: <1983278401.1633394.1479290038924.JavaMail.zimbra@u-pem.fr> References: <1983278401.1633394.1479290038924.JavaMail.zimbra@u-pem.fr> Message-ID: I think --add-root-modules would be an improvement, too. Sander > On 16 Nov 2016, at 10:53, Remi Forax wrote: > > Hi all, > it's a minor request, but the option --add-modules should be renamed to --add-root-modules because as the doc says it specifies the "Root modules to resolve". Several students of mine had trouble to see the difference between --add-modules and --module-path because of that (and yes they should have read the doc). > > regards, > R?mi > > From alan.bateman at oracle.com Wed Nov 16 13:32:12 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 Nov 2016 13:32:12 +0000 Subject: hg: jigsaw/jake/hotspot: Realign --patch-module with JEP 261 Message-ID: <201611161332.uAGDWCTC019190@aojmv0008.oracle.com> Changeset: 5dcc850b3457 Author: alanb Date: 2016-11-16 13:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5dcc850b3457 Realign --patch-module with JEP 261 ! test/runtime/modules/IgnoreModulePropertiesTest.java From harold.seigel at oracle.com Wed Nov 16 13:49:28 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 16 Nov 2016 13:49:28 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201611161349.uAGDnS8L022489@aojmv0008.oracle.com> Changeset: cb0712bd2538 Author: gtriantafill Date: 2016-11-16 08:04 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cb0712bd2538 8169328: Change hotspot tests to use new --add-opens options Summary: Replace --add-exports-private with --add-opens, replace :private in @modules with :open Reviewed-by: hseigel ! src/share/vm/runtime/arguments.cpp ! test/compiler/c2/Test7190310_unsafe.java ! test/compiler/codegen/Test8011901.java ! test/compiler/escapeAnalysis/TestUnsafePutAddressNullObjMustNotEscape.java ! test/compiler/intrinsics/bigInteger/MontgomeryMultiplyTest.java ! test/compiler/intrinsics/unsafe/AllocateUninitializedArray.java ! test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java ! test/compiler/intrinsics/unsafe/UnsafeGetAddressTest.java ! test/compiler/intrinsics/unsafe/UnsafeTwoCASLong.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetSymbolTest.java ! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java ! test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java ! test/compiler/rangechecks/TestExplicitRangeChecks.java ! test/compiler/runtime/Test8010927.java ! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestByte.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestChar.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestDouble.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestFloat.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestInt.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestLong.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestObject.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestShort.java ! test/compiler/unsafe/JdkInternalMiscUnsafeUnalignedAccess.java ! test/compiler/unsafe/TestUnsafeLoadControl.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/runtime/LocalLong/LocalLongTest.java ! test/runtime/Throwable/StackTraceLogging.java ! test/runtime/Throwable/TestThrowable.java ! test/runtime/Throwable/ThrowableIntrospectionSegfault.java ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/serviceability/attach/AttachWithStalePidFile.java ! test/serviceability/sa/TestInstanceKlassSize.java ! test/serviceability/sa/TestInstanceKlassSizeForInterface.java Changeset: 4a5a911c810a Author: hseigel Date: 2016-11-16 08:40 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4a5a911c810a Merge From david.lloyd at redhat.com Wed Nov 16 14:00:14 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 16 Nov 2016 08:00:14 -0600 Subject: uses is useless ? In-Reply-To: <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> Message-ID: On 11/16/2016 04:44 AM, Alan Bateman wrote: > On 16/11/2016 10:25, forax at univ-mlv.fr wrote: > >> : >> The whole point of uses is to enable a kind of static analysis on the >> service dependencies, >> if 'uses' is not required, if you can easily bypass it or it doesn't >> provide useful information, >> then it should be removed from the spec. > `uses` is used to link the consumers of services to the providers of > services. If nobody `uses S` then the modules that `provides S with ...` > will not be resolved (assuming nobody directly depends on these service > provider modules). > > The scenario where a framework uses ServiceLoader on behalf of a > consumer really needs the consumer to declare that it uses the service > type, otherwise there is no guarantee that the modules that provide > implementation of the service will be resolved. That's really a usability regression though, isn't it? In the past, I could always use ServiceLoader with a ClassLoader argument to specify on whose behalf I'm loading. In fact we do this quite a lot today. -- - DML From Alan.Bateman at oracle.com Wed Nov 16 14:06:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2016 14:06:40 +0000 Subject: uses is useless ? In-Reply-To: References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> Message-ID: <9138774f-9e97-6f3f-c9cf-ccfe3309ac8b@oracle.com> On 16/11/2016 14:00, David M. Lloyd wrote: > > That's really a usability regression though, isn't it? In the past, I > could always use ServiceLoader with a ClassLoader argument to specify > on whose behalf I'm loading. In fact we do this quite a lot today. > No change to existing code on the class path, the question only comes up when migrating to an explicit module (meaning you are writing a module declaration). It's a reasonable question to ask of course. -Alan From david.lloyd at redhat.com Wed Nov 16 14:36:53 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 16 Nov 2016 08:36:53 -0600 Subject: uses is useless ? In-Reply-To: <9138774f-9e97-6f3f-c9cf-ccfe3309ac8b@oracle.com> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> <9138774f-9e97-6f3f-c9cf-ccfe3309ac8b@oracle.com> Message-ID: <09c54d91-b9f1-84ae-9fbc-d9a55defda86@redhat.com> On 11/16/2016 08:06 AM, Alan Bateman wrote: > On 16/11/2016 14:00, David M. Lloyd wrote: > >> >> That's really a usability regression though, isn't it? In the past, I >> could always use ServiceLoader with a ClassLoader argument to specify >> on whose behalf I'm loading. In fact we do this quite a lot today. >> > No change to existing code on the class path, the question only comes up > when migrating to an explicit module (meaning you are writing a module > declaration). It's a reasonable question to ask of course. Of course, but assuming one ports existing code to be modular and expect to live in a modular environment, it's still perfectly reasonable to want to load services on behalf of another module. I disagree with using Lookup for this purpose, but a simple method (even on Module itself) to create a service loader from that module's perspective would be very useful for this. In fact we do this in JBoss Modules. -- - DML From james.laskey at oracle.com Wed Nov 16 15:00:52 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 16 Nov 2016 11:00:52 -0400 Subject: RFR: JDK-8168256 - Plugin alias options in jlink --help output seems to be in an arbitrary order Message-ID: Sorts options by full name http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8168256 From mandy.chung at oracle.com Wed Nov 16 16:51:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Nov 2016 08:51:26 -0800 Subject: RFR 8153038: The set of jlink plugins enabled by default should be the same via CLI or jlink API In-Reply-To: <582C1919.5000204@oracle.com> References: <582C1919.5000204@oracle.com> Message-ID: <5768F785-D5E0-48D5-A853-1901152B1190@oracle.com> Looks okay. Mandy > On Nov 16, 2016, at 12:30 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8153038/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8153038 > > PS. Pre-existing IntegrationTest.java test already checks the Jlink API code path [so, no new test added]. > > Thanks, > -Sundar From harold.seigel at oracle.com Wed Nov 16 18:15:56 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 16 Nov 2016 18:15:56 +0000 Subject: hg: jigsaw/jake/hotspot: 8169328: Change hotspot tests to use new --add-opens options Message-ID: <201611161815.uAGIFu3d028710@aojmv0008.oracle.com> Changeset: 60ab9a59cfb9 Author: hseigel Date: 2016-11-16 13:05 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/60ab9a59cfb9 8169328: Change hotspot tests to use new --add-opens options Summary: Restore previous change that removed --add-exports-private support Reviewed-by: lfoltan ! src/share/vm/runtime/arguments.cpp From alan.bateman at oracle.com Wed Nov 16 18:19:36 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 Nov 2016 18:19:36 +0000 Subject: hg: jigsaw/jake/jdk: Realign --patch-module with JEP 261 Message-ID: <201611161819.uAGIJaAk029524@aojmv0008.oracle.com> Changeset: 01398d0dc8ef Author: alanb Date: 2016-11-16 13:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01398d0dc8ef Realign --patch-module with JEP 261 ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java From mandy.chung at oracle.com Wed Nov 16 19:19:05 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Nov 2016 19:19:05 +0000 Subject: hg: jigsaw/jake/jdk: Fix tests to use --add-opens Message-ID: <201611161919.uAGJJ5FU013860@aojmv0008.oracle.com> Changeset: ad153b3d457d Author: mchung Date: 2016-11-16 11:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ad153b3d457d Fix tests to use --add-opens ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/java/util/ResourceBundle/modules/unnamed/unnamed.sh From forax at univ-mlv.fr Wed Nov 16 19:41:17 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 16 Nov 2016 20:41:17 +0100 (CET) Subject: uses is useless ? In-Reply-To: <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> Message-ID: <1427011145.2137503.1479325277850.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: forax at univ-mlv.fr > Cc: "jigsaw-dev" > Envoy?: Mercredi 16 Novembre 2016 11:44:21 > Objet: Re: uses is useless ? > On 16/11/2016 10:25, forax at univ-mlv.fr wrote: > >> : >> The whole point of uses is to enable a kind of static analysis on the service >> dependencies, >> if 'uses' is not required, if you can easily bypass it or it doesn't provide >> useful information, >> then it should be removed from the spec. > `uses` is used to link the consumers of services to the providers of > services. If nobody `uses S` then the modules that `provides S with ...` > will not be resolved (assuming nobody directly depends on these service > provider modules). My point is that in teory, that's cool but in reality the module-info of java.base (or java.sql) declares a lot of 'uses' making the whole idea moot. To avoid java.base to use 'uses', we need a way to be able to have a way to delegate the power of the ServiceLoader to another code, so the other code will have to use 'uses'. > > The scenario where a framework uses ServiceLoader on behalf of a > consumer really needs the consumer to declare that it uses the service > type, otherwise there is no guarantee that the modules that provide > implementation of the service will be resolved. yes ! if a class calls DriverManager.drivers(), 'uses' should be defined on the module of the class and not on the module of DriverManager, as this is currently the case. R?mi > >> : >> Yes, jlink doesn't do that, but my tool on top of jlink does it :) >> But as i said above, if the information given by 'uses' do not allow to do >> static analysis like finding the root modules (services included), it perhaps >> means that 'uses' doesn't worth its own weight. > jlink could do service binding > (s/resolveRequires/resolveRequiresAndUses) but all the initial feedback > was that people wanted the minimum number of modules in the image. It's > not hard to have jlink make some suggestions, it just hasn't been > implemented (this is what the open issue in JEP 282 is about). > > -Alan From alex.buckley at oracle.com Wed Nov 16 21:02:14 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Nov 2016 13:02:14 -0800 Subject: Compiling Java 9 In-Reply-To: <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> Message-ID: <582CC956.3080202@oracle.com> On 11/15/2016 6:34 AM, Stephan Herrmann wrote: > On 11/15/2016 12:20 AM, Alex Buckley wrote: >> You have a lot of questions here, mainly not about the OpenJDK >> implementation of JSR 379 but rather about JSR 379 itself. I'm >> working on JLS text that will be presented alongside lang-vm.html in >> the next few weeks, but here are some quick points: > > I'm looking forward to the JLS text very much ... (Oops, I meant JSR 376 (Module System) rather than 379 (SE 9 Platform).) >> - lang-vm.html does not say that restricted keywords are keywords only >> inside a module declaration; it says they are keywords >> _solely where they appear as terminals in ModuleDeclaration_. > > Thanks, so for one this settles, that the compilation unit is > irrelevant for the questions at hand, only the syntactical structure > of the content is relevant, right? I get the feeling that by "compilation unit" you mean "file on disk", but I never mean that. A compilation unit is a sequence of tokens (technically, input elements per JLS 3.5) that matches the CompilationUnit production; I have no interest in whether the sequence comes from a file, and if it does, what that file's name is. As to matching the sequence to one of the two alternatives for CompilationUnit: > I'm still reluctant to believe the full consequences of what you seem > to be saying. With ModuleDeclaration being a non-terminal in the > grammar, is the definition of "restricted keywords" intended to mean: > Whether or not a word is a keyword or identifier is decided *after* > parsing has completed? > Viz.: if a given text could be parsed as a ModuleDeclaration then > exactly those words that have been used as keywords are keywords. > It seems so, because before parsing we don't have any knowledge > whether or not a given text *is* a ModuleDeclaration. Is it even > justified to speak of "parsing" in this context? Syntax inference? - If you lex 'package', then the sequence must parse as the first alternative. - If you don't lex 'package', but rather lex 'import', then parsing is ambiguous until you've looked ahead to lex either 'open', 'module', or a keyword that can start TypeDeclaration. [Ignoring annotations for simplicity.] - If you lexed 'open' or module', then the sequence must parse as the second alternative; if you lexed anything else, then the sequence must parse as the first alternative. > The current grammar can be parsed, e.g., with a hand-written scannerless > parser, > but can we assume any regularities about the grammar now and in the future? > If not, should all tool implementers be prepared to replace the parser with > full pattern matching with back tracking, as to try all possible > combinations of > interpreting keyword candidates as keywords or identifiers? My interest is Java SE 9, where we face the problem that 'open', 'module', 'requires', etc have been parsed as identifiers for 20 years so we can't turn them into traditional keywords. We could do something like saying they're keywords only in a ModuleDeclaration, which restricts the parser trickery to just the 'open' and 'module' terms at the start of a ModuleDeclaration. But then, you couldn't have 'open' (say) as part of a module name, and we think that's an unreasonable restriction. (What about module names that wish to begin with a digit, which seems reasonable yet is prohibited by the use of Identifier in ModuleName? Good question.) So, we say these terms are identifiers like previously, except where they can be keywords in ModuleDeclaration. > Thinking aloud about possible consequences, I wonder what happens in > case of a syntax error. Strictly speaking a text that almost looks > like a ModuleDeclaration but still cannot be fully accepted as such, > contains no keywords at all (because we have no ModuleDeclaration), > right? That's probably a fact which tools should carefully hide from > users, to avoid producing utterly confusing error messages. Generally > speaking, the only "correct" syntax error message seems to be: "the > input text could not be matched as a ModuleDeclaration". I agree. > Picking on words, I still hold that my example contains restricted > keywords as terminals > in a ModuleDeclaration where they are apparently interpreted (by javac) > as identifiers: > > module module { // second word is an identifier > requires requires; // second word is an identifier > exports to to exports; // words #2 and #4 are identifiers > uses module; // second word is an identifier > provides uses with to; // words #2 and #4 are identifiers > } > > So, am I possibly still barking up the wrong tree? > Or should the definition really say > "where they appear as _keywords_ in ModuleDeclaration" OK, I think I see what you're saying. On the first line, you're saying that the second 'module' word is parsed by javac as an identifier _and Identifier is a terminal symbol on the RHS of ModuleDeclaration_ so why does lang-vm say to parse it as a keyword ("they are keywords solely where they appear as terminals in ModuleDeclaration") ? Make a close reading of JLS 2.2. It's true that identifiers are terminal symbols of the _syntactic grammar_. However, I want to speak of 'open', 'module', et al as terminal symbols of the _lexical grammar_. Basically I mean "a fixed width font presentation of a reserved lexeme spelled o p e n". [Sidebar. The first sentence of JLS 2.4 says that terminal symbols of the _syntactic_ grammar are shown in fixed width font, but plainly, Identifier is never shown in fixed width font despite being deemed a terminal symbol of the syntactic grammar in 2.2. I've tried various ways of rewriting 2.4 -- "In the syntactic grammar, some terminal symbols are shown in fixed width font, namely keywords + separators + operators + certain literals, while other terminal symbols are shown in italic type, namely identifiers + certain other literals." -- but it doesn't feel very satisfying.] FWIW I don't want to introduce a new kind of token in the syntactic grammar -- identifiers, keywords, ***modwords***, literals, separators, operators -- because this whole issue is particular to module declarations whose mass is not so large as to move the center of gravity of the language, with its five token kinds. Alex From mandy.chung at oracle.com Wed Nov 16 21:35:03 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Nov 2016 21:35:03 +0000 Subject: hg: jigsaw/jake/jdk: 8169339: Provide internal API to JavaFX to locate JDK fonts Message-ID: <201611162135.uAGLZ3tM021598@aojmv0008.oracle.com> Changeset: 21f7c4aaeb68 Author: prr Date: 2016-11-09 10:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/21f7c4aaeb68 8169339: Provide internal API to JavaFX to locate JDK fonts Reviewed-by: serb, kcr ! src/java.desktop/share/classes/sun/font/SunFontManager.java + src/java.desktop/share/classes/sun/font/lookup/JDKFontLookup.java From stephan.herrmann at berlin.de Wed Nov 16 21:41:47 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 16 Nov 2016 22:41:47 +0100 Subject: Compiling Java 9 In-Reply-To: <582CC956.3080202@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> Message-ID: <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> Alex, I understand the motivation of not breaking existing code that uses these as identifiers. I just want to understand the precise rules and figure out if any established technology can recognize the desired language. On 11/16/2016 10:02 PM, Alex Buckley wrote: > [...] > Make a close reading of JLS 2.2. It's true that identifiers are terminal symbols of the _syntactic grammar_. However, I want to > speak of 'open', 'module', et al as terminal symbols of the _lexical grammar_. Basically I mean "a fixed width font presentation of > a reserved lexeme spelled o p e n". JLS 2.2: "A lexical grammar for the Java programming language is given in ?3 (Lexical Structure). This grammar has as its terminal symbols the characters of the Unicode character set." "open" is not a character of the Unicode character set. That's why I concluded you must be speaking of terminals of the syntactic grammar, which has as its terminals identifiers, keywords, etc. Or is 2.2 going to be extended to include restricted keywords as terminals of the lexical grammar? But how can they be interpreted as identifiers if they are already terminals of the lexical grammar? I believe your newer phrase "where they can be keywords in ModuleDeclaration" is already closer, if you add what you mean by "can": don't cause parsing the ModuleDeclaration rule to fail. At the end of the day we need full pattern matching right? I.e., find a combination of interpreting each occurrence of a restricted keyword as either a keyword or an identifier that allows to match the rule ModuleDeclaration. Anyway, your answers tell me that javac matches your intentions, even if I still can't match the current text in lang-vm to this. Remain my worries that this will cause a lot of pain for all kinds of tools. Even simple syntax highlighting becomes a major challenge, it's impossible to process only sections of a module declaration. Error reporting and syntax recovery are much harder, still. BTW: has it been considered to use an escape character to explicitly turn a restricted keyword into an identifier? That's the only way I can see that a traditional parser can grok a ModuleDeclaration without "wasting" keywords. Stephan From jonathan.gibbons at oracle.com Wed Nov 16 22:01:50 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Nov 2016 14:01:50 -0800 Subject: Compiling Java 9 In-Reply-To: <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> Message-ID: <582CD74E.4080102@oracle.com> On 11/16/2016 01:41 PM, Stephan Herrmann wrote: > > At the end of the day we need full pattern matching right? Not really, at least, not in javac. Words like 'module', 'requires', etc are lexed as identifiers. When we get to the point where the grammar would accept one of these words as a keyword, we simply check to see if we have an identifier with the appropriate value. -- Jon From stephan.herrmann at berlin.de Wed Nov 16 22:08:56 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 16 Nov 2016 23:08:56 +0100 Subject: Compiling Java 9 In-Reply-To: <582CC956.3080202@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> Message-ID: On 11/16/2016 10:02 PM, Alex Buckley wrote: > - If you lex 'package', then the sequence must parse as the first alternative. > - If you don't lex 'package', but rather lex 'import', then parsing is ambiguous until you've looked ahead to lex either 'open', > 'module', or a keyword that can start TypeDeclaration. [Ignoring annotations for simplicity.] > - If you lexed 'open' or module', then the sequence must parse as the second alternative; if you lexed anything else, then the > sequence must parse as the first alternative. I just tried this: ---8<--- import open.module; module foo { } ---8<--- According to lang-vm this should be legal. The import statement contains restricted keywords in positions where they cannot be keywords. => Parsing should succeed. javac rejects this, which supports your explanation that lexical lookahead should suffice to recognize a ModuleDeclaration. Which one will it be? Stephan From jonathan.gibbons at oracle.com Wed Nov 16 22:19:28 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Nov 2016 14:19:28 -0800 Subject: Compiling Java 9 In-Reply-To: References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> Message-ID: <582CDB70.4080602@oracle.com> On 11/16/2016 02:08 PM, Stephan Herrmann wrote: > On 11/16/2016 10:02 PM, Alex Buckley wrote: >> - If you lex 'package', then the sequence must parse as the first >> alternative. >> - If you don't lex 'package', but rather lex 'import', then parsing >> is ambiguous until you've looked ahead to lex either 'open', >> 'module', or a keyword that can start TypeDeclaration. [Ignoring >> annotations for simplicity.] >> - If you lexed 'open' or module', then the sequence must parse as the >> second alternative; if you lexed anything else, then the >> sequence must parse as the first alternative. > > I just tried this: > > ---8<--- > import open.module; > > module foo { > } > ---8<--- > > According to lang-vm this should be legal. The import statement > contains restricted keywords in positions where they cannot be keywords. > => Parsing should succeed. > javac rejects this, which supports your explanation that lexical > lookahead > should suffice to recognize a ModuleDeclaration. > > Which one will it be? > > Stephan > I suspect you're not using the latest javac. Your example works for me, after I also create a class called open.module that I can import. $ more $(find play/stephan/ -name \*.java) :::::::::::::: play/stephan/open/module.java :::::::::::::: package open; public class module { } :::::::::::::: play/stephan/module-info.java :::::::::::::: import open.module; module foo { } $ /opt/jdk/jake/bin/javac -sourcepath play/stephan play/stephan/module-info.java $ -- Jon From stephan.herrmann at berlin.de Wed Nov 16 22:26:34 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 16 Nov 2016 23:26:34 +0100 Subject: Compiling Java 9 In-Reply-To: <582CD74E.4080102@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> Message-ID: <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> On 11/16/2016 11:01 PM, Jonathan Gibbons wrote: > > > On 11/16/2016 01:41 PM, Stephan Herrmann wrote: >> >> At the end of the day we need full pattern matching right? > > Not really, at least, not in javac. > > Words like 'module', 'requires', etc are lexed as identifiers. When we get to the point where the grammar would accept one of these > words as a keyword, we simply check to see if we have an identifier with the appropriate value. > > -- Jon OK, feedback from the parser to the scanner to tell it whether the current context accepts a specific restricted keyword. And we may safely assume regularity of the grammar, i.e., the above approach will never lead to ambiguities, right? Fictitious counter example ModuleDeclaration: module open Identifier ModuleBody; module Identifier ModuleBody; With this the second token could be keyword or identifier, and we're stuck, aren't we? May we assume that the grammar will not be extended in such ambiguous ways? For all tools that read from the start of the file this is good news. Still no good news for tools wishing to process just a fragment of the text. thanks, Stephan From stephan.herrmann at berlin.de Wed Nov 16 22:34:40 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 16 Nov 2016 23:34:40 +0100 Subject: Compiling Java 9 In-Reply-To: <582CDB70.4080602@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <582CDB70.4080602@oracle.com> Message-ID: On 11/16/2016 11:19 PM, Jonathan Gibbons wrote: > > > On 11/16/2016 02:08 PM, Stephan Herrmann wrote: >> On 11/16/2016 10:02 PM, Alex Buckley wrote: >>> - If you lex 'package', then the sequence must parse as the first alternative. >>> - If you don't lex 'package', but rather lex 'import', then parsing is ambiguous until you've looked ahead to lex either 'open', >>> 'module', or a keyword that can start TypeDeclaration. [Ignoring annotations for simplicity.] >>> - If you lexed 'open' or module', then the sequence must parse as the second alternative; if you lexed anything else, then the >>> sequence must parse as the first alternative. >> >> I just tried this: >> >> ---8<--- >> import open.module; >> >> module foo { >> } >> ---8<--- >> >> According to lang-vm this should be legal. The import statement >> contains restricted keywords in positions where they cannot be keywords. >> => Parsing should succeed. >> javac rejects this, which supports your explanation that lexical lookahead >> should suffice to recognize a ModuleDeclaration. >> >> Which one will it be? >> >> Stephan >> > > I suspect you're not using the latest javac. 9-ea-142 gives a syntax error: module-info.java:3: error: class, interface, or enum expected I'm downloading 9-ea-144 as we speak. > Your example works for me, after I also create a class called open.module that I can > import. Thanks, so restricted keywords now follow the same rules throughout the file. Sounds good. And with your explanation (previous post) I'm confident that javac's implementation and what I had in mind are congruent. Still curious how a spec will faithfully capture this :) Stephan From jonathan.gibbons at oracle.com Wed Nov 16 22:35:43 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Nov 2016 14:35:43 -0800 Subject: Compiling Java 9 In-Reply-To: <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> Message-ID: <582CDF3F.1080401@oracle.com> On 11/16/2016 02:26 PM, Stephan Herrmann wrote: > On 11/16/2016 11:01 PM, Jonathan Gibbons wrote: >> >> >> On 11/16/2016 01:41 PM, Stephan Herrmann wrote: >>> >>> At the end of the day we need full pattern matching right? >> >> Not really, at least, not in javac. >> >> Words like 'module', 'requires', etc are lexed as identifiers. When >> we get to the point where the grammar would accept one of these >> words as a keyword, we simply check to see if we have an identifier >> with the appropriate value. >> >> -- Jon > > OK, feedback from the parser to the scanner to tell it > whether the current context accepts a specific restricted keyword. > > And we may safely assume regularity of the grammar, i.e., > the above approach will never lead to ambiguities, right? > > Fictitious counter example > > ModuleDeclaration: > module open Identifier ModuleBody; > module Identifier ModuleBody; > > With this the second token could be keyword or identifier, and we're > stuck, aren't we? > > May we assume that the grammar will not be extended in such ambiguous > ways? I'll leave it to Alex to declare definitively on that, but I think that would be a reasonable assumption. :-) > > For all tools that read from the start of the file this is good news. > > Still no good news for tools wishing to process just a fragment of the > text. > Just how small a fragment, and in how unknown a context are you worried about? Yes, if you're wanting to locally analyse the character string "module" in isolation, then yes, you cannot say whether it is a keyword or an identifier, but if you know you're in a ModuleBody, then "exports to to exports;" can be processed just fine. > > thanks, > Stephan From jonathan.gibbons at oracle.com Wed Nov 16 22:39:14 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Nov 2016 14:39:14 -0800 Subject: Compiling Java 9 In-Reply-To: References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <582CDB70.4080602@oracle.com> Message-ID: <582CE012.2050703@oracle.com> On 11/16/2016 02:34 PM, Stephan Herrmann wrote: > On 11/16/2016 11:19 PM, Jonathan Gibbons wrote: >> >> >> On 11/16/2016 02:08 PM, Stephan Herrmann wrote: >>> On 11/16/2016 10:02 PM, Alex Buckley wrote: >>>> - If you lex 'package', then the sequence must parse as the first >>>> alternative. >>>> - If you don't lex 'package', but rather lex 'import', then parsing >>>> is ambiguous until you've looked ahead to lex either 'open', >>>> 'module', or a keyword that can start TypeDeclaration. [Ignoring >>>> annotations for simplicity.] >>>> - If you lexed 'open' or module', then the sequence must parse as >>>> the second alternative; if you lexed anything else, then the >>>> sequence must parse as the first alternative. >>> >>> I just tried this: >>> >>> ---8<--- >>> import open.module; >>> >>> module foo { >>> } >>> ---8<--- >>> >>> According to lang-vm this should be legal. The import statement >>> contains restricted keywords in positions where they cannot be >>> keywords. >>> => Parsing should succeed. >>> javac rejects this, which supports your explanation that lexical >>> lookahead >>> should suffice to recognize a ModuleDeclaration. >>> >>> Which one will it be? >>> >>> Stephan >>> >> >> I suspect you're not using the latest javac. > > 9-ea-142 gives a syntax error: > > module-info.java:3: error: class, interface, or enum expected > > I'm downloading 9-ea-144 as we speak. > 9-ea-144 probably won't be good enough. You will need a build of the jigsaw/jake forest, coming soon. > >> Your example works for me, after I also create a class called >> open.module that I can >> import. > > Thanks, so restricted keywords now follow the same rules throughout > the file. > Sounds good. > > And with your explanation (previous post) I'm confident that javac's > implementation > and what I had in mind are congruent. > > Still curious how a spec will faithfully capture this :) :-) > > Stephan > From alex.buckley at oracle.com Wed Nov 16 22:47:44 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Nov 2016 14:47:44 -0800 Subject: Compiling Java 9 In-Reply-To: <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> Message-ID: <582CE210.3040006@oracle.com> On 11/16/2016 1:41 PM, Stephan Herrmann wrote: > On 11/16/2016 10:02 PM, Alex Buckley wrote: >> [...] >> Make a close reading of JLS 2.2. It's true that identifiers are >> terminal symbols of the _syntactic grammar_. However, I want to >> speak of 'open', 'module', et al as terminal symbols of the _lexical >> grammar_. Basically I mean "a fixed width font presentation of >> a reserved lexeme spelled o p e n". > > JLS 2.2: > "A lexical grammar for the Java programming language is given in ?3 > (Lexical Structure). > This grammar has as its terminal symbols the characters of the Unicode > character set." > > "open" is not a character of the Unicode character set. > That's why I concluded you must be speaking of terminals of the > syntactic grammar, which has as its terminals identifiers, keywords, etc. > > Or is 2.2 going to be extended to include restricted keywords as > terminals of > the lexical grammar? But how can they be interpreted as identifiers if they > are already terminals of the lexical grammar? Please disregard 'open' being a terminal symbol of the lexical grammar ... I was looking at the opening sentence to 2.4 at the time, which smashes together the terminals of both grammars, and I got mixed up. Nothing is changing in 2.2. I say again: I agree identifiers are terminals in the syntactic grammar, and that it's confusing for lang-vm to say that 'module' is a keyword solely where it may appear as a terminal in ModuleDeclaration, since here it appears as a terminal (Identifier) in the second-word place yet plainly it should not be a keyword there: module module { // second word is an identifier But by "appears as a terminal", I didn't mean "can be parsed as the terminal Identifier". I literally meant "appears in fixed width font presentation on the RHS of a production under ModuleDeclaration". > BTW: has it been considered to use an escape character to explicitly turn a > restricted keyword into an identifier? That's the only way I can see that > a traditional parser can grok a ModuleDeclaration without "wasting" > keywords. Frankly no. Alex From stephan.herrmann at berlin.de Wed Nov 16 22:55:19 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 16 Nov 2016 23:55:19 +0100 Subject: Compiling Java 9 In-Reply-To: <582CDF3F.1080401@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> <582CDF3F.1080401@oracle.com> Message-ID: On 11/16/2016 11:35 PM, Jonathan Gibbons wrote: > > > On 11/16/2016 02:26 PM, Stephan Herrmann wrote: >> Still no good news for tools wishing to process just a fragment of the text. >> > > Just how small a fragment, and in how unknown a context are you worried about? Yes, if you're wanting to locally analyse the > character string "module" in isolation, then yes, you cannot say whether it is a keyword or an identifier, but if you know you're in > a ModuleBody, then "exports to to exports;" can be processed just fine. For syntax highlighting: processing just one line of text would be great. And the line break could be in the middle of an exports clause. For error recovery: let's say, s.o. just forgot a ';', we'd like to search for the next keyword to get back on track parsing. So even if we started from the top of the file, we don't have the context for sure, because we don't know where the syntax error happened. I guess in that case reverting to always seeing restricted keywords as keywords will give the best heuristics ... but it looks messy to me. Different tools / tool features have different requirements, a full IDE will have tens if not hundreds of different use cases in this regard. Mind you: during editing text with syntax errors is the norm, not the exception. Stephan From alex.buckley at oracle.com Wed Nov 16 22:57:28 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Nov 2016 14:57:28 -0800 Subject: Compiling Java 9 In-Reply-To: <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> Message-ID: <582CE458.5030809@oracle.com> On 11/16/2016 2:26 PM, Stephan Herrmann wrote: > And we may safely assume regularity of the grammar, i.e., > the above approach will never lead to ambiguities, right? > > Fictitious counter example > > ModuleDeclaration: > module open Identifier ModuleBody; > module Identifier ModuleBody; > > With this the second token could be keyword or identifier, and we're > stuck, aren't we? > > May we assume that the grammar will not be extended in such ambiguous ways? There is already a production like this: ModuleStatement: requires transitive ModuleName ; requires ModuleName ; Alex From jonathan.gibbons at oracle.com Wed Nov 16 23:02:14 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Nov 2016 15:02:14 -0800 Subject: Compiling Java 9 In-Reply-To: References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> <582CDF3F.1080401@oracle.com> Message-ID: <582CE576.1020907@oracle.com> On 11/16/2016 02:55 PM, Stephan Herrmann wrote: > On 11/16/2016 11:35 PM, Jonathan Gibbons wrote: >> >> >> On 11/16/2016 02:26 PM, Stephan Herrmann wrote: >>> Still no good news for tools wishing to process just a fragment of >>> the text. >>> >> >> Just how small a fragment, and in how unknown a context are you >> worried about? Yes, if you're wanting to locally analyse the >> character string "module" in isolation, then yes, you cannot say >> whether it is a keyword or an identifier, but if you know you're in >> a ModuleBody, then "exports to to exports;" can be processed just fine. > > > For syntax highlighting: processing just one line of text would be great. > And the line break could be in the middle of an exports clause. > > For error recovery: let's say, s.o. just forgot a ';', we'd like to > search for the next keyword to get back on track parsing. > So even if we started from the top of the file, we don't have the > context for sure, because we don't know where the syntax error happened. > I guess in that case reverting to always seeing restricted keywords as > keywords will give the best heuristics ... but it looks messy to me. I agree error recovery can be tricky, but if you are before the first '{' then the only restricted keywords are 'open', 'module'. Once you're inside a module declaration, ';' is a good recovery point. ';' is always followed by a restricted keyword, or '}'. > > Different tools / tool features have different requirements, a full IDE > will have tens if not hundreds of different use cases in this regard. > Mind you: during editing text with syntax errors is the norm, not the > exception. > > Stephan From stephan.herrmann at berlin.de Wed Nov 16 23:03:35 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Thu, 17 Nov 2016 00:03:35 +0100 Subject: Compiling Java 9 In-Reply-To: <582CE458.5030809@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> <582CE458.5030809@oracle.com> Message-ID: On 11/16/2016 11:57 PM, Alex Buckley wrote: > On 11/16/2016 2:26 PM, Stephan Herrmann wrote: >> And we may safely assume regularity of the grammar, i.e., >> the above approach will never lead to ambiguities, right? >> >> Fictitious counter example >> >> ModuleDeclaration: >> module open Identifier ModuleBody; >> module Identifier ModuleBody; >> >> With this the second token could be keyword or identifier, and we're >> stuck, aren't we? >> >> May we assume that the grammar will not be extended in such ambiguous ways? > > There is already a production like this: > > ModuleStatement: > requires transitive ModuleName ; > requires ModuleName ; Outch!! So when you read "requires transitive" which rule are you parsing against? When do you decide whether transitive is a keyword or an identifier? I guess we have to wait until we matched the full rule. That requires backtracking, or what am I missing? Stephan From alex.buckley at oracle.com Wed Nov 16 23:10:31 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Nov 2016 15:10:31 -0800 Subject: Compiling Java 9 In-Reply-To: References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> <582CE458.5030809@oracle.com> Message-ID: <582CE767.1030307@oracle.com> On 11/16/2016 3:03 PM, Stephan Herrmann wrote: > On 11/16/2016 11:57 PM, Alex Buckley wrote: >> On 11/16/2016 2:26 PM, Stephan Herrmann wrote: >>> And we may safely assume regularity of the grammar, i.e., >>> the above approach will never lead to ambiguities, right? >>> >>> Fictitious counter example >>> >>> ModuleDeclaration: >>> module open Identifier ModuleBody; >>> module Identifier ModuleBody; >>> >>> With this the second token could be keyword or identifier, and we're >>> stuck, aren't we? >>> >>> May we assume that the grammar will not be extended in such ambiguous >>> ways? >> >> There is already a production like this: >> >> ModuleStatement: >> requires transitive ModuleName ; >> requires ModuleName ; > > Outch!! > > So when you read "requires transitive" which rule are you parsing against? > When do you decide whether transitive is a keyword or an identifier? > I guess we have to wait until we matched the full rule. > That requires backtracking, or what am I missing? Yes, you need to lookahead to a ; Alex From mandy.chung at oracle.com Wed Nov 16 23:25:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Nov 2016 15:25:55 -0800 Subject: Proposal to move src.zip and jrt-fs.zip to the `lib` directory in the run-time image Message-ID: Several files in a runtime image are intended for external uses and their pathname is a committed interface, including: jrt-fs.jar src.zip lib/javafx-swt.jar lib/ant-javafx.jar The `lib` directory in the runtime image currently defined in JEP 220 is private implementation and for internal use only. In addition to the above files, external launchers depend on the path `lib/$VMTYPE/libjvm.so` (or the equivalent) and tools depend on `lib/jexec`. The proposal is to redefine the purpose of the `lib` directory. The `lib` directory will contain read-only files that are intended for external use and thus are committed interfaces. Therefore we propose to move `jrt-fs.jar` and `src.zip` from the top level into the `lib` directory. We?ll leave `javafx-swt.jar` and `ant-javafx.jar` in the `lib` directory. For the internal files under the `lib` directory, we propose to leave them in the `lib` directory in JDK 9 and be moved out of the `lib` directory in future releases. This change [1] will impact external tools depending on jrt-fs.jar and src.zip. One tentative plan is to make this change in 2 weeks (possibly jdk-9+147) unless any one needs more time. Comments? Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8169816 From stephan.herrmann at berlin.de Wed Nov 16 23:28:14 2016 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Thu, 17 Nov 2016 00:28:14 +0100 Subject: Compiling Java 9 In-Reply-To: <582CE767.1030307@oracle.com> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> <582CE458.5030809@oracle.com> <582CE767.1030307@oracle.com> Message-ID: <6b0e82ea-cf67-3031-dc37-64b5f21859c9@berlin.de> On 11/17/2016 12:10 AM, Alex Buckley wrote: > On 11/16/2016 3:03 PM, Stephan Herrmann wrote: >> On 11/16/2016 11:57 PM, Alex Buckley wrote: >>> On 11/16/2016 2:26 PM, Stephan Herrmann wrote: >>>> And we may safely assume regularity of the grammar, i.e., >>>> the above approach will never lead to ambiguities, right? >>>> >>>> Fictitious counter example >>>> >>>> ModuleDeclaration: >>>> module open Identifier ModuleBody; >>>> module Identifier ModuleBody; >>>> >>>> With this the second token could be keyword or identifier, and we're >>>> stuck, aren't we? >>>> >>>> May we assume that the grammar will not be extended in such ambiguous >>>> ways? >>> >>> There is already a production like this: >>> >>> ModuleStatement: >>> requires transitive ModuleName ; >>> requires ModuleName ; >> >> Outch!! >> >> So when you read "requires transitive" which rule are you parsing against? >> When do you decide whether transitive is a keyword or an identifier? >> I guess we have to wait until we matched the full rule. >> That requires backtracking, or what am I missing? > > Yes, you need to lookahead to a ; > > Alex So everything points at ';' to the rescue. Unfortunately, while a user types a line of text, this essential character will be missing until the very end, so tool support for incomplete lines will not be great. Not much we can do, I guess. OK, thanks to you both, I believe I understand the intention. I guess I made my point that I see tremendous difficulties in providing good tool support, and that I'm not convinced that the current definition matches to the intended solution. I mentioned that all this could probably be avoided by using an escape mechanism. That said I will stop harping on these points, Stephan From jonathan.gibbons at oracle.com Wed Nov 16 23:54:15 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Nov 2016 15:54:15 -0800 Subject: Compiling Java 9 In-Reply-To: <6b0e82ea-cf67-3031-dc37-64b5f21859c9@berlin.de> References: <38d1f81d-fddb-2195-aa3a-49e376534298@berlin.de> <582A46BB.5060905@oracle.com> <979e4aeb-0d43-0211-e09e-2b3cc4108127@berlin.de> <582CC956.3080202@oracle.com> <27c364f3-73e5-0559-c251-eb8aa340200f@berlin.de> <582CD74E.4080102@oracle.com> <6332fb29-0f6c-0129-6c4d-5ee305cc6e2d@berlin.de> <582CE458.5030809@oracle.com> <582CE767.1030307@oracle.com> <6b0e82ea-cf67-3031-dc37-64b5f21859c9@berlin.de> Message-ID: <582CF1A7.40600@oracle.com> On 11/16/2016 03:28 PM, Stephan Herrmann wrote: > On 11/17/2016 12:10 AM, Alex Buckley wrote: >> On 11/16/2016 3:03 PM, Stephan Herrmann wrote: >>> On 11/16/2016 11:57 PM, Alex Buckley wrote: >>>> On 11/16/2016 2:26 PM, Stephan Herrmann wrote: >>>>> And we may safely assume regularity of the grammar, i.e., >>>>> the above approach will never lead to ambiguities, right? >>>>> >>>>> Fictitious counter example >>>>> >>>>> ModuleDeclaration: >>>>> module open Identifier ModuleBody; >>>>> module Identifier ModuleBody; >>>>> >>>>> With this the second token could be keyword or identifier, and we're >>>>> stuck, aren't we? >>>>> >>>>> May we assume that the grammar will not be extended in such ambiguous >>>>> ways? >>>> >>>> There is already a production like this: >>>> >>>> ModuleStatement: >>>> requires transitive ModuleName ; >>>> requires ModuleName ; >>> >>> Outch!! >>> >>> So when you read "requires transitive" which rule are you parsing >>> against? >>> When do you decide whether transitive is a keyword or an identifier? >>> I guess we have to wait until we matched the full rule. >>> That requires backtracking, or what am I missing? >> >> Yes, you need to lookahead to a ; >> >> Alex > > So everything points at ';' to the rescue. > > Unfortunately, while a user types a line of text, this essential > character will be missing until the very end, so tool support > for incomplete lines will not be great. > > Not much we can do, I guess. > > OK, thanks to you both, I believe I understand the intention. > > I guess I made my point that I see tremendous difficulties > in providing good tool support, and that I'm not convinced > that the current definition matches to the intended solution. > > I mentioned that all this could probably be avoided by using > an escape mechanism. > > That said I will stop harping on these points, > Stephan > > > It is not quite as bad as that. An identifier-that-might-be-a-keyword is definitely a restricted keyword if it is followed by another identifier (including an identifier-that-might-be-a-keyword) or static. An identifier-that-might-be-a-keyword is definitely an identifier if it is followed by a '.' or ';'. So in the following horrible cases: requires transitive transitive; ^ at this point you know the first transitive was a restricted keyword and the second was an identifier requires transitive transitive.transitive.transitive; ^ at this point you know the first transitive was a restricted keyword, and that the second and any subsequent instances are identifiers. requires transitive static a.b.c.d.e.f.g.h.i.j; ^ at this point you know transitive was a restricted keyword In other words, you don't need unbounded lookahead. -- Jon From Alan.Bateman at oracle.com Thu Nov 17 08:43:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Nov 2016 08:43:41 +0000 Subject: uses is useless ? In-Reply-To: <1427011145.2137503.1479325277850.JavaMail.zimbra@u-pem.fr> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> <1427011145.2137503.1479325277850.JavaMail.zimbra@u-pem.fr> Message-ID: <3599517b-8e7c-819c-6ef4-e314810182f1@oracle.com> On 16/11/2016 19:41, forax at univ-mlv.fr wrote: > : > My point is that in teory, that's cool but in reality the module-info of java.base (or java.sql) declares a lot of 'uses' making the whole idea moot. > To avoid java.base to use 'uses', we need a way to be able to have a way to delegate the power of the ServiceLoader to another code, so the other code will have to use 'uses'. If a consumer is making use of an API in java.base and the implementation of that API makes use of services under the covers then it is transparent to the consumer of the API. The consumer of the API shouldn't need to know anything about the "SPI" types and would be very surprising if the user of an API needed to declare `uses` on such types. In the JDK then I'm only aware of two cases where the consumer passes a service type to an API that doesn't know anything about the service type (the two cases are JVMCI and a utility method in javac). Both of these cases use addUses to get through the hygiene check. jlink is a bit special in that the user of the tool needs at least some global knowledge when choosing the service provider modules to include in the run time image. As I said, the tool could help more but having it do eager service binding is problematic as it tends to maximize rather than minimize the number of the modules. -Alan. From alan.bateman at oracle.com Thu Nov 17 10:29:47 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 17 Nov 2016 10:29:47 +0000 Subject: hg: jigsaw/jake/hotspot: Clean-up of JVMTI AddModuleExports/AddModuleOpens Message-ID: <201611171029.uAHATl4C026597@aojmv0008.oracle.com> Changeset: e9f9a8d55756 Author: sspitsyn Date: 2016-11-17 10:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e9f9a8d55756 Clean-up of JVMTI AddModuleExports/AddModuleOpens ! make/test/JtregNative.gmk ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp - test/serviceability/jvmti/AddModuleExports/MyPackage/AddModuleExportsTest.java - test/serviceability/jvmti/AddModuleExports/libAddModuleExportsTest.c + test/serviceability/jvmti/AddModuleExportsAndOpens/MyPackage/AddModuleExportsAndOpensTest.java + test/serviceability/jvmti/AddModuleExportsAndOpens/libAddModuleExportsAndOpensTest.c From harold.seigel at oracle.com Thu Nov 17 21:22:14 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 17 Nov 2016 21:22:14 +0000 Subject: hg: jigsaw/jake/nashorn: 8169920: Fix Nashorn JTReg Jake test failures Message-ID: <201611172122.uAHLME3k023448@aojmv0008.oracle.com> Changeset: 51851824d373 Author: hseigel Date: 2016-11-17 16:12 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/51851824d373 8169920: Fix Nashorn JTReg Jake test failures Summary: add needed :open to @modules Reviewed-by: alanb ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/BignumTest.java ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/DiyFpTest.java From jonathan.gibbons at oracle.com Thu Nov 17 22:34:39 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 17 Nov 2016 22:34:39 +0000 Subject: hg: jigsaw/jake/langtools: Fix spurious error caused by @deprecated tag on module comment Message-ID: <201611172234.uAHMYdgP011400@aojmv0008.oracle.com> Changeset: b8086bb7db9a Author: jjg Date: 2016-11-17 14:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b8086bb7db9a Fix spurious error caused by @deprecated tag on module comment ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From mandy.chung at oracle.com Fri Nov 18 02:05:03 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:03 +0000 Subject: hg: jigsaw/jake: 4 new changesets Message-ID: <201611180205.uAI254xk027337@aojmv0008.oracle.com> Changeset: 3b59ad58041d Author: simonis Date: 2016-11-14 11:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3b59ad58041d 8169630: Fix wrong cpu build flag for Linux/ppc64le build Reviewed-by: erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: ff98aa9ec9fa Author: erikj Date: 2016-11-15 10:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ff98aa9ec9fa 8169632: Update compare script for clean compare Reviewed-by: tbell ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: b6c985a906c9 Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b6c985a906c9 Added tag jdk-9+145 for changeset ff98aa9ec9fa ! .hgtags Changeset: 6e2540d701ac Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6e2540d701ac Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/bin/compare.sh From mandy.chung at oracle.com Fri Nov 18 02:05:08 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:08 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201611180205.uAI258nX027390@aojmv0008.oracle.com> Changeset: ecd74b41ab65 Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/ecd74b41ab65 Added tag jdk-9+145 for changeset a44b156ae7f0 ! .hgtags Changeset: be54656af21d Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/be54656af21d Merge From mandy.chung at oracle.com Fri Nov 18 02:05:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:15 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201611180205.uAI25FYW027442@aojmv0008.oracle.com> Changeset: 225b91f1b118 Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/225b91f1b118 Added tag jdk-9+145 for changeset 61e7ea563123 ! .hgtags Changeset: 5f1fd16ade77 Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5f1fd16ade77 Merge ! .hgtags - test/runtime/modules/JVMCanReadModule.java - test/runtime/modules/JVMIsExportedToModule.java - test/serviceability/jdwp/JdwpCanReadCmd.java - test/serviceability/jdwp/JdwpCanReadReply.java From mandy.chung at oracle.com Fri Nov 18 02:05:22 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:22 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201611180205.uAI25M6Q027499@aojmv0008.oracle.com> Changeset: 4f68472a3623 Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4f68472a3623 Added tag jdk-9+145 for changeset 71558b38bad7 ! .hgtags Changeset: dac05614acb1 Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/dac05614acb1 Merge From mandy.chung at oracle.com Fri Nov 18 02:05:25 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:25 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201611180205.uAI25PIY027588@aojmv0008.oracle.com> Changeset: e997d835cfee Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e997d835cfee Added tag jdk-9+145 for changeset 29277a4e7307 ! .hgtags Changeset: 8e8d9cd2f887 Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/8e8d9cd2f887 Merge From mandy.chung at oracle.com Fri Nov 18 02:05:35 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:35 +0000 Subject: hg: jigsaw/jake/jdk: 26 new changesets Message-ID: <201611180205.uAI25abl027650@aojmv0008.oracle.com> Changeset: 762dad364838 Author: jlaskey Date: 2016-11-07 14:36 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/762dad364838 8155756: Better context for some jlink exceptions Reviewed-by: mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/DirArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties Changeset: 361fb5404741 Author: xuelei Date: 2016-11-08 06:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/361fb5404741 8169318: Dump the reproduced packet in DTLSOverDatagram.java Reviewed-by: mullan ! test/javax/net/ssl/DTLS/DTLSOverDatagram.java Changeset: 60837db5d445 Author: nishjain Date: 2016-11-08 14:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60837db5d445 8166994: Improve sun.util.locale.LocaleMatcher Reviewed-by: okutsu, naoto, peytoia ! src/java.base/share/classes/sun/util/locale/LocaleMatcher.java + test/java/util/Locale/Bug8166994.java Changeset: 3f560167843d Author: redestad Date: 2016-11-08 13:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f560167843d 8168911: Increased number of classes initialized during initialization of SignatureFileVerifier Reviewed-by: ascarpino ! src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java Changeset: befc4757d253 Author: psandoz Date: 2016-11-08 12:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/befc4757d253 8165782: java.util.jar.JarFile.runtimeVersion() spec needs clarification Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/util/jar/JarFile.java Changeset: a641b410ee9b Author: psandoz Date: 2016-11-08 12:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a641b410ee9b 8166735: JarFile#getVersion spec clarification for unversioned jars Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/util/jar/JarFile.java Changeset: 36cf65a9e2f9 Author: sherman Date: 2016-11-08 14:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/36cf65a9e2f9 8168862: Tighten permissions granted to the jdk.zipfs module Reviewed-by: mullan, mchung, lancea, bpb ! src/java.base/share/lib/security/default.policy Changeset: 9bb8dc7e972d Author: asmotrak Date: 2016-11-08 15:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9bb8dc7e972d 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar Reviewed-by: weijun, mullan ! src/java.base/share/classes/sun/security/tools/keytool/Main.java + test/lib/security/SecurityTools.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/PrintSSL.java + test/sun/security/tools/keytool/ReadJar.java - test/sun/security/tools/keytool/readjar.sh Changeset: 4407b0525631 Author: wetmore Date: 2016-11-08 16:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4407b0525631 8169229: RSAClientKeyExchange debug info is incorrect Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 7f7091c1dd33 Author: rpatil Date: 2016-11-08 18:02 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f7091c1dd33 8169191: (tz) Support tzdata2016i Reviewed-by: martin, okutsu ! make/data/tzdata/VERSION ! make/data/tzdata/antarctica ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/zone.tab ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: a02d6daeba2a Author: psandoz Date: 2016-11-09 10:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a02d6daeba2a 8164934: Optional.map() javadoc code example Reviewed-by: forax, chegar ! src/java.base/share/classes/java/util/Optional.java Changeset: 60d4214cc8ba Author: xuelei Date: 2016-11-10 08:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60d4214cc8ba 8169362: Interop automated testing with Chrome Reviewed-by: wetmore, jnimeh, asmotrak + test/javax/net/ssl/interop/ClientHelloChromeInterOp.java + test/javax/net/ssl/interop/ClientHelloInterOp.java Changeset: df914079c901 Author: skovalev Date: 2016-11-09 14:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/df914079c901 8169196: [TESTBUG] Three tests from sun/net/www have undeclared dependencies Reviewed-by: dfuchs ! test/sun/net/www/http/HttpClient/RetryPost.java - test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/http/KeepAliveStream/InfiniteLoop.java ! test/sun/net/www/protocol/http/NoNTLM.java Changeset: 9aaa84760473 Author: ksrini Date: 2016-11-10 15:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9aaa84760473 8169001: Remove launcher's built-in ergonomics Reviewed-by: dholmes, erikj ! make/launcher/Launcher-jdk.compiler.gmk ! make/launcher/Launcher-jdk.javadoc.gmk ! make/launcher/Launcher-jdk.jdeps.gmk ! make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.jshell.gmk ! src/java.base/macosx/conf/x86_64/jvm.cfg ! src/java.base/macosx/native/libjli/java_md_macosx.c ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/launcher/defines.h ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h ! src/java.base/unix/conf/aarch64/jvm.cfg ! src/java.base/unix/conf/amd64/jvm.cfg ! src/java.base/unix/conf/i586/jvm.cfg ! src/java.base/unix/conf/ia64/jvm.cfg ! src/java.base/unix/conf/ppc64/jvm.cfg ! src/java.base/unix/conf/ppc64le/jvm.cfg ! src/java.base/unix/conf/s390x/jvm.cfg ! src/java.base/unix/conf/sparc/jvm.cfg ! src/java.base/unix/conf/sparcv9/jvm.cfg ! src/java.base/unix/conf/zero/jvm.cfg - src/java.base/unix/native/libjli/ergo.c - src/java.base/unix/native/libjli/ergo.h - src/java.base/unix/native/libjli/ergo_i586.c ! src/java.base/windows/conf/amd64/jvm.cfg ! src/java.base/windows/conf/i586/jvm.cfg ! src/java.base/windows/conf/ia64/jvm.cfg ! src/java.base/windows/native/libjli/java_md.c Changeset: 1b0ed4d3704e Author: amlu Date: 2016-11-11 11:31 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b0ed4d3704e 8169041: com/sun/corba/cachedSocket should be added to exclusiveAccess.dirs Reviewed-by: chegar ! test/TEST.ROOT Changeset: 5b6b8e24a20b Author: lana Date: 2016-11-11 05:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5b6b8e24a20b Merge - src/java.base/unix/native/libjli/ergo.c - src/java.base/unix/native/libjli/ergo.h - src/java.base/unix/native/libjli/ergo_i586.c - test/sun/net/www/http/HttpClient/RetryPost.sh - test/sun/security/tools/keytool/readjar.sh Changeset: ba70dcd8de76 Author: msheppar Date: 2016-11-11 13:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba70dcd8de76 8164815: 3 JCK NetworkInterface tests fail on Raspberry Pi Reviewed-by: chegar, alanb ! src/java.base/share/classes/java/net/NetworkInterface.java Changeset: 93ebc26afa26 Author: jlahoda Date: 2016-11-14 10:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93ebc26afa26 8169595: jshell tool: pasting multiple lines hangs input Summary: Need to allow newlines in the user's input. Reviewed-by: rfield ! src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java Changeset: 47a8e055bab1 Author: rriggs Date: 2016-01-28 23:13 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/47a8e055bab1 8169556: Wrapping of FileInputStream's native skip and available methods Summary: Wrap further native methods in FileInputStreams Reviewed-by: chegar, bpb, rriggs Contributed-by: sunny.chan at gs.com ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjava/reorder-sparc ! make/mapfiles/libjava/reorder-sparcv9 ! make/mapfiles/libjava/reorder-x86 ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/native/libjava/FileInputStream.c Changeset: da8892f0a591 Author: skovalev Date: 2016-11-08 16:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/da8892f0a591 8169316: com/sun/net/httpserver tests have undeclared dependency on java.logging Reviewed-by: chegar ! test/com/sun/net/httpserver/TEST.properties Changeset: b5afa4a68a25 Author: ascarpino Date: 2016-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b5afa4a68a25 8168861: AnchorCertificates uses hardcoded password for cacerts keystore Reviewed-by: vinnie, mullan ! src/java.base/share/classes/sun/security/util/AnchorCertificates.java Changeset: aa6fda530e14 Author: ascarpino Date: 2016-11-14 13:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aa6fda530e14 8168931: Few OCSP related test failed with "Response is unreliable: its validity interval is out-of-date" Reviewed-by: mullan ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java Changeset: a88e0ff30e44 Author: jlaskey Date: 2016-11-15 10:53 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a88e0ff30e44 8169720: jimage help message for --include option should be corrected Reviewed-by: alanb, sundar ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties Changeset: 99b7853cfbd8 Author: bpb Date: 2016-11-15 08:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/99b7853cfbd8 8168500: (se) EPollArrayWrapper optimization for update events should be robust to dynamic changes in file descriptor resource limits Summary: Make eventsHigh final and always initialize it to an empty Map. Reviewed-by: alanb ! src/java.base/linux/classes/sun/nio/ch/EPollArrayWrapper.java Changeset: 1210d929d34e Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1210d929d34e Added tag jdk-9+145 for changeset 99b7853cfbd8 ! .hgtags Changeset: 9e5958d94d8c Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9e5958d94d8c Merge ! .hgtags ! make/launcher/Launcher-jdk.compiler.gmk ! make/launcher/Launcher-jdk.javadoc.gmk ! make/launcher/Launcher-jdk.jdeps.gmk ! make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.jshell.gmk ! make/mapfiles/libjava/mapfile-vers - src/java.base/share/classes/java/lang/module/Dependence.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/launcher/defines.h ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/DirArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! test/TEST.ROOT - 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/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/Basic.java - test/java/util/ServiceLoader/FooProvider1.java - test/java/util/ServiceLoader/FooProvider2.java - test/java/util/ServiceLoader/FooProvider3.java - test/java/util/ServiceLoader/FooService.java - test/java/util/ServiceLoader/Load.java - test/java/util/ServiceLoader/basic.sh - 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/DTLSOverDatagram.java ! test/sun/net/www/protocol/http/NoNTLM.java From mandy.chung at oracle.com Fri Nov 18 02:05:46 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:46 +0000 Subject: hg: jigsaw/jake/langtools: 10 new changesets Message-ID: <201611180205.uAI25lC3027745@aojmv0008.oracle.com> Changeset: 6cc2220006f2 Author: lana Date: 2016-11-11 05:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6cc2220006f2 Merge Changeset: eb48b040fbc2 Author: jlahoda Date: 2016-11-11 12:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eb48b040fbc2 8145838: JShell: restrict RemoteAgent connection socket to localhost Summary: Also reviewed by Chris Ries Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java Changeset: 4c650abde107 Author: jlahoda Date: 2016-11-11 17:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4c650abde107 8169599: Several JShell tests are failing on Solaris after JDK-8145838 Summary: Partially reverting eb48b040fbc2 Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java Changeset: c5d46cf53534 Author: rfield Date: 2016-11-11 11:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c5d46cf53534 8166333: jshell tool: shortcut var does not import its type Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java Changeset: 768f685bceb7 Author: mchung Date: 2016-11-11 17:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/768f685bceb7 8168386: Fix jdeps verbose options Reviewed-by: dfuchs, lancea ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! test/tools/jdeps/DotFileTest.java + test/tools/jdeps/Options.java ! test/tools/jdeps/lib/JdepsRunner.java Changeset: c18249ecb690 Author: mchung Date: 2016-11-12 09:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c18249ecb690 8169606: jdeps --list-reduced-deps should not show java.base as all modules require it Reviewed-by: dfuchs ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java ! test/tools/jdeps/listdeps/ListModuleDeps.java + test/tools/jdeps/listdeps/src/hi/Hi.java Changeset: 120957324d6e Author: sadayapalam Date: 2016-11-14 19:45 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/120957324d6e 8168312: javac throws NPE if annotation processor is specified and module is declared in a file named arbitrarily Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java + test/tools/javac/modules/AnnotationProcessingWithModuleInfoInWrongPlace.java Changeset: cb9e896265ef Author: ksrini Date: 2016-11-14 16:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cb9e896265ef 8167967: javadoc should identify the ordinal value of enum constants Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.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/ConstructorWriterImpl.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/AnnotationTypeFieldBuilder.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/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/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/PropertyBuilder.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/VisibleMemberMap.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/jdk/javadoc/doclet/testOrdering/TestOrdering.java - test/jdk/javadoc/doclet/testOrdering/order/MethodOrder.java + test/jdk/javadoc/doclet/testOrdering/pkg5/AnnoFieldTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/AnnoOptionalTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/AnnoRequiredTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/CtorTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/EnumTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/FieldTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/IntfTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/MethodTest.java + test/jdk/javadoc/doclet/testOrdering/pkg5/PropertyTest.java Changeset: 26f972dc2d17 Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/26f972dc2d17 Added tag jdk-9+145 for changeset cb9e896265ef ! .hgtags Changeset: 72acc7c5dd6f Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/72acc7c5dd6f Merge ! .hgtags ! 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.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java - test/tools/javac/diags/examples/DuplicateExports/exported/Class.java - test/tools/javac/diags/examples/DuplicateExports/module-info.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/LeaksNotAccessibleNotRequiredPublic.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/api1/Api1.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/module-info.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/api2/Api2.java - test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/module-info.java - test/tools/javac/modules/RequiresPublicTest.java ! test/tools/jdeps/DotFileTest.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 Nov 18 02:05:50 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 02:05:50 +0000 Subject: hg: jigsaw/jake/nashorn: 5 new changesets Message-ID: <201611180205.uAI25ol2027792@aojmv0008.oracle.com> Changeset: cb625e28d779 Author: attila Date: 2016-11-11 15:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cb625e28d779 8168373: don't emit conversions for symbols outside their lexical scope Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/PrintVisitor.java + test/script/basic/es6/JDK-8168373.js Changeset: ac5035ff7ee9 Author: hannesw Date: 2016-11-11 18:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ac5035ff7ee9 8168049: Fix Performance of Lexer.isJSWhitespace Reviewed-by: sundar, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Lexer.java Changeset: 4a68dd740be8 Author: sdama Date: 2016-11-14 22:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4a68dd740be8 8156615: Catch parameter can be a BindingPattern in ES6 mode Summary: Added parser support for catch parameter being a binding pattern Reviewed-by: sundar, hannesw, attila Contributed-by: srinivas.dama at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/IRTranslator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! test/script/basic/es6/destructuring.js ! test/script/basic/es6/destructuring.js.EXPECTED + test/script/nosecurity/treeapi/destructuring_catch.js + test/script/nosecurity/treeapi/destructuring_catch.js.EXPECTED Changeset: f9d3c20b9585 Author: lana Date: 2016-11-17 17:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f9d3c20b9585 Added tag jdk-9+145 for changeset 4a68dd740be8 ! .hgtags Changeset: e7c817adf098 Author: mchung Date: 2016-11-17 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e7c817adf098 Merge ! .hgtags From jonathan.gibbons at oracle.com Fri Nov 18 05:33:33 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 18 Nov 2016 05:33:33 +0000 Subject: hg: jigsaw/jake/langtools: fix issues with deprecation on modules Message-ID: <201611180533.uAI5XXoi016150@aojmv0008.oracle.com> Changeset: b98dda53ad13 Author: jjg Date: 2016-11-17 21:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b98dda53ad13 fix issues with deprecation on modules ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.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/model/JavacElements.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/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! test/tools/javac/modules/AnnotationsOnModules.java ! test/tools/javac/tree/SourceTreeScannerTest.java From mandy.chung at oracle.com Fri Nov 18 06:07:08 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 06:07:08 +0000 Subject: hg: jigsaw/jake/hotspot: Merge multiple provides of the same service type Message-ID: <201611180607.uAI678Oi022977@aojmv0008.oracle.com> Changeset: 1273e7cc048b Author: mchung Date: 2016-11-17 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1273e7cc048b Merge multiple provides of the same service type ! src/jdk.vm.ci/share/classes/module-info.java From mandy.chung at oracle.com Fri Nov 18 06:07:17 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 06:07:17 +0000 Subject: hg: jigsaw/jake/jaxws: Merge multiple provides of the same service type Message-ID: <201611180607.uAI67Hac023136@aojmv0008.oracle.com> Changeset: 77a73360ee6b Author: mchung Date: 2016-11-17 21:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/77a73360ee6b Merge multiple provides of the same service type ! src/jdk.xml.bind/share/classes/module-info.java ! src/jdk.xml.ws/share/classes/module-info.java From mandy.chung at oracle.com Fri Nov 18 06:07:22 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 06:07:22 +0000 Subject: hg: jigsaw/jake/jdk: Merge multiple provides of the same service type Message-ID: <201611180607.uAI67MvU023191@aojmv0008.oracle.com> Changeset: e2110950087f Author: mchung Date: 2016-11-17 22:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e2110950087f Merge multiple provides of the same service type ! src/java.desktop/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jvmstat/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java From mandy.chung at oracle.com Fri Nov 18 06:07:50 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 06:07:50 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201611180607.uAI67oJ6023401@aojmv0008.oracle.com> Changeset: e25e195084d7 Author: mchung Date: 2016-11-17 21:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e25e195084d7 Fix test to use requires transitive ! test/tools/javac/modules/InvalidModuleDirective/module-info.java Changeset: 30107007ddc8 Author: mchung Date: 2016-11-17 22:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/30107007ddc8 Merge From mandy.chung at oracle.com Fri Nov 18 07:21:34 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Nov 2016 07:21:34 +0000 Subject: hg: jigsaw/jake/jdk: Revert provides change until javadoc supports it. Message-ID: <201611180721.uAI7LYSD008543@aojmv0008.oracle.com> Changeset: cc82cebf8689 Author: mchung Date: 2016-11-17 22:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cc82cebf8689 Revert provides change until javadoc supports it. ! src/java.desktop/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jvmstat/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java From adinn at redhat.com Fri Nov 18 16:43:46 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Nov 2016 16:43:46 +0000 Subject: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages In-Reply-To: References: <6BDF26F3-4676-4A6E-B0E6-AD0EC2C0192B@oracle.com> <0d084e7b-1ec7-741b-dbe6-5be4d4d56509@redhat.com> <8a2abf97-e799-ad13-671e-34db64407d24@redhat.com> <7dcb2d85-71da-9ad7-3bbe-6465c7660e3c@redhat.com> <966718282.2304538.1478876975064.JavaMail.zimbra@u-pem.fr> Message-ID: On 12/11/16 03:23, John Rose wrote: > On Nov 11, 2016, at 7:09 AM, forax at univ-mlv.fr > wrote: >> MH.invokeWithArguments takes an array of arguments but because it is >> specified as a varargs you may think that it works like Method.invoke, >> but it is a trap, >> it takes the receiver and the arguments altogether into the same array. > > Thanks, Remi. That should fix the problem. I'm not sure Remi's answer exactly addresses my question exactly as he explained what happens when there is a receiver for the call and my problem case is a static call. Anyway, I think I have got the picture and now know what is wrong. > We thought a little bit about adding more overloadings to > invokeWithArguments, > such as one that works like Method.invoke (one prepended argument). > The general case would be making invokeWithArguments be > signature-polymorphic, > with an on-the-fly asSpreader transform on the way through. > > But, such extra generality would simplify only a few use cases, and on the > other hand it would probably create plenty of confusion whenever the target > method is *also* a varargs method. My problem was that the String[] argument I was passing to Arrays.asList got wrapped in an enclosing Object[] array. That's because the method has a varargs signature and when you call the method handle returned by findStatic or findVirtual the arguments are expected to be provided unwrapped in the invoke call. Whereas a method handle for a method with a trailing Object[] argument (naturally) expects the argument to contain the relevant Objects wrapped in an Object[]. This is where the disparity with reflective invocation occurs where the varargs arguments must be provided pre-wrapped to the reflective invoke call. So, (excusing the expository-but-fake array literals used to show supplied arguments) where I reflectively call method.invoke(["first", "second", third"]) the corresponding handle call would be expected to be handle.invokeWithArguments("first", "second", "third") Similary, with a varargs instance method (let's call it Foo.foo(Object...) where the reflective call would be method.invoke(foo, ["first", "second", third"]) the corresponding handle call would be either handle.invokeWithArguments(foo, "first", "second", "third") or handle.bindTo(foo).invokeWithArguments("first", "second", "third") (I think that was what Remi was getting at :-) Of course, since I package the arguments in generci code and then invoke the method in code specific to JDK8[-] or JDK9[+] I am stuck with an Object for the receiver (or null for a static call) and an Object[] for the arguments. Hence, I cannot actually supply the arguments one by one in the method handle call. The fix I found is to detect the case where a method is varargs and in that case use method asfixedArity() to convert the method handle retrieved by findStatic or findVirtual to one which accepts the arguments pre-wrapped. So, where I currently have the following reflective code: Object receiver = ... Object[] args = ... Method method = ... boolean isStatic = ... if (isStatic) { method.invoke(null, args); } else { method.invoke(receiver, args); } I simply need to replace the latter 5 lines as . . . MethodType methodType = MethodType.methodType(method.getReturnType(), method.getParameterTypes()); MethodHandle handle; if (isStatic) { handle = theLookup.findStatic(method.getDeclaringClass(), method.getName(), methodType); } else { handle = theLookup.findVirtual(method.getDeclaringClass(), method.getName(), methodType); } if (method.isVarArgs()) { handle = handle.asfixedArity(); } if (isStatic) { handle.invokeWithArguments(args); } else { handle.bindTo(receiver).invokeWithArguments(args); } This appears to have resolved my problem. 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 mandy.chung at oracle.com Fri Nov 18 20:57:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Nov 2016 12:57:00 -0800 Subject: RFR: JDK-8168256 - Plugin alias options in jlink --help output seems to be in an arbitrary order In-Reply-To: References: Message-ID: <2F579D82-DF67-46BA-AAF9-EBC70F79D8E7@oracle.com> > On Nov 16, 2016, at 7:00 AM, Jim Laskey (Oracle) wrote: > > Sorts options by full name > > http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8168256 > 113 public Option(boolean hasArg, Processing processing, String name, String shortcut) { 114 this(hasArg, processing, false, name, ""); 115 } should be this(hasArg, processing, false, name, shortcut); 152 } else if (trimmedName.startsWith("-")) { 153 trimmedName = trimmedName.substring(1); 154 } Per JEP 293, jlink is a new tool that should have long form option names. This can be simplified (these 2 lines not needed) and the resource bundle key uses the long form name. Option constructor should validate the name parameter with two slashes prefix. Otherwise, looks good. Mandy From org.openjdk at io7m.com Fri Nov 18 21:40:13 2016 From: org.openjdk at io7m.com (org.openjdk at io7m.com) Date: Fri, 18 Nov 2016 21:40:13 +0000 Subject: onejars under Jigsaw Message-ID: <20161118214013.4a6404d4@copperhead.int.arc7.info> Hello! When I write command line applications, I typically produce an additional platform-independent "onejar" for convenience. More specifically, I use the Maven Shade plugin to pack all of the classes of all of the dependencies into a single jar with MainClass attribute. The main benefit of doing things this way is that the jar file remains platform independent (assuming that the code itself is platform independent). A good example of this is my kstructural package: http://io7m.github.io/kstructural/ The main command-line jar program is an amalgamation of all of the other modules and all dependencies: https://repo1.maven.org/maven2//com/io7m/kstructural/io7m-kstructural-cmdline/0.3.0/io7m-kstructural-cmdline-0.3.0-main.jar Is there already a facility to do this under Jigsaw? Jlink is not quite what I'm looking for in this case, because the produced artifacts would be platform-specific. Clearly, producing onejars in pre-Jigsaw Java is like taking all of the problems of the classpath and smashing them into one unfixable lump for deployment. The fact that we often get builds that appear to work using this method seems to owe a lot to blind luck. No doubt doing this sort of transformation is a hell of a lot safer when there are module boundaries to work with, services declared in module descriptors, and so on. I suspect I could address the same question to the Maven Shade list, but I thought I'd better check here first. :) M From forax at univ-mlv.fr Sat Nov 19 14:34:25 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 Nov 2016 15:34:25 +0100 (CET) Subject: Configuration.resolveRequires want providers of services to be in an exported package Message-ID: <1805156031.3433302.1479566065775.JavaMail.zimbra@u-pem.fr> Hi all, hi Alan, With 9-ea+144-jigsaw-nightly-h5735-20161117, it seems that Configuration.resolveRequires() do more checks than necessary, it checks that each provider of a service has its package exported, something which is not required by the spec. Maybe i'm wrong, but it should just check that the provider is in a package of the module, it seems that the error message agree :). cheers, R?mi Exception in thread "main" java.lang.module.ResolutionException: Provider com.github.forax.pro.main.JSONRunner not in module com.github.forax.pro.main at java.base/java.lang.module.Resolver.fail(Resolver.java:828) at java.base/java.lang.module.Resolver.checkExportSuppliers(Resolver.java:731) at java.base/java.lang.module.Resolver.finish(Resolver.java:286) at java.base/java.lang.module.Configuration.(Configuration.java:200) at java.base/java.lang.module.Configuration.resolveRequires(Configuration.java:412) at com.github.forax.pro.plugin.compiler/com.github.forax.pro.plugin.compiler.CompilerPlugin.execute(CompilerPlugin.java:94) at com.github.forax.pro/com.github.forax.pro.Pro.lambda$run$12(Pro.java:208) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:430) at com.github.forax.pro/com.github.forax.pro.Pro.run(Pro.java:206) at simpletest/com.github.forax.pro.test.Programmatic.main(Programmatic.java:64) From forax at univ-mlv.fr Sat Nov 19 14:44:12 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 Nov 2016 15:44:12 +0100 (CET) Subject: ModuleDescriptor.Builder.provides() is too restrictive Message-ID: <1979400920.3434385.1479566652058.JavaMail.zimbra@u-pem.fr> Hi all, Currently the spec supports two ways to declare several providers for one service: provides com.github.forax.pro.main.runner.Runner with com.github.forax.pro.main.JSONRunner, com.github.forax.pro.main.JShellRunner; or provides com.github.forax.pro.main.runner.Runner with com.github.forax.pro.main.JSONRunner; provides com.github.forax.pro.main.runner.Runner with com.github.forax.pro.main.JShellRunner; but the equivalent code declared using the ModuleDescriptor.Builder.provides() fails. cheers, R?mi Exception in thread "main" java.lang.IllegalStateException: Providers of service com.github.forax.pro.main.runner.Runner already declared by com.github.forax.pro.main at java.base/java.lang.module.ModuleDescriptor$Builder.provides(ModuleDescriptor.java:1807) at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.visitProvides(ModuleHelper.java:84) at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseProvides(ModuleParser.java:262) at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseModule(ModuleParser.java:202) at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parse(ModuleParser.java:153) at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.parse(ModuleHelper.java:89) at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper.sourceModuleDescriptor(ModuleHelper.java:95) ... From forax at univ-mlv.fr Sat Nov 19 14:52:53 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 Nov 2016 15:52:53 +0100 (CET) Subject: ModuleDescirptor.Builder and open module Message-ID: <1202538887.3435645.1479567173054.JavaMail.zimbra@u-pem.fr> Hi all (again), as far as i know, it seems there is no way to programmatically using the ModuleDescriptor.Builder API creates an open module. There is a package private method for that but no public visible method. cheers, R?mi From Alan.Bateman at oracle.com Sat Nov 19 17:22:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Nov 2016 17:22:13 +0000 Subject: Configuration.resolveRequires want providers of services to be in an exported package In-Reply-To: <1805156031.3433302.1479566065775.JavaMail.zimbra@u-pem.fr> References: <1805156031.3433302.1479566065775.JavaMail.zimbra@u-pem.fr> Message-ID: On 19/11/2016 14:34, Remi Forax wrote: > Hi all, hi Alan, > > With 9-ea+144-jigsaw-nightly-h5735-20161117, > it seems that Configuration.resolveRequires() do more checks than necessary, > it checks that each provider of a service has its package exported, something which is not required by the spec. > Maybe i'm wrong, but it should just check that the provider is in a package of the module, it seems that the error message agree :). > > cheers, > R?mi > > Exception in thread "main" java.lang.module.ResolutionException: Provider com.github.forax.pro.main.JSONRunner not in module com.github.forax.pro.main > This exception just means that the package isn't in the com.github.forax.pro.main, are you sure it's in the module? -Alan From Alan.Bateman at oracle.com Sat Nov 19 17:24:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Nov 2016 17:24:39 +0000 Subject: ModuleDescriptor.Builder.provides() is too restrictive In-Reply-To: <1979400920.3434385.1479566652058.JavaMail.zimbra@u-pem.fr> References: <1979400920.3434385.1479566652058.JavaMail.zimbra@u-pem.fr> Message-ID: On 19/11/2016 14:44, Remi Forax wrote: > Hi all, > Currently the spec supports two ways to declare several providers for one service: > provides com.github.forax.pro.main.runner.Runner > with com.github.forax.pro.main.JSONRunner, > com.github.forax.pro.main.JShellRunner; > or > provides com.github.forax.pro.main.runner.Runner with com.github.forax.pro.main.JSONRunner; > provides com.github.forax.pro.main.runner.Runner with com.github.forax.pro.main.JShellRunner; > > but the equivalent code declared using the ModuleDescriptor.Builder.provides() fails. The second form isn't allowed but javac is temporarily allowing it during the transition. So the exception is correct, except that I would expect InvalidModuleDescriptorException with what you have as the cause. -Alan > > cheers, > R?mi > > Exception in thread "main" java.lang.IllegalStateException: Providers of service com.github.forax.pro.main.runner.Runner already declared by com.github.forax.pro.main > at java.base/java.lang.module.ModuleDescriptor$Builder.provides(ModuleDescriptor.java:1807) > at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.visitProvides(ModuleHelper.java:84) > at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseProvides(ModuleParser.java:262) > at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseModule(ModuleParser.java:202) > at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parse(ModuleParser.java:153) > at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.parse(ModuleHelper.java:89) > at com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper.sourceModuleDescriptor(ModuleHelper.java:95) > ... > > From Alan.Bateman at oracle.com Sat Nov 19 17:26:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Nov 2016 17:26:47 +0000 Subject: ModuleDescirptor.Builder and open module In-Reply-To: <1202538887.3435645.1479567173054.JavaMail.zimbra@u-pem.fr> References: <1202538887.3435645.1479567173054.JavaMail.zimbra@u-pem.fr> Message-ID: On 19/11/2016 14:52, Remi Forax wrote: > Hi all (again), > as far as i know, it seems there is no way to programmatically using the ModuleDescriptor.Builder API creates an open module. > There is a package private method for that but no public visible method. > The builder API still needs a bit of work but this should do what you want: ModuleDescriptor descriptor = ModuleDescriptor.openModule("m1").requires("m2").exports("p").build(); -Alan From forax at univ-mlv.fr Sat Nov 19 17:42:51 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 19 Nov 2016 18:42:51 +0100 (CET) Subject: ModuleDescriptor.Builder.provides() is too restrictive In-Reply-To: References: <1979400920.3434385.1479566652058.JavaMail.zimbra@u-pem.fr> Message-ID: <239082400.3449597.1479577371187.JavaMail.zimbra@u-pem.fr> I have something fun currently, i've (at least) two errors in my configuration, and depending on the run i get one error or the other because the code is full of hashmap/hashset so the iteration order between runs changed :( R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "jigsaw-dev" > Envoy?: Samedi 19 Novembre 2016 18:24:39 > Objet: Re: ModuleDescriptor.Builder.provides() is too restrictive > On 19/11/2016 14:44, Remi Forax wrote: > >> Hi all, >> Currently the spec supports two ways to declare several providers for one >> service: >> provides com.github.forax.pro.main.runner.Runner >> with com.github.forax.pro.main.JSONRunner, >> com.github.forax.pro.main.JShellRunner; >> or >> provides com.github.forax.pro.main.runner.Runner with >> com.github.forax.pro.main.JSONRunner; >> provides com.github.forax.pro.main.runner.Runner with >> com.github.forax.pro.main.JShellRunner; >> >> but the equivalent code declared using the ModuleDescriptor.Builder.provides() >> fails. > The second form isn't allowed but javac is temporarily allowing it > during the transition. > > So the exception is correct, except that I would expect > InvalidModuleDescriptorException with what you have as the cause. > > -Alan > >> >> cheers, >> R?mi >> >> Exception in thread "main" java.lang.IllegalStateException: Providers of service >> com.github.forax.pro.main.runner.Runner already declared by >> com.github.forax.pro.main >> at >> java.base/java.lang.module.ModuleDescriptor$Builder.provides(ModuleDescriptor.java:1807) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.visitProvides(ModuleHelper.java:84) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseProvides(ModuleParser.java:262) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseModule(ModuleParser.java:202) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parse(ModuleParser.java:153) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.parse(ModuleHelper.java:89) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper.sourceModuleDescriptor(ModuleHelper.java:95) >> ... >> From forax at univ-mlv.fr Sat Nov 19 18:02:06 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 19 Nov 2016 19:02:06 +0100 (CET) Subject: Configuration.resolveRequires want providers of services to be in an exported package In-Reply-To: References: <1805156031.3433302.1479566065775.JavaMail.zimbra@u-pem.fr> Message-ID: <1513471353.3450591.1479578526341.JavaMail.zimbra@u-pem.fr> Ok, find the bug, obvious in retrospect, there is no way to declare a concealed package using the ModuleDescriptor.Builder so my configuration miss concealed packages thus the configuration that i try to verify is ill formed. The builder should be able to declare concealed packages or all packages. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "jigsaw-dev" > Envoy?: Samedi 19 Novembre 2016 18:22:13 > Objet: Re: Configuration.resolveRequires want providers of services to be in an exported package > On 19/11/2016 14:34, Remi Forax wrote: > >> Hi all, hi Alan, >> >> With 9-ea+144-jigsaw-nightly-h5735-20161117, >> it seems that Configuration.resolveRequires() do more checks than necessary, >> it checks that each provider of a service has its package exported, something >> which is not required by the spec. >> Maybe i'm wrong, but it should just check that the provider is in a package of >> the module, it seems that the error message agree :). >> >> cheers, >> R?mi >> >> Exception in thread "main" java.lang.module.ResolutionException: Provider >> com.github.forax.pro.main.JSONRunner not in module com.github.forax.pro.main >> > This exception just means that the package isn't in the > com.github.forax.pro.main, are you sure it's in the module? > > -Alan From forax at univ-mlv.fr Sat Nov 19 18:08:38 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 19 Nov 2016 19:08:38 +0100 (CET) Subject: ModuleDescriptor.Builder.provides() is too restrictive In-Reply-To: References: <1979400920.3434385.1479566652058.JavaMail.zimbra@u-pem.fr> Message-ID: <1021224146.3451238.1479578918862.JavaMail.zimbra@u-pem.fr> Ok ! R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "jigsaw-dev" > Envoy?: Samedi 19 Novembre 2016 18:24:39 > Objet: Re: ModuleDescriptor.Builder.provides() is too restrictive > On 19/11/2016 14:44, Remi Forax wrote: > >> Hi all, >> Currently the spec supports two ways to declare several providers for one >> service: >> provides com.github.forax.pro.main.runner.Runner >> with com.github.forax.pro.main.JSONRunner, >> com.github.forax.pro.main.JShellRunner; >> or >> provides com.github.forax.pro.main.runner.Runner with >> com.github.forax.pro.main.JSONRunner; >> provides com.github.forax.pro.main.runner.Runner with >> com.github.forax.pro.main.JShellRunner; >> >> but the equivalent code declared using the ModuleDescriptor.Builder.provides() >> fails. > The second form isn't allowed but javac is temporarily allowing it > during the transition. > > So the exception is correct, except that I would expect > InvalidModuleDescriptorException with what you have as the cause. > > -Alan > >> >> cheers, >> R?mi >> >> Exception in thread "main" java.lang.IllegalStateException: Providers of service >> com.github.forax.pro.main.runner.Runner already declared by >> com.github.forax.pro.main >> at >> java.base/java.lang.module.ModuleDescriptor$Builder.provides(ModuleDescriptor.java:1807) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.visitProvides(ModuleHelper.java:84) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseProvides(ModuleParser.java:262) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parseModule(ModuleParser.java:202) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleParser.parse(ModuleParser.java:153) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper$1.parse(ModuleHelper.java:89) >> at >> com.github.forax.pro.helper/com.github.forax.pro.helper.ModuleHelper.sourceModuleDescriptor(ModuleHelper.java:95) >> ... >> From Alan.Bateman at oracle.com Sat Nov 19 18:38:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Nov 2016 18:38:39 +0000 Subject: Configuration.resolveRequires want providers of services to be in an exported package In-Reply-To: <1513471353.3450591.1479578526341.JavaMail.zimbra@u-pem.fr> References: <1805156031.3433302.1479566065775.JavaMail.zimbra@u-pem.fr> <1513471353.3450591.1479578526341.JavaMail.zimbra@u-pem.fr> Message-ID: <55b4b0b7-7e70-1e48-2928-ae7da65bc41c@oracle.com> On 19/11/2016 18:02, forax at univ-mlv.fr wrote: > Ok, find the bug, obvious in retrospect, > there is no way to declare a concealed package using the ModuleDescriptor.Builder so my configuration miss concealed packages thus the configuration that i try to verify is ill formed. > > The builder should be able to declare concealed packages or all packages. > Is there any reason why you can't use the `contains` method, as in : ModuleDescriptor.module("m1").requires("m2").exports("p").contains("p.internal").build(); -Alan. From forax at univ-mlv.fr Sat Nov 19 19:19:37 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 19 Nov 2016 20:19:37 +0100 (CET) Subject: Configuration.resolveRequires want providers of services to be in an exported package In-Reply-To: <55b4b0b7-7e70-1e48-2928-ae7da65bc41c@oracle.com> References: <1805156031.3433302.1479566065775.JavaMail.zimbra@u-pem.fr> <1513471353.3450591.1479578526341.JavaMail.zimbra@u-pem.fr> <55b4b0b7-7e70-1e48-2928-ae7da65bc41c@oracle.com> Message-ID: <311948244.3455068.1479583177046.JavaMail.zimbra@u-pem.fr> Apart the fact that the method should be called packages(), no :) Also the implementation makes the order of the calls important, i.e. contains() has to be called after all the other methods. If you move the code that checks that a package can not be at the same time in concealed packages and in opens or exports in build(), the problem disappear. thanks, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: forax at univ-mlv.fr > Cc: "jigsaw-dev" > Envoy?: Samedi 19 Novembre 2016 19:38:39 > Objet: Re: Configuration.resolveRequires want providers of services to be in an exported package > On 19/11/2016 18:02, forax at univ-mlv.fr wrote: >> Ok, find the bug, obvious in retrospect, >> there is no way to declare a concealed package using the >> ModuleDescriptor.Builder so my configuration miss concealed packages thus the >> configuration that i try to verify is ill formed. >> >> The builder should be able to declare concealed packages or all packages. >> > Is there any reason why you can't use the `contains` method, as in : > ModuleDescriptor.module("m1").requires("m2").exports("p").contains("p.internal").build(); > > -Alan. From Alan.Bateman at oracle.com Sat Nov 19 19:43:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Nov 2016 19:43:45 +0000 Subject: Configuration.resolveRequires want providers of services to be in an exported package In-Reply-To: <311948244.3455068.1479583177046.JavaMail.zimbra@u-pem.fr> References: <1805156031.3433302.1479566065775.JavaMail.zimbra@u-pem.fr> <1513471353.3450591.1479578526341.JavaMail.zimbra@u-pem.fr> <55b4b0b7-7e70-1e48-2928-ae7da65bc41c@oracle.com> <311948244.3455068.1479583177046.JavaMail.zimbra@u-pem.fr> Message-ID: <50ace608-c2bc-c1eb-0eff-e54134ac76e0@oracle.com> On 19/11/2016 19:19, forax at univ-mlv.fr wrote: > Apart the fact that the method should be called packages(), no :) > > Also the implementation makes the order of the calls important, i.e. contains() has to be called after all the other methods. > If you move the code that checks that a package can not be at the same time in concealed packages and in opens or exports in build(), the problem disappear. > The ordering shouldn't matter, exports("p").contains("p.internal") and contains("p.internal").exports("p") will both declare an exported package and a non-exported package. Also exports("p").contains("p") and contains("p").exports("p") should both fail with ISE. Ditto for opens("p").contains("p") and contains("p").opens("p") -Alan. From michael.rasmussen at zeroturnaround.com Sat Nov 19 20:13:04 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Sat, 19 Nov 2016 22:13:04 +0200 Subject: onejars under Jigsaw In-Reply-To: <20161118214013.4a6404d4@copperhead.int.arc7.info> References: <20161118214013.4a6404d4@copperhead.int.arc7.info> Message-ID: Hi I don't know if it already exists somewhere, but it shouldn't be hard to create a main method that's loaded with -jar which then bootstraps all the modules found inside the jar file. For instance, say all your modules are inside your fatjar.jar!/mods directory, and you have the name of the main module / main class, then something like this might work: FileSystem fs = // create zip fs of the fatjar.jar finder = ModuleFinder.of(Files.walk(fs.getPath("/mods/")).toArray(Path[]::new)); config = Layer.boot().configuration().resolveRequires(finder, ModuleFinder.of(), Set.of(mainModuleName)); layer = Layer.boot().defineModulesWithOneLoader(config, ClassLoader.getSystemClassLoader()); layer.findLoader(mainModuleName).loadClass(mainClassName).getDeclaredMethod("main", String[].class).invoke(null, args); /Michael On 18 November 2016 at 23:40, wrote: > Hello! > > When I write command line applications, I typically produce an > additional platform-independent "onejar" for convenience. More > specifically, I use the Maven Shade plugin to pack all of the classes > of all of the dependencies into a single jar with MainClass attribute. > The main benefit of doing things this way is that the jar file remains > platform independent (assuming that the code itself is platform > independent). A good example of this is my kstructural package: > > http://io7m.github.io/kstructural/ > > The main command-line jar program is an amalgamation of all of the > other modules and all dependencies: > > https://repo1.maven.org/maven2//com/io7m/kstructural/ > io7m-kstructural-cmdline/0.3.0/io7m-kstructural-cmdline-0.3.0-main.jar > > Is there already a facility to do this under Jigsaw? Jlink is not quite > what I'm looking for in this case, because the produced artifacts would > be platform-specific. > > Clearly, producing onejars in pre-Jigsaw Java is like taking all of the > problems of the classpath and smashing them into one unfixable lump for > deployment. The fact that we often get builds that appear to work using > this method seems to owe a lot to blind luck. > > No doubt doing this sort of transformation is a hell of a lot safer when > there are module boundaries to work with, services declared in module > descriptors, and so on. > > I suspect I could address the same question to the Maven Shade list, > but I thought I'd better check here first. :) > > M > From forax at univ-mlv.fr Sat Nov 19 20:39:49 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 Nov 2016 21:39:49 +0100 (CET) Subject: Configuration checks on uses service is too strict Message-ID: <31915774.3458536.1479587989951.JavaMail.zimbra@u-pem.fr> Ok, i may have a found bug. The spec says (section 1.1.3) "The service interface may be declared in the current module or in another module. If the service interface is not declared in the current module, then the service interface must be accessible to code in the current module, or a compile-time error occurs. " but the check in Resolve.checkExportSuppliers is this one: // uses S for (String service : descriptor1.uses()) { String pn = packageName(service); if (!packageToExporter.containsKey(pn)) { fail("Module %s does not read a module that exports %s", descriptor1.name(), pn); } } which doesn't take care of the case of a service interface declared in another module. regards, R?mi From rfscholte at apache.org Sat Nov 19 21:53:17 2016 From: rfscholte at apache.org (Robert Scholte) Date: Sat, 19 Nov 2016 22:53:17 +0100 Subject: onejars under Jigsaw In-Reply-To: <20161118214013.4a6404d4@copperhead.int.arc7.info> References: <20161118214013.4a6404d4@copperhead.int.arc7.info> Message-ID: Hi, The following topics have been created for this issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs Once resolved we should improve the maven-shade-plugin according the new specifications. Robert On Fri, 18 Nov 2016 22:40:13 +0100, wrote: > Hello! > > When I write command line applications, I typically produce an > additional platform-independent "onejar" for convenience. More > specifically, I use the Maven Shade plugin to pack all of the classes > of all of the dependencies into a single jar with MainClass attribute. > The main benefit of doing things this way is that the jar file remains > platform independent (assuming that the code itself is platform > independent). A good example of this is my kstructural package: > > http://io7m.github.io/kstructural/ > > The main command-line jar program is an amalgamation of all of the > other modules and all dependencies: > > https://repo1.maven.org/maven2//com/io7m/kstructural/io7m-kstructural-cmdline/0.3.0/io7m-kstructural-cmdline-0.3.0-main.jar > > Is there already a facility to do this under Jigsaw? Jlink is not quite > what I'm looking for in this case, because the produced artifacts would > be platform-specific. > > Clearly, producing onejars in pre-Jigsaw Java is like taking all of the > problems of the classpath and smashing them into one unfixable lump for > deployment. The fact that we often get builds that appear to work using > this method seems to owe a lot to blind luck. > > No doubt doing this sort of transformation is a hell of a lot safer when > there are module boundaries to work with, services declared in module > descriptors, and so on. > > I suspect I could address the same question to the Maven Shade list, > but I thought I'd better check here first. :) > > M From Alan.Bateman at oracle.com Sat Nov 19 22:12:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Nov 2016 22:12:16 +0000 Subject: Configuration checks on uses service is too strict In-Reply-To: <31915774.3458536.1479587989951.JavaMail.zimbra@u-pem.fr> References: <31915774.3458536.1479587989951.JavaMail.zimbra@u-pem.fr> Message-ID: <78d3c18f-577f-4f98-c42e-aef5c81c6f88@oracle.com> On 19/11/2016 20:39, Remi Forax wrote: > Ok, i may have a found bug. > > The spec says (section 1.1.3) > "The service interface may be declared in the current module or in another module. If the service interface is not declared in the current module, then the service interface must be accessible to code in the current module, or a compile-time error occurs." > but the check in Resolve.checkExportSuppliers is this one: > // uses S > for (String service : descriptor1.uses()) { > String pn = packageName(service); > if (!packageToExporter.containsKey(pn)) { > fail("Module %s does not read a module that exports %s", > descriptor1.name(), pn); > } > } > which doesn't take care of the case of a service interface declared in another module. > I don't see a bug here. If m1 `uses p.S` and m1 reads m2 that exports p to at least m1 then this map will contain p -> m2. -Alan. From forax at univ-mlv.fr Sun Nov 20 13:39:37 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 20 Nov 2016 14:39:37 +0100 (CET) Subject: Configuration checks on uses service is too strict In-Reply-To: <78d3c18f-577f-4f98-c42e-aef5c81c6f88@oracle.com> References: <31915774.3458536.1479587989951.JavaMail.zimbra@u-pem.fr> <78d3c18f-577f-4f98-c42e-aef5c81c6f88@oracle.com> Message-ID: <1872328114.3506948.1479649177471.JavaMail.zimbra@u-pem.fr> Sorry, again, not a bug, i've forgotten to add java.base by default, i was thinking that the ModuleDescriptor.Builder was adding it by default but this is not the case. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "jigsaw-dev" > Envoy?: Samedi 19 Novembre 2016 23:12:16 > Objet: Re: Configuration checks on uses service is too strict > On 19/11/2016 20:39, Remi Forax wrote: > >> Ok, i may have a found bug. >> >> The spec says (section 1.1.3) >> "The service interface may be declared in the current module or in another >> module. If the service interface is not declared in the current module, then >> the service interface must be accessible to code in the current module, or a >> compile-time error occurs." >> but the check in Resolve.checkExportSuppliers is this one: >> // uses S >> for (String service : descriptor1.uses()) { >> String pn = packageName(service); >> if (!packageToExporter.containsKey(pn)) { >> fail("Module %s does not read a module that exports %s", >> descriptor1.name(), pn); >> } >> } >> which doesn't take care of the case of a service interface declared in another >> module. >> > I don't see a bug here. If m1 `uses p.S` and m1 reads m2 that exports p > to at least m1 then this map will contain p -> m2. > > -Alan. From forax at univ-mlv.fr Sun Nov 20 13:44:30 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 20 Nov 2016 14:44:30 +0100 (CET) Subject: onejars under Jigsaw In-Reply-To: References: <20161118214013.4a6404d4@copperhead.int.arc7.info> Message-ID: <536426202.3507527.1479649470168.JavaMail.zimbra@u-pem.fr> I wonder how far this is different from having more than one implementation for jrt ? If we can see a uberjar as a module file system, all the other tools will work on it. Can an uberjar be see as a kind of mount point in the jrt filesystem ? R?mi ----- Mail original ----- > De: "Robert Scholte" > ?: jigsaw-dev at openjdk.java.net, "org openjdk" > Envoy?: Samedi 19 Novembre 2016 22:53:17 > Objet: Re: onejars under Jigsaw > Hi, > > The following topics have been created for this issue: > http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs > http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs > > Once resolved we should improve the maven-shade-plugin according the new > specifications. > > Robert > > > On Fri, 18 Nov 2016 22:40:13 +0100, wrote: > >> Hello! >> >> When I write command line applications, I typically produce an >> additional platform-independent "onejar" for convenience. More >> specifically, I use the Maven Shade plugin to pack all of the classes >> of all of the dependencies into a single jar with MainClass attribute. >> The main benefit of doing things this way is that the jar file remains >> platform independent (assuming that the code itself is platform >> independent). A good example of this is my kstructural package: >> >> http://io7m.github.io/kstructural/ >> >> The main command-line jar program is an amalgamation of all of the >> other modules and all dependencies: >> >> https://repo1.maven.org/maven2//com/io7m/kstructural/io7m-kstructural-cmdline/0.3.0/io7m-kstructural-cmdline-0.3.0-main.jar >> >> Is there already a facility to do this under Jigsaw? Jlink is not quite >> what I'm looking for in this case, because the produced artifacts would >> be platform-specific. >> >> Clearly, producing onejars in pre-Jigsaw Java is like taking all of the >> problems of the classpath and smashing them into one unfixable lump for >> deployment. The fact that we often get builds that appear to work using >> this method seems to owe a lot to blind luck. >> >> No doubt doing this sort of transformation is a hell of a lot safer when >> there are module boundaries to work with, services declared in module >> descriptors, and so on. >> >> I suspect I could address the same question to the Maven Shade list, >> but I thought I'd better check here first. :) >> > > M From forax at univ-mlv.fr Sun Nov 20 18:50:52 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 20 Nov 2016 19:50:52 +0100 (CET) Subject: using javac to parse module-info.java Message-ID: <1711016357.3539287.1479667852306.JavaMail.zimbra@u-pem.fr> After having written my own parser of module-info.java and see it burn in flames because it doesn't manage unicodes and comments correctly, i've decided to directly use the javac parser for that. I want to post the code here for several reason, one is that it can help others, the other is that it uses com.sun.source.tree and i'm not sure i use it in a kosher way. https://gist.github.com/forax/5b8d52ac28db1126e2c1ed4e0461f550 regards, R?mi PS: it doesn't recognize the open directive because the version i use (b144) doesn't support it yet. From eirbjo at gmail.com Sun Nov 20 21:57:04 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Sun, 20 Nov 2016 22:57:04 +0100 Subject: javac --add-modules java.xml.bind for annotation processor? Message-ID: Hi there! I'm giving Java 9 and Jigsaw a spin on a moderately complex project. (Interestingly, the project is itself a module system, so we do stuff like annotation processing and dynamic reloading of class loader graphs and services) I'm experienced enough with advanced Java to have shot myself in the foot with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundException :-) However, I've only recently been looking into Jigsaw in concrete terms. So please be kind when I expose my ignorance :-) Initially, I just want to see if I can get the project to compile on Java 9. So I'm using --add-modules to javac here and there to add modules not available to the unnamed module by default. (Not making any proper modules yet, that will be the next step). This seems to be working fine, except for one of our annotation processors, which happens to use JAXBContext from java.xml.bind. I added --add-modules to javac (via Maven configuration), but my annotation processor still can't load JAXBContext and fails with this message: $ java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+144) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) $ mvn clean install -e This fails with: Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext at com.example.processor.ProcessorUsingJavaXmlBind.process(ProcessorUsingJavaXmlBind.java:24) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(JavacProcessingEnvironment.java:106) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1182) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1290) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1260) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:939) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(JavacTaskImpl.java:106) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(JavacTaskImpl.java:100) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:137) ... 28 more I've confirmed that this reproduces using only javac: $ cd example-module $ javac -d target/classes -classpath target/classes:$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules java.xml.bind src/main/java/com/example/module/SomeClass.java java.xml? true java.xml.bind? false An annotation processor threw an uncaught exception. Consult the following stack trace for details. java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext at com.example.processor.ProcessorUsingJavaXmlBind.process(ProcessorUsingJavaXmlBind.java:24) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) I've reduced this to a minimal-ish test case, available on Github: https://github.com/eirbjo/java-xml-bind-processor Here's the annotation processor: https://github.com/eirbjo/java-xml-bind-processor/blob/master/annotation-processor/src/main/java/com/example/processor/ProcessorUsingJavaXmlBind.java The class under compilation and the annotation: https://github.com/eirbjo/java-xml-bind-processor/blob/master/example-module/src/main/java/com/example/module/SomeClass.java https://github.com/eirbjo/java-xml-bind-processor/blob/master/example-module/src/main/java/com/example/module/SomeAnnotation.java Any clues? Cheers, Eirik. From eirbjo at gmail.com Sun Nov 20 22:21:34 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Sun, 20 Nov 2016 23:21:34 +0100 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: References: Message-ID: I found that when I use this instead: javac -J--add-modules -Jjava.xml.bind then java.xml.bind is made available to my annotation processor and javac is able to compile. Two quick questions: 1) Is this by design? 2) How would this work if I made my annotation processor a proper module which required java.xml.bind? In my initial testing, the processor isn't picked when if I move it from -classpath to --module-path. Cheers, Eirik. On Sun, Nov 20, 2016 at 10:57 PM, Eirik Bj?rsn?s wrote: > > Hi there! > > I'm giving Java 9 and Jigsaw a spin on a moderately complex project. > (Interestingly, the project is itself a module system, so we do stuff like > annotation processing and dynamic reloading of class loader graphs and > services) > > I'm experienced enough with advanced Java to have shot myself in the foot > with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundException > :-) However, I've only recently been looking into Jigsaw in concrete terms. > So please be kind when I expose my ignorance :-) > > Initially, I just want to see if I can get the project to compile on Java > 9. > > So I'm using --add-modules to javac here and there to add modules not > available to the unnamed module by default. (Not making any proper modules > yet, that will be the next step). > > This seems to be working fine, except for one of our annotation > processors, which happens to use JAXBContext from java.xml.bind. > > I added --add-modules to javac (via Maven configuration), but my > annotation processor still can't load JAXBContext and fails with this > message: > > $ java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+144) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) > > $ mvn clean install -e > > This fails with: > > Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext > at com.example.processor.ProcessorUsingJavaXmlBind.process( > ProcessorUsingJavaXmlBind.java:24) > at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment. > callProcessor(JavacProcessingEnvironment.java:959) > at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment. > discoverAndRunProcs(JavacProcessingEnvironment.java:875) > at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment. > access$2100(JavacProcessingEnvironment.java:106) > at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ > Round.run(JavacProcessingEnvironment.java:1182) > at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment. > doProcessing(JavacProcessingEnvironment.java:1290) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations( > JavaCompiler.java:1260) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler. > compile(JavaCompiler.java:939) > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1. > call(JavacTaskImpl.java:106) > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1. > call(JavacTaskImpl.java:100) > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions( > JavacTaskImpl.java:137) > ... 28 more > > I've confirmed that this reproduces using only javac: > > $ cd example-module > > $ javac -d target/classes -classpath target/classes:$HOME/.m2/ > repository/com/example/annotation-processor/1.0- > SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: -sourcepath > src/main/java/ -target 1.9 -source 1.9 --add-modules java.xml.bind > src/main/java/com/example/module/SomeClass.java > > java.xml? true > java.xml.bind? false > > > An annotation processor threw an uncaught exception. > Consult the following stack trace for details. > java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext > at com.example.processor.ProcessorUsingJavaXmlBind.process( > ProcessorUsingJavaXmlBind.java:24) > at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment. > callProcessor(JavacProcessingEnvironment.java:959) > > > I've reduced this to a minimal-ish test case, available on Github: > > https://github.com/eirbjo/java-xml-bind-processor > > Here's the annotation processor: > > https://github.com/eirbjo/java-xml-bind-processor/blob/ > master/annotation-processor/src/main/java/com/example/processor/ > ProcessorUsingJavaXmlBind.java > > The class under compilation and the annotation: > > https://github.com/eirbjo/java-xml-bind-processor/blob/ > master/example-module/src/main/java/com/example/module/SomeClass.java > https://github.com/eirbjo/java-xml-bind-processor/blob/ > master/example-module/src/main/java/com/example/module/SomeAnnotation.java > > > Any clues? > > Cheers, > Eirik. > > > > From claes.redestad at oracle.com Sun Nov 20 22:23:26 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 20 Nov 2016 23:23:26 +0100 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: References: Message-ID: <5832225E.8010503@oracle.com> Hi Eirik, compiling com.example.processor.ProcessorUsingJavaXmlBind standalone seems to work fine with --add-modules java.xml.bind - instead it appears as if maven-compiler-plugin doesn't preserve argument order, so you need to use the joined argument form in your pom.xml: --add-modules=java.xml.bind I tried this on your minified example, and seems to work. Thanks! /Claes On 2016-11-20 22:57, Eirik Bj?rsn?s wrote: > Hi there! > > I'm giving Java 9 and Jigsaw a spin on a moderately complex project. > (Interestingly, the project is itself a module system, so we do stuff like > annotation processing and dynamic reloading of class loader graphs and > services) > > I'm experienced enough with advanced Java to have shot myself in the foot > with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundException > :-) However, I've only recently been looking into Jigsaw in concrete terms. > So please be kind when I expose my ignorance :-) > > Initially, I just want to see if I can get the project to compile on Java 9. > > So I'm using --add-modules to javac here and there to add modules not > available to the unnamed module by default. (Not making any proper modules > yet, that will be the next step). > > This seems to be working fine, except for one of our annotation processors, > which happens to use JAXBContext from java.xml.bind. > > I added --add-modules to javac (via Maven configuration), but my annotation > processor still can't load JAXBContext and fails with this message: > > $ java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+144) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) > > $ mvn clean install -e > > This fails with: > > Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext > at > com.example.processor.ProcessorUsingJavaXmlBind.process(ProcessorUsingJavaXmlBind.java:24) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(JavacProcessingEnvironment.java:106) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1182) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1290) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1260) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:939) > at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(JavacTaskImpl.java:106) > at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(JavacTaskImpl.java:100) > at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:137) > ... 28 more > > I've confirmed that this reproduces using only javac: > > $ cd example-module > > $ javac -d target/classes -classpath > target/classes:$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: > -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules > java.xml.bind src/main/java/com/example/module/SomeClass.java > > java.xml? true > java.xml.bind? false > > > An annotation processor threw an uncaught exception. > Consult the following stack trace for details. > java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext > at > com.example.processor.ProcessorUsingJavaXmlBind.process(ProcessorUsingJavaXmlBind.java:24) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) > > > I've reduced this to a minimal-ish test case, available on Github: > > https://github.com/eirbjo/java-xml-bind-processor > > Here's the annotation processor: > > https://github.com/eirbjo/java-xml-bind-processor/blob/master/annotation-processor/src/main/java/com/example/processor/ProcessorUsingJavaXmlBind.java > > The class under compilation and the annotation: > > https://github.com/eirbjo/java-xml-bind-processor/blob/master/example-module/src/main/java/com/example/module/SomeClass.java > https://github.com/eirbjo/java-xml-bind-processor/blob/master/example-module/src/main/java/com/example/module/SomeAnnotation.java > > > Any clues? > > Cheers, > Eirik. > From eirbjo at gmail.com Sun Nov 20 22:43:44 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Sun, 20 Nov 2016 23:43:44 +0100 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: <5832225E.8010503@oracle.com> References: <5832225E.8010503@oracle.com> Message-ID: Claes, I tested this using javac directly on the command line, like this $ cd example-module $ javac -J--add-modules -Jjava.xml.bind -d target/classes -classpath target/classes:$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar -sourcepath src/main/java/ -target 1.9 -source 1.9 src/main/java/com/example/module/SomeClass.java java.xml? true java.xml.bind? true class javax.xml.bind.JAXBContext The above works (you can see that the processor is applied prints some debug info) Maven seems to the -J arguments somehow. Here's my current maven-compiler-plugin configuration: true -J--add-modules -Jjava.xml.bind This gives the following output from mvn clean compile -X : [DEBUG] Command line options: [DEBUG] -d target/classes -classpath target/classes:$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: -sourcepath src/main/java:target/generated-sources/annotations src/main/java/com/example/module/SomeClass.java src/main/java/com/example/module/SomeAnnotation.java -s target/generated-sources/annotations -g -nowarn -target 1.9 -source 1.9 (Absolute paths cleaned up for readability..) Eirik. On Sun, Nov 20, 2016 at 11:23 PM, Claes Redestad wrote: > Hi Eirik, > > compiling com.example.processor.ProcessorUsingJavaXmlBind standalone > seems to work fine with --add-modules java.xml.bind - instead it > appears as if maven-compiler-plugin doesn't preserve argument order, so > you need to use the joined argument form in your pom.xml: > > --add-modules=java.xml.bind > > I tried this on your minified example, and seems to work. Thanks! > > /Claes > > > On 2016-11-20 22:57, Eirik Bj?rsn?s wrote: > >> Hi there! >> >> I'm giving Java 9 and Jigsaw a spin on a moderately complex project. >> (Interestingly, the project is itself a module system, so we do stuff like >> annotation processing and dynamic reloading of class loader graphs and >> services) >> >> I'm experienced enough with advanced Java to have shot myself in the foot >> with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundException >> :-) However, I've only recently been looking into Jigsaw in concrete >> terms. >> So please be kind when I expose my ignorance :-) >> >> Initially, I just want to see if I can get the project to compile on Java >> 9. >> >> So I'm using --add-modules to javac here and there to add modules not >> available to the unnamed module by default. (Not making any proper modules >> yet, that will be the next step). >> >> This seems to be working fine, except for one of our annotation >> processors, >> which happens to use JAXBContext from java.xml.bind. >> >> I added --add-modules to javac (via Maven configuration), but my >> annotation >> processor still can't load JAXBContext and fails with this message: >> >> $ java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+144) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >> >> $ mvn clean install -e >> >> This fails with: >> >> Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >> at >> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >> essorUsingJavaXmlBind.java:24) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.access$2100(JavacProcessingEnvironment.java:106) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment$Round.run(JavacProcessingEnvironment.java:1182) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.doProcessing(JavacProcessingEnvironment.java:1290) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAn >> notations(JavaCompiler.java:1260) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile( >> JavaCompiler.java:939) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call( >> JavacTaskImpl.java:106) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call( >> JavacTaskImpl.java:100) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExc >> eptions(JavacTaskImpl.java:137) >> ... 28 more >> >> I've confirmed that this reproduces using only javac: >> >> $ cd example-module >> >> $ javac -d target/classes -classpath >> target/classes:$HOME/.m2/repository/com/example/annotation- >> processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: >> -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules >> java.xml.bind src/main/java/com/example/module/SomeClass.java >> >> java.xml? true >> java.xml.bind? false >> >> >> An annotation processor threw an uncaught exception. >> Consult the following stack trace for details. >> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >> at >> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >> essorUsingJavaXmlBind.java:24) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >> >> >> I've reduced this to a minimal-ish test case, available on Github: >> >> https://github.com/eirbjo/java-xml-bind-processor >> >> Here's the annotation processor: >> >> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >> r/annotation-processor/src/main/java/com/example/processo >> r/ProcessorUsingJavaXmlBind.java >> >> The class under compilation and the annotation: >> >> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >> r/example-module/src/main/java/com/example/module/SomeClass.java >> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >> r/example-module/src/main/java/com/example/module/SomeAnnotation.java >> >> >> Any clues? >> >> Cheers, >> Eirik. >> >> From eirbjo at gmail.com Sun Nov 20 22:45:38 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Sun, 20 Nov 2016 23:45:38 +0100 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: <5832225E.8010503@oracle.com> References: <5832225E.8010503@oracle.com> Message-ID: Claes, Btw, the annotation processor has been _compiling_ fine all along. The problem happens when the example-module is compiled with the annotation-processor on the javac -classpath Eirik. On Sun, Nov 20, 2016 at 11:23 PM, Claes Redestad wrote: > Hi Eirik, > > compiling com.example.processor.ProcessorUsingJavaXmlBind standalone > seems to work fine with --add-modules java.xml.bind - instead it > appears as if maven-compiler-plugin doesn't preserve argument order, so > you need to use the joined argument form in your pom.xml: > > --add-modules=java.xml.bind > > I tried this on your minified example, and seems to work. Thanks! > > /Claes > > > On 2016-11-20 22:57, Eirik Bj?rsn?s wrote: > >> Hi there! >> >> I'm giving Java 9 and Jigsaw a spin on a moderately complex project. >> (Interestingly, the project is itself a module system, so we do stuff like >> annotation processing and dynamic reloading of class loader graphs and >> services) >> >> I'm experienced enough with advanced Java to have shot myself in the foot >> with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundException >> :-) However, I've only recently been looking into Jigsaw in concrete >> terms. >> So please be kind when I expose my ignorance :-) >> >> Initially, I just want to see if I can get the project to compile on Java >> 9. >> >> So I'm using --add-modules to javac here and there to add modules not >> available to the unnamed module by default. (Not making any proper modules >> yet, that will be the next step). >> >> This seems to be working fine, except for one of our annotation >> processors, >> which happens to use JAXBContext from java.xml.bind. >> >> I added --add-modules to javac (via Maven configuration), but my >> annotation >> processor still can't load JAXBContext and fails with this message: >> >> $ java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+144) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >> >> $ mvn clean install -e >> >> This fails with: >> >> Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >> at >> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >> essorUsingJavaXmlBind.java:24) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.access$2100(JavacProcessingEnvironment.java:106) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment$Round.run(JavacProcessingEnvironment.java:1182) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.doProcessing(JavacProcessingEnvironment.java:1290) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAn >> notations(JavaCompiler.java:1260) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile( >> JavaCompiler.java:939) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call( >> JavacTaskImpl.java:106) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call( >> JavacTaskImpl.java:100) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExc >> eptions(JavacTaskImpl.java:137) >> ... 28 more >> >> I've confirmed that this reproduces using only javac: >> >> $ cd example-module >> >> $ javac -d target/classes -classpath >> target/classes:$HOME/.m2/repository/com/example/annotation- >> processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: >> -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules >> java.xml.bind src/main/java/com/example/module/SomeClass.java >> >> java.xml? true >> java.xml.bind? false >> >> >> An annotation processor threw an uncaught exception. >> Consult the following stack trace for details. >> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >> at >> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >> essorUsingJavaXmlBind.java:24) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >> >> >> I've reduced this to a minimal-ish test case, available on Github: >> >> https://github.com/eirbjo/java-xml-bind-processor >> >> Here's the annotation processor: >> >> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >> r/annotation-processor/src/main/java/com/example/processo >> r/ProcessorUsingJavaXmlBind.java >> >> The class under compilation and the annotation: >> >> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >> r/example-module/src/main/java/com/example/module/SomeClass.java >> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >> r/example-module/src/main/java/com/example/module/SomeAnnotation.java >> >> >> Any clues? >> >> Cheers, >> Eirik. >> >> From forax at univ-mlv.fr Sun Nov 20 23:22:42 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 21 Nov 2016 00:22:42 +0100 (CET) Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: <5832225E.8010503@oracle.com> References: <5832225E.8010503@oracle.com> Message-ID: <1742370432.7773.1479684162641.JavaMail.zimbra@u-pem.fr> It seems to me that all the command line options of the VM before jigsaw doesn't use space as a separator, but with the new option like --module-path or --add-modules, you have to put a space after, so it doesn't work well with the -J option used to take option from tools like javac to feed them to the VM, because the space in the middle of the VM option is interpreted as a space between the options of the tool. regards, R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: jigsaw-dev at openjdk.java.net, eirbjo at gmail.com > Envoy?: Dimanche 20 Novembre 2016 23:23:26 > Objet: Re: javac --add-modules java.xml.bind for annotation processor? > Hi Eirik, > > compiling com.example.processor.ProcessorUsingJavaXmlBind standalone > seems to work fine with --add-modules java.xml.bind - instead it > appears as if maven-compiler-plugin doesn't preserve argument order, so > you need to use the joined argument form in your pom.xml: > > --add-modules=java.xml.bind > > I tried this on your minified example, and seems to work. Thanks! > > /Claes > > On 2016-11-20 22:57, Eirik Bj?rsn?s wrote: >> Hi there! >> >> I'm giving Java 9 and Jigsaw a spin on a moderately complex project. >> (Interestingly, the project is itself a module system, so we do stuff like >> annotation processing and dynamic reloading of class loader graphs and >> services) >> >> I'm experienced enough with advanced Java to have shot myself in the foot >> with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundException >> :-) However, I've only recently been looking into Jigsaw in concrete terms. >> So please be kind when I expose my ignorance :-) >> >> Initially, I just want to see if I can get the project to compile on Java 9. >> >> So I'm using --add-modules to javac here and there to add modules not >> available to the unnamed module by default. (Not making any proper modules >> yet, that will be the next step). >> >> This seems to be working fine, except for one of our annotation processors, >> which happens to use JAXBContext from java.xml.bind. >> >> I added --add-modules to javac (via Maven configuration), but my annotation >> processor still can't load JAXBContext and fails with this message: >> >> $ java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+144) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >> >> $ mvn clean install -e >> >> This fails with: >> >> Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >> at >> com.example.processor.ProcessorUsingJavaXmlBind.process(ProcessorUsingJavaXmlBind.java:24) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(JavacProcessingEnvironment.java:106) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1182) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1290) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1260) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:939) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(JavacTaskImpl.java:106) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(JavacTaskImpl.java:100) >> at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:137) >> ... 28 more >> >> I've confirmed that this reproduces using only javac: >> >> $ cd example-module >> >> $ javac -d target/classes -classpath >> target/classes:$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: >> -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules >> java.xml.bind src/main/java/com/example/module/SomeClass.java >> >> java.xml? true >> java.xml.bind? false >> >> >> An annotation processor threw an uncaught exception. >> Consult the following stack trace for details. >> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >> at >> com.example.processor.ProcessorUsingJavaXmlBind.process(ProcessorUsingJavaXmlBind.java:24) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:959) >> >> >> I've reduced this to a minimal-ish test case, available on Github: >> >> https://github.com/eirbjo/java-xml-bind-processor >> >> Here's the annotation processor: >> >> https://github.com/eirbjo/java-xml-bind-processor/blob/master/annotation-processor/src/main/java/com/example/processor/ProcessorUsingJavaXmlBind.java >> >> The class under compilation and the annotation: >> >> https://github.com/eirbjo/java-xml-bind-processor/blob/master/example-module/src/main/java/com/example/module/SomeClass.java >> https://github.com/eirbjo/java-xml-bind-processor/blob/master/example-module/src/main/java/com/example/module/SomeAnnotation.java >> >> >> Any clues? >> >> Cheers, >> Eirik. From claes.redestad at oracle.com Sun Nov 20 23:37:17 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Nov 2016 00:37:17 +0100 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: References: <5832225E.8010503@oracle.com> Message-ID: <583233AD.4030403@oracle.com> Ah, I underestimated the trickiness of the issue you're facing since I hit a similar error you reported when simply compiling the annotation- processor module using a jake build (but it compiles fine with jdk9/dev). I'd also note that your -J--add-modules -Jjava.xml.bind workaround - works on jdk9/dev but doesn't seem to work on jake ("Module java.xml.bind not found"), so there does appear to be some issues to get to the bottom of here. Thanks! /Claes On 2016-11-20 23:43, Eirik Bj?rsn?s wrote: > Claes, > > I tested this using javac directly on the command line, like this > > $ cd example-module > $ javac -J--add-modules -Jjava.xml.bind -d target/classes -classpath > target/classes:$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar > -sourcepath src/main/java/ -target 1.9 -source 1.9 > src/main/java/com/example/module/SomeClass.java > > java.xml? true > java.xml.bind? true > class javax.xml.bind.JAXBContext > > The above works (you can see that the processor is applied prints some > debug info) > > Maven seems to the -J arguments somehow. Here's my current > maven-compiler-plugin configuration: > > > true > > -J--add-modules > -Jjava.xml.bind > > > > This gives the following output from mvn clean compile -X : > > [DEBUG] Command line options: > [DEBUG] -d target/classes -classpath > target/classes:$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: > -sourcepath src/main/java:target/generated-sources/annotations > src/main/java/com/example/module/SomeClass.java > src/main/java/com/example/module/SomeAnnotation.java -s > target/generated-sources/annotations -g -nowarn -target 1.9 -source 1.9 > > (Absolute paths cleaned up for readability..) > > Eirik. > > > > On Sun, Nov 20, 2016 at 11:23 PM, Claes Redestad > wrote: > >> Hi Eirik, >> >> compiling com.example.processor.ProcessorUsingJavaXmlBind standalone >> seems to work fine with --add-modules java.xml.bind - instead it >> appears as if maven-compiler-plugin doesn't preserve argument order, so >> you need to use the joined argument form in your pom.xml: >> >> --add-modules=java.xml.bind >> >> I tried this on your minified example, and seems to work. Thanks! >> >> /Claes >> >> >> On 2016-11-20 22:57, Eirik Bj?rsn?s wrote: >> >>> Hi there! >>> >>> I'm giving Java 9 and Jigsaw a spin on a moderately complex project. >>> (Interestingly, the project is itself a module system, so we do stuff like >>> annotation processing and dynamic reloading of class loader graphs and >>> services) >>> >>> I'm experienced enough with advanced Java to have shot myself in the foot >>> with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundException >>> :-) However, I've only recently been looking into Jigsaw in concrete >>> terms. >>> So please be kind when I expose my ignorance :-) >>> >>> Initially, I just want to see if I can get the project to compile on Java >>> 9. >>> >>> So I'm using --add-modules to javac here and there to add modules not >>> available to the unnamed module by default. (Not making any proper modules >>> yet, that will be the next step). >>> >>> This seems to be working fine, except for one of our annotation >>> processors, >>> which happens to use JAXBContext from java.xml.bind. >>> >>> I added --add-modules to javac (via Maven configuration), but my >>> annotation >>> processor still can't load JAXBContext and fails with this message: >>> >>> $ java -version >>> java version "9-ea" >>> Java(TM) SE Runtime Environment (build 9-ea+144) >>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >>> >>> $ mvn clean install -e >>> >>> This fails with: >>> >>> Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >>> at >>> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >>> essorUsingJavaXmlBind.java:24) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.access$2100(JavacProcessingEnvironment.java:106) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment$Round.run(JavacProcessingEnvironment.java:1182) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.doProcessing(JavacProcessingEnvironment.java:1290) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAn >>> notations(JavaCompiler.java:1260) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile( >>> JavaCompiler.java:939) >>> at >>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call( >>> JavacTaskImpl.java:106) >>> at >>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call( >>> JavacTaskImpl.java:100) >>> at >>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExc >>> eptions(JavacTaskImpl.java:137) >>> ... 28 more >>> >>> I've confirmed that this reproduces using only javac: >>> >>> $ cd example-module >>> >>> $ javac -d target/classes -classpath >>> target/classes:$HOME/.m2/repository/com/example/annotation- >>> processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: >>> -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules >>> java.xml.bind src/main/java/com/example/module/SomeClass.java >>> >>> java.xml? true >>> java.xml.bind? false >>> >>> >>> An annotation processor threw an uncaught exception. >>> Consult the following stack trace for details. >>> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >>> at >>> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >>> essorUsingJavaXmlBind.java:24) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >>> >>> >>> I've reduced this to a minimal-ish test case, available on Github: >>> >>> https://github.com/eirbjo/java-xml-bind-processor >>> >>> Here's the annotation processor: >>> >>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>> r/annotation-processor/src/main/java/com/example/processo >>> r/ProcessorUsingJavaXmlBind.java >>> >>> The class under compilation and the annotation: >>> >>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>> r/example-module/src/main/java/com/example/module/SomeClass.java >>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>> r/example-module/src/main/java/com/example/module/SomeAnnotation.java >>> >>> >>> Any clues? >>> >>> Cheers, >>> Eirik. >>> >>> From eirbjo at gmail.com Sun Nov 20 23:39:33 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 21 Nov 2016 00:39:33 +0100 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: References: <5832225E.8010503@oracle.com> Message-ID: Turns out that: a) Maven treats -J arguments in a special way which hides them from the debug log, but they're still passed on to javac b) Maven parses the javac output for error messages, but drops any output not following the javac output format. So using -J--add-modules=java.xml.bind does actually work! But my question remains: What's the difference between -J--add-modules and --add-modules in javac? I guess --add-modules specifies modules that javac should allow compilation against, while -J--add-modules adds modules which should be visible to javac itself? Eirik. On Sun, Nov 20, 2016 at 11:45 PM, Eirik Bj?rsn?s wrote: > > Claes, > > Btw, the annotation processor has been _compiling_ fine all along. > > The problem happens when the example-module is compiled with the > annotation-processor on the javac -classpath > > Eirik. > > On Sun, Nov 20, 2016 at 11:23 PM, Claes Redestad < > claes.redestad at oracle.com> wrote: > >> Hi Eirik, >> >> compiling com.example.processor.ProcessorUsingJavaXmlBind standalone >> seems to work fine with --add-modules java.xml.bind - instead it >> appears as if maven-compiler-plugin doesn't preserve argument order, so >> you need to use the joined argument form in your pom.xml: >> >> --add-modules=java.xml.bind >> >> I tried this on your minified example, and seems to work. Thanks! >> >> /Claes >> >> >> On 2016-11-20 22:57, Eirik Bj?rsn?s wrote: >> >>> Hi there! >>> >>> I'm giving Java 9 and Jigsaw a spin on a moderately complex project. >>> (Interestingly, the project is itself a module system, so we do stuff >>> like >>> annotation processing and dynamic reloading of class loader graphs and >>> services) >>> >>> I'm experienced enough with advanced Java to have shot myself in the foot >>> with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundExcepti >>> on >>> :-) However, I've only recently been looking into Jigsaw in concrete >>> terms. >>> So please be kind when I expose my ignorance :-) >>> >>> Initially, I just want to see if I can get the project to compile on >>> Java 9. >>> >>> So I'm using --add-modules to javac here and there to add modules not >>> available to the unnamed module by default. (Not making any proper >>> modules >>> yet, that will be the next step). >>> >>> This seems to be working fine, except for one of our annotation >>> processors, >>> which happens to use JAXBContext from java.xml.bind. >>> >>> I added --add-modules to javac (via Maven configuration), but my >>> annotation >>> processor still can't load JAXBContext and fails with this message: >>> >>> $ java -version >>> java version "9-ea" >>> Java(TM) SE Runtime Environment (build 9-ea+144) >>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >>> >>> $ mvn clean install -e >>> >>> This fails with: >>> >>> Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >>> at >>> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >>> essorUsingJavaXmlBind.java:24) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.access$2100(JavacProcessingEnvironment.java:106) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment$Round.run(JavacProcessingEnvironment.java:1182) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.doProcessing(JavacProcessingEnvironment.java:1290) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAn >>> notations(JavaCompiler.java:1260) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(J >>> avaCompiler.java:939) >>> at >>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(Ja >>> vacTaskImpl.java:106) >>> at >>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(Ja >>> vacTaskImpl.java:100) >>> at >>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExc >>> eptions(JavacTaskImpl.java:137) >>> ... 28 more >>> >>> I've confirmed that this reproduces using only javac: >>> >>> $ cd example-module >>> >>> $ javac -d target/classes -classpath >>> target/classes:$HOME/.m2/repository/com/example/annotation-p >>> rocessor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: >>> -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules >>> java.xml.bind src/main/java/com/example/module/SomeClass.java >>> >>> java.xml? true >>> java.xml.bind? false >>> >>> >>> An annotation processor threw an uncaught exception. >>> Consult the following stack trace for details. >>> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >>> at >>> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >>> essorUsingJavaXmlBind.java:24) >>> at >>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >>> >>> >>> I've reduced this to a minimal-ish test case, available on Github: >>> >>> https://github.com/eirbjo/java-xml-bind-processor >>> >>> Here's the annotation processor: >>> >>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>> r/annotation-processor/src/main/java/com/example/processor/ >>> ProcessorUsingJavaXmlBind.java >>> >>> The class under compilation and the annotation: >>> >>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>> r/example-module/src/main/java/com/example/module/SomeClass.java >>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>> r/example-module/src/main/java/com/example/module/SomeAnnotation.java >>> >>> >>> Any clues? >>> >>> Cheers, >>> Eirik. >>> >>> > From eirbjo at gmail.com Mon Nov 21 00:22:30 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 21 Nov 2016 01:22:30 +0100 Subject: Annotation processors and the --processor-module-path Message-ID: Following up on my example, I updated both the annotation processor and the example-module to be proper Java 9 modules with module-info.java. Maven then moved the annotation processor to the --module-path for example-module's compilation. That did not seem to work. The processor wasn't loaded at all. Then I saw that javac also has a --processor-module-path which seemed promising. However, my processor was not loaded at all. First, let us verify that out module is actually a module now: $ java -p ~/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar --list-modules com.example.annotation.processor com.example.annotation.processor (file:///$HOME/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar) requires mandated java.base requires java.compiler requires java.xml.bind conceals com.example.processor Then, compile the example module, now using --processor-module-path: $ javac --processor-module-path ~/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar -sourcepath src/main/java src/main/java/module-info.java src/main/java/com/example/module/SomeClass.java -g -nowarn -target 1.9 -source 9 No output, the annotation-processor was not loaded. Is there some trick needed to load annotation processors as modules? Eirik. From eirbjo at gmail.com Mon Nov 21 00:35:13 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 21 Nov 2016 01:35:13 +0100 Subject: Annotation processors and the --processor-module-path In-Reply-To: References: Message-ID: Assuming Java 9 annotaton processors might need to provide javax.annotation.processing.Processor as a service, I added: provides javax.annotation.processing.Processor with com.example.processor.ProcessorUsingJavaXmlBind to module-info.java. But still, no dice. Eirik. On Mon, Nov 21, 2016 at 1:22 AM, Eirik Bj?rsn?s wrote: > > Following up on my example, I updated both the annotation processor and > the example-module to be proper Java 9 modules with module-info.java. > > Maven then moved the annotation processor to the --module-path for > example-module's compilation. > > That did not seem to work. The processor wasn't loaded at all. > > Then I saw that javac also has a --processor-module-path which seemed > promising. > > However, my processor was not loaded at all. > > First, let us verify that out module is actually a module now: > > $ java -p ~/.m2/repository/com/example/annotation-processor/1.0- > SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar --list-modules > com.example.annotation.processor > com.example.annotation.processor (file:///$HOME/.m2/repository/ > com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0- > SNAPSHOT.jar) > requires mandated java.base > requires java.compiler > requires java.xml.bind > conceals com.example.processor > > Then, compile the example module, now using --processor-module-path: > > $ javac --processor-module-path ~/.m2/repository/com/example/ > annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar > -sourcepath src/main/java src/main/java/module-info.java > src/main/java/com/example/module/SomeClass.java -g -nowarn -target 1.9 > -source 9 > > No output, the annotation-processor was not loaded. > > Is there some trick needed to load annotation processors as modules? > > Eirik. > From jonathan.gibbons at oracle.com Mon Nov 21 07:43:09 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 20 Nov 2016 23:43:09 -0800 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: References: <5832225E.8010503@oracle.com> Message-ID: On 11/20/16 3:39 PM, Eirik Bj?rsn?s wrote: > Turns out that: > > a) Maven treats -J arguments in a special way which hides them from the > debug log, but they're still passed on to javac > b) Maven parses the javac output for error messages, but drops any output > not following the javac output format. > > So using -J--add-modules=java.xml.bind does actually work! > > But my question remains: > > What's the difference between -J--add-modules and --add-modules in javac? > > I guess --add-modules specifies modules that javac should allow compilation > against, while -J--add-modules adds modules which should be visible to > javac itself? That's a pretty good analysis. javac works with two environments: there's the "compilation environment" which contains the elements being compiled, and there's the "runtime environment" which contains the classes for javac itself, and any annotation processors that are loaded and running. > > Eirik. > > On Sun, Nov 20, 2016 at 11:45 PM, Eirik Bj?rsn?s wrote: > >> Claes, >> >> Btw, the annotation processor has been _compiling_ fine all along. >> >> The problem happens when the example-module is compiled with the >> annotation-processor on the javac -classpath >> >> Eirik. >> >> On Sun, Nov 20, 2016 at 11:23 PM, Claes Redestad < >> claes.redestad at oracle.com> wrote: >> >>> Hi Eirik, >>> >>> compiling com.example.processor.ProcessorUsingJavaXmlBind standalone >>> seems to work fine with --add-modules java.xml.bind - instead it >>> appears as if maven-compiler-plugin doesn't preserve argument order, so >>> you need to use the joined argument form in your pom.xml: >>> >>> --add-modules=java.xml.bind >>> >>> I tried this on your minified example, and seems to work. Thanks! >>> >>> /Claes >>> >>> >>> On 2016-11-20 22:57, Eirik Bj?rsn?s wrote: >>> >>>> Hi there! >>>> >>>> I'm giving Java 9 and Jigsaw a spin on a moderately complex project. >>>> (Interestingly, the project is itself a module system, so we do stuff >>>> like >>>> annotation processing and dynamic reloading of class loader graphs and >>>> services) >>>> >>>> I'm experienced enough with advanced Java to have shot myself in the foot >>>> with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundExcepti >>>> on >>>> :-) However, I've only recently been looking into Jigsaw in concrete >>>> terms. >>>> So please be kind when I expose my ignorance :-) >>>> >>>> Initially, I just want to see if I can get the project to compile on >>>> Java 9. >>>> >>>> So I'm using --add-modules to javac here and there to add modules not >>>> available to the unnamed module by default. (Not making any proper >>>> modules >>>> yet, that will be the next step). >>>> >>>> This seems to be working fine, except for one of our annotation >>>> processors, >>>> which happens to use JAXBContext from java.xml.bind. >>>> >>>> I added --add-modules to javac (via Maven configuration), but my >>>> annotation >>>> processor still can't load JAXBContext and fails with this message: >>>> >>>> $ java -version >>>> java version "9-ea" >>>> Java(TM) SE Runtime Environment (build 9-ea+144) >>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >>>> >>>> $ mvn clean install -e >>>> >>>> This fails with: >>>> >>>> Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >>>> at >>>> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >>>> essorUsingJavaXmlBind.java:24) >>>> at >>>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>>> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >>>> at >>>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>>> nvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875) >>>> at >>>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>>> nvironment.access$2100(JavacProcessingEnvironment.java:106) >>>> at >>>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>>> nvironment$Round.run(JavacProcessingEnvironment.java:1182) >>>> at >>>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>>> nvironment.doProcessing(JavacProcessingEnvironment.java:1290) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAn >>>> notations(JavaCompiler.java:1260) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(J >>>> avaCompiler.java:939) >>>> at >>>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(Ja >>>> vacTaskImpl.java:106) >>>> at >>>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(Ja >>>> vacTaskImpl.java:100) >>>> at >>>> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExc >>>> eptions(JavacTaskImpl.java:137) >>>> ... 28 more >>>> >>>> I've confirmed that this reproduces using only javac: >>>> >>>> $ cd example-module >>>> >>>> $ javac -d target/classes -classpath >>>> target/classes:$HOME/.m2/repository/com/example/annotation-p >>>> rocessor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar: >>>> -sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules >>>> java.xml.bind src/main/java/com/example/module/SomeClass.java >>>> >>>> java.xml? true >>>> java.xml.bind? false >>>> >>>> >>>> An annotation processor threw an uncaught exception. >>>> Consult the following stack trace for details. >>>> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext >>>> at >>>> com.example.processor.ProcessorUsingJavaXmlBind.process(Proc >>>> essorUsingJavaXmlBind.java:24) >>>> at >>>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >>>> nvironment.callProcessor(JavacProcessingEnvironment.java:959) >>>> >>>> >>>> I've reduced this to a minimal-ish test case, available on Github: >>>> >>>> https://github.com/eirbjo/java-xml-bind-processor >>>> >>>> Here's the annotation processor: >>>> >>>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>>> r/annotation-processor/src/main/java/com/example/processor/ >>>> ProcessorUsingJavaXmlBind.java >>>> >>>> The class under compilation and the annotation: >>>> >>>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>>> r/example-module/src/main/java/com/example/module/SomeClass.java >>>> https://github.com/eirbjo/java-xml-bind-processor/blob/maste >>>> r/example-module/src/main/java/com/example/module/SomeAnnotation.java >>>> >>>> >>>> Any clues? >>>> >>>> Cheers, >>>> Eirik. >>>> >>>> From Alan.Bateman at oracle.com Mon Nov 21 07:46:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2016 07:46:13 +0000 Subject: javac --add-modules java.xml.bind for annotation processor? In-Reply-To: <1742370432.7773.1479684162641.JavaMail.zimbra@u-pem.fr> References: <5832225E.8010503@oracle.com> <1742370432.7773.1479684162641.JavaMail.zimbra@u-pem.fr> Message-ID: <6f8c464f-1e24-4cdf-3ad5-14c5e5d56009@oracle.com> On 20/11/2016 23:22, Remi Forax wrote: > It seems to me that all the command line options of the VM before jigsaw doesn't use space as a separator, but with the new option like --module-path or --add-modules, you have to put a space after, > so it doesn't work well with the -J option used to take option from tools like javac to feed them to the VM, because the space in the middle of the VM option is interpreted as a space between the options of the tool. > JEP 293 [1] documents the guidelines on this. It documents that the long form can use space or `=` to separate the option name and value. It further documents that the HotSpot VM will only accept a subset of these rules, hence we have to use `=` as the separator when using the JNI innovation interface, VM options files, or _JAVA_OPTIONS. When only using the java launcher then you need to care too much about this because it will accept space as a separator. -Alan [1] http://openjdk.java.net/jeps/293 From Alan.Bateman at oracle.com Mon Nov 21 08:22:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2016 08:22:39 +0000 Subject: Annotation processors and the --processor-module-path In-Reply-To: References: Message-ID: On 21/11/2016 00:22, Eirik Bj?rsn?s wrote: > : > > $ javac --processor-module-path > ~/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar > -sourcepath src/main/java src/main/java/module-info.java > src/main/java/com/example/module/SomeClass.java -g -nowarn -target 1.9 > -source 9 > > No output, the annotation-processor was not loaded. > > Is there some trick needed to load annotation processors as modules? > I assume you also need to specify -processor so that javac knows which annotation processors to run. -Alan. From eirbjo at gmail.com Mon Nov 21 09:46:47 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 21 Nov 2016 10:46:47 +0100 Subject: Annotation processors and the --processor-module-path In-Reply-To: References: Message-ID: Alan, | $ javac --help | -processor [,,...] | Names of the annotation processors to run; bypasses default discovery process Why does the "default discovery process" work with --classpath, but not with --processor-module-path? Is it simply an omission, or is this by design? With the current discovery process (ServiceLoader?), the number of processors and their class names are implementation details that the processor author is free to change. Do we really want to require users to have to deal with and keep track of the internal workings of their processors? Seems like a regression to me.. Cheers, Eirik. On Mon, Nov 21, 2016 at 9:22 AM, Alan Bateman wrote: > On 21/11/2016 00:22, Eirik Bj?rsn?s wrote: > > : >> >> $ javac --processor-module-path >> ~/.m2/repository/com/example/annotation-processor/1.0-SNAPSH >> OT/annotation-processor-1.0-SNAPSHOT.jar >> -sourcepath src/main/java src/main/java/module-info.java >> src/main/java/com/example/module/SomeClass.java -g -nowarn -target 1.9 >> -source 9 >> >> No output, the annotation-processor was not loaded. >> >> Is there some trick needed to load annotation processors as modules? >> >> I assume you also need to specify -processor so that javac knows which > annotation processors to run. > > -Alan. > From Alan.Bateman at oracle.com Mon Nov 21 10:03:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2016 10:03:44 +0000 Subject: Annotation processors and the --processor-module-path In-Reply-To: References: Message-ID: <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com> On 21/11/2016 09:46, Eirik Bj?rsn?s wrote: > Alan, > > | $ javac --help > | -processor [,,...] > | Names of the annotation processors to run; bypasses default > discovery process > > Why does the "default discovery process" work with --classpath, but not > with --processor-module-path? > > Is it simply an omission, or is this by design? > If you have `provides javax.annotation.processing.Processor with ...` in your module declaration then it should find it. I just checked this locally and it works as expected. One of your mails said this wasn't working for you, not immediately obvious why from the mails. So if you aren't using `provides` then my understanding is that the processor needs to be specified via -processor but I don't think there is support there for allowing -processor to specify the processor module, hence not clear how it could be resolved. -Alan From jan.lahoda at oracle.com Mon Nov 21 10:17:14 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 21 Nov 2016 11:17:14 +0100 Subject: Annotation processors and the --processor-module-path In-Reply-To: <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com> References: <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com> Message-ID: <5832C9AA.8010901@oracle.com> On 21.11.2016 11:03, Alan Bateman wrote: > On 21/11/2016 09:46, Eirik Bj?rsn?s wrote: > >> Alan, >> >> | $ javac --help >> | -processor [,,...] >> | Names of the annotation processors to run; bypasses default >> discovery process >> >> Why does the "default discovery process" work with --classpath, but not >> with --processor-module-path? >> >> Is it simply an omission, or is this by design? >> > If you have `provides javax.annotation.processing.Processor with ...` in > your module declaration then it should find it. I just checked this > locally and it works as expected. One of your mails said this wasn't > working for you, not immediately obvious why from the mails. So if you > aren't using `provides` then my understanding is that the processor > needs to be specified via -processor but I don't think there is support > there for allowing -processor to specify the processor module, hence not > clear how it could be resolved. Currently, AFAIK, the processors on module path need to be registered in the ServiceLoader. For --processor-module-path, "-processor" can be used to select processors out of those registered in the ServiceLoader. If --processor-module-path is used and there is no "-processor", all processors registered in ServiceLoader are considered, AFAIK. Please note that (as before) the processors are only run if their SupportedAnnotationTypes match, etc. I tried a simple example as well, and with the proper "provides" the annotation processor was run. Is there a testcase we could try? Jan > > -Alan From eirbjo at gmail.com Mon Nov 21 10:39:58 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 21 Nov 2016 11:39:58 +0100 Subject: Annotation processors and the --processor-module-path In-Reply-To: <5832C9AA.8010901@oracle.com> References: <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com> <5832C9AA.8010901@oracle.com> Message-ID: > Currently, AFAIK, the processors on module path need to be registered in > the ServiceLoader. For --processor-module-path, "-processor" can be used to > select processors out of those registered in the ServiceLoader. If > --processor-module-path is used and there is no "-processor", all > processors registered in ServiceLoader are considered, AFAIK. Please note > that (as before) the processors are only run if their > SupportedAnnotationTypes match, etc. > > I tried a simple example as well, and with the proper "provides" the > annotation processor was run. Is there a testcase we could try? > Jan, I've updated the testcase on Github: https://github.com/eirbjo/java-xml-bind-processor How to reproduce: $ mvn clean install $ cd example-module Now (since Maven doesn't know about --processor-module-path): $ javac -d target/classes --processor-module-path ~/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar -sourcepath src/main/java src/main/java/com/example/module/SomeClass.java No output - the processor is not applied. However: $ javac -d target/classes -classpath ~/.m2/repository/com/example/annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar -sourcepath src/main/java src/main/java/com/example/module/SomeClass.java Running ProcessorUsingJavaXmlBind.process java.xml? true java.xml.bind? false The processor was now applied. Note that the test case now has provides in module-info.java _and_ the ServiceLoader file in META-INF/services. I tried removing the services file, no change. Eirik. From sundararajan.athijegannathan at oracle.com Mon Nov 21 14:14:38 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 21 Nov 2016 19:44:38 +0530 Subject: RFR 8170099: Nashorn test failures with stricter reflection access checks in jake forest Message-ID: <5833014E.50502@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8170099/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8170099 Thanks, -Sundar From james.laskey at oracle.com Mon Nov 21 14:10:42 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 21 Nov 2016 10:10:42 -0400 Subject: RFR 8170099: Nashorn test failures with stricter reflection access checks in jake forest In-Reply-To: <5833014E.50502@oracle.com> References: <5833014E.50502@oracle.com> Message-ID: <7F5C3FAA-C3E9-4D7B-B29F-EA5A460A2FE6@oracle.com> +1 > On Nov 21, 2016, at 10:14 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8170099/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8170099 > > Thanks, > -Sundar From Alan.Bateman at oracle.com Mon Nov 21 14:13:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2016 14:13:39 +0000 Subject: RFR 8170099: Nashorn test failures with stricter reflection access checks in jake forest In-Reply-To: <5833014E.50502@oracle.com> References: <5833014E.50502@oracle.com> Message-ID: On 21/11/2016 14:14, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8170099/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8170099 This looks okay although you could replace the setAccessible methods in Reflector that take Method and Constructor with one that takes an Executable. -Alan From org.openjdk at io7m.com Mon Nov 21 14:19:49 2016 From: org.openjdk at io7m.com (org.openjdk at io7m.com) Date: Mon, 21 Nov 2016 14:19:49 +0000 Subject: onejars under Jigsaw In-Reply-To: References: <20161118214013.4a6404d4@copperhead.int.arc7.info> Message-ID: <20161121141949.6a678214@copperhead.int.arc7.info> On 2016-11-19T22:53:17 +0100 "Robert Scholte" wrote: > Hi, > > The following topics have been created for this issue: > http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs > http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs > > Once resolved we should improve the maven-shade-plugin according the new > specifications. > 'Ello. I'm glad to know this is under consideration. Is there anything in particular that needs to happen to resolve this? M From alan.bateman at oracle.com Mon Nov 21 14:54:49 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 21 Nov 2016 14:54:49 +0000 Subject: hg: jigsaw/jake/langtools: Rename Hashes attribute to jdk.Hashes as it is JDK-specific Message-ID: <201611211454.uALEsnXS019499@aojmv0008.oracle.com> Changeset: 52a360826e26 Author: alanb Date: 2016-11-21 14:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/52a360826e26 Rename Hashes attribute to jdk.Hashes as it is JDK-specific ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java From alan.bateman at oracle.com Mon Nov 21 14:55:15 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 21 Nov 2016 14:55:15 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611211455.uALEtFfQ019618@aojmv0008.oracle.com> Changeset: c67449fbf341 Author: alanb Date: 2016-11-21 14:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c67449fbf341 Rename Hashes attribute to jdk.Hashes as it is JDK-specific ! 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/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java Changeset: 66e466a557d8 Author: alanb Date: 2016-11-21 14:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/66e466a557d8 Layer.Controller and privateLookupIn ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java + test/java/lang/invoke/MethodHandles/privateLookupIn/Driver.java + test/java/lang/invoke/MethodHandles/privateLookupIn/m1/module-info.java + test/java/lang/invoke/MethodHandles/privateLookupIn/m1/p1/Type.java + test/java/lang/invoke/MethodHandles/privateLookupIn/m2/module-info.java + test/java/lang/invoke/MethodHandles/privateLookupIn/m2/p2/Type.java + test/java/lang/invoke/MethodHandles/privateLookupIn/m3/module-info.java + test/java/lang/invoke/MethodHandles/privateLookupIn/m3/p3/Type.java + test/java/lang/invoke/MethodHandles/privateLookupIn/test/module-info.java + test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java + test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/internal/NonPublicType.java + test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/internal/PublicType.java + test/java/lang/reflect/Layer/LayerControllerTest.java ! test/java/lang/reflect/Module/BasicModuleTest.java ! test/java/lang/reflect/Module/access/src/test/test/Main.java ! test/java/util/ServiceLoader/modules/Basic.java From sundararajan.athijegannathan at oracle.com Mon Nov 21 15:06:47 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 21 Nov 2016 20:36:47 +0530 Subject: RFR 8170099: Nashorn test failures with stricter reflection access checks in jake forest In-Reply-To: References: <5833014E.50502@oracle.com> Message-ID: <58330D87.70005@oracle.com> Thanks for the review. Fixing Reflection with your suggesting and pushing it. Updated webrev for the record: http://cr.openjdk.java.net/~sundar/8170099/webrev.01/ -Sundar On 21/11/16, 7:43 PM, Alan Bateman wrote: > > > On 21/11/2016 14:14, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8170099/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8170099 > This looks okay although you could replace the setAccessible methods > in Reflector that take Method and Constructor with one that takes an > Executable. > > -Alan From sundararajan.athijegannathan at oracle.com Mon Nov 21 14:58:53 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 21 Nov 2016 14:58:53 +0000 Subject: hg: jigsaw/jake/nashorn: 8170099: Nashorn test failures with stricter reflection access checks in jake forest Message-ID: <201611211458.uALEwrxK021901@aojmv0008.oracle.com> Changeset: 3d66147560bb Author: sundar Date: 2016-11-21 20:37 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3d66147560bb 8170099: Nashorn test failures with stricter reflection access checks in jake forest Reviewed-by: jlaskey, alanb ! make/project.properties ! test/script/nosecurity/JDK-8044798.js ! test/src/jdk/nashorn/test/models/Reflector.java From mandy.chung at oracle.com Mon Nov 21 19:08:39 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 21 Nov 2016 19:08:39 +0000 Subject: hg: jigsaw/jake/hotspot: Remove --add-exports-private option Message-ID: <201611211908.uALJ8da2015103@aojmv0008.oracle.com> Changeset: 8f2d918e0619 Author: mchung Date: 2016-11-21 11:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8f2d918e0619 Remove --add-exports-private option ! src/share/vm/runtime/arguments.cpp From mandy.chung at oracle.com Mon Nov 21 19:08:45 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 21 Nov 2016 19:08:45 +0000 Subject: hg: jigsaw/jake/jaxp: Fix test that uses deep reflection Message-ID: <201611211908.uALJ8j3G015169@aojmv0008.oracle.com> Changeset: 23e94a1d726d Author: mchung Date: 2016-11-21 11:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/23e94a1d726d Fix test that uses deep reflection ! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java From mandy.chung at oracle.com Mon Nov 21 19:08:52 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 21 Nov 2016 19:08:52 +0000 Subject: hg: jigsaw/jake/jdk: 5 new changesets Message-ID: <201611211908.uALJ8qrn015326@aojmv0008.oracle.com> Changeset: 375b859caf2e Author: mchung Date: 2016-11-21 11:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/375b859caf2e Clean up jlink/jmod code ! 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/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 Changeset: ca42c7a61b1a Author: mchung Date: 2016-11-21 11:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ca42c7a61b1a Improve GenModuleInfoSource tool for error checking ! make/src/classes/build/tools/module/GenModuleInfoSource.java + make/src/classes/build/tools/module/ModuleInfoExtraTest.java Changeset: e573196ec0e3 Author: mchung Date: 2016-11-21 11:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e573196ec0e3 Remove --add-exports-private option ! src/java.base/share/native/libjli/java.c Changeset: a693d3504846 Author: mchung Date: 2016-11-21 11:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a693d3504846 migrate to requires transitive ! src/jdk.desktop/share/classes/module-info.java Changeset: 304a11f652b2 Author: mchung Date: 2016-11-21 11:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/304a11f652b2 merge provides a service type with multiple impl classes ! src/java.desktop/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jvmstat/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java From eirbjo at gmail.com Tue Nov 22 10:33:15 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 22 Nov 2016 11:33:15 +0100 Subject: Annotation processors and the --processor-module-path In-Reply-To: References: <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com> <5832C9AA.8010901@oracle.com> Message-ID: Found it! With --processor-module-path, JavacProcessingEnvironment.java:257 throws an exception when calling fileManager.getServiceLoader(ANNOTATION_PROCESSOR_MODULE_PATH, Processor.class) There's a catch for this exception at JavaCompiler, line 982: catch (Abort ex) { if (devVerbose) ex.printStackTrace(System.err); } Since devVerbose is false, this exception is effectively swallowed. The exception is an ResolutionException: Module java.xml.bind not found, required by com.example.annotation.processor So again, I added -J-add-modules=java.xml.bind, and now my annotation processor is loading. Given that my annotation processor does require java.xml.bind and I'm using --processor-module-path, my expectation would be that javac would resolve that requires for me. What gives, am I expecting too much? Bonus question: What is devVerbose, and how can I enable it? Eirik. On Mon, Nov 21, 2016 at 11:39 AM, Eirik Bj?rsn?s wrote: > > Currently, AFAIK, the processors on module path need to be registered in >> the ServiceLoader. For --processor-module-path, "-processor" can be used to >> select processors out of those registered in the ServiceLoader. If >> --processor-module-path is used and there is no "-processor", all >> processors registered in ServiceLoader are considered, AFAIK. Please note >> that (as before) the processors are only run if their >> SupportedAnnotationTypes match, etc. >> >> I tried a simple example as well, and with the proper "provides" the >> annotation processor was run. Is there a testcase we could try? >> > > > Jan, > > I've updated the testcase on Github: > > https://github.com/eirbjo/java-xml-bind-processor > > How to reproduce: > > $ mvn clean install > $ cd example-module > > Now (since Maven doesn't know about --processor-module-path): > > $ javac -d target/classes --processor-module-path > ~/.m2/repository/com/example/annotation-processor/1.0- > SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar -sourcepath src/main/java > src/main/java/com/example/module/SomeClass.java > > No output - the processor is not applied. > > However: > > $ javac -d target/classes -classpath ~/.m2/repository/com/example/ > annotation-processor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar > -sourcepath src/main/java src/main/java/com/example/module/SomeClass.java > Running ProcessorUsingJavaXmlBind.process > java.xml? true > java.xml.bind? false > > > The processor was now applied. > > Note that the test case now has provides in module-info.java _and_ the > ServiceLoader file in META-INF/services. I tried removing the services > file, no change. > > Eirik. > > > From denis.kononenko at oracle.com Tue Nov 22 12:51:07 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Tue, 22 Nov 2016 04:51:07 -0800 (PST) Subject: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures Message-ID: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> Hi, Could someone please review this small fix. Recently several failing test cases were delivered into jdk9-dev by my mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed these test cases to temporarily avoid their execution. They should be renamed back when appropriate fixes for 4 product bugs are delivered. Also I've fixed testcase JImageVerifyTest.testVerifyNotExistingImage, it contained a regrettable error and duplicated another test case (testVerifyImageNotSpecified). BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170120 WEBREV: http://cr.openjdk.java.net/~dkononenko/8170120/webrev.00 Now the tests have 100% pass rate. JImageListTest: Invoking testList jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListHelp jimage [list, -h] jimage [list, --help] Invoking testListVerbose jimage [list, --verbose, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeAllWithGlob jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, **, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeWithGlob jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, /java.base/java/util/zip/**, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeNoMatchWithGlob jimage [list, --include, not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeAllWithExplicitGlob jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, glob:**, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeAllWithRegex jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, regex:.*, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeWithRegex jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, regex:/java.base/java/text/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeNoMatchWithRegex jimage [list, --include, regex:not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeMultiplePatterns jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, glob:/java.base/java/time/**,regex:/java.base/java/util/zip/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListNotExistingImage jimage [list, ./not_existing_image] Invoking testListWithUnknownOption jimage [list, --unknown] STDERR: STATUS:Passed. JImageExtractTest: Invoking testExtract jimage [extract, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractHelp jimage [extract, --help] jimage [extract, --help] Invoking testExtractToDir jimage [extract, --dir, ./JImageExtractTest3092688479608335903, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractNotExistingImage jimage [extract, ./not_existing_image] Invoking testExtractToUnspecifiedDir jimage [extract, --dir, --, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractToNotExistingDir jimage [extract, --dir, ./JImageExtractTest9794403129293432977, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractFromDir jimage [extract, home/dnk/projects/oracle/jdk-9/lib] Invoking testExtractToDirBySymlink jimage [extract, --dir, ./symlink, /home/dnk/projects/oracle/jdk-9/lib/modules] STDERR: STATUS:Passed. JImageVerifyTest: Invoking testVerify jimage [verify, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testVerifyHelp jimage [verify, -h] jimage [verify, --help] Invoking testVerifyNotExistingImage jimage [verify, ./not_existing_image] Invoking testVerifyWithUnknownOption jimage [verify, --unknown] STDERR: STATUS:Passed. Also I need a sponsor to push the change into jdk9-dev. Thank you, Denis. From Alan.Bateman at oracle.com Tue Nov 22 13:57:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Nov 2016 13:57:31 +0000 Subject: Annotation processors and the --processor-module-path In-Reply-To: References: <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com> <5832C9AA.8010901@oracle.com> Message-ID: <555b0d80-82b7-a23d-f865-594bf52a372c@oracle.com> On 22/11/2016 10:33, Eirik Bj?rsn?s wrote: > : > > So again, I added -J-add-modules=java.xml.bind, and now my annotation > processor is loading. > > Given that my annotation processor does require java.xml.bind and I'm using > --processor-module-path, my expectation would be that javac would resolve > that requires for me. > > What gives, am I expecting too much? When you deploy annotation processors on the --processor-module-path then javac needs to resolve the annotation processor modules as part of creating the dynamic configuration. The issue with the dependency on java.xml.bind is that it's not in the boot layer and it's also not observable on the processor module path. There is no support at this time for augmenting the boot layer once it is created, also javac does not attempt to resolve these modules from the original module path and system image that were used to start the VM. So for now at least, running with -J--add-modules=java.xml.bind is the only way to get this to work. -Alan From jan.lahoda at oracle.com Tue Nov 22 14:36:48 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 22 Nov 2016 14:36:48 +0000 Subject: hg: jigsaw/jake/langtools: --add-exports-private changed to --add-opens. Message-ID: <201611221436.uAMEan99020268@aojmv0008.oracle.com> Changeset: 117386f5ab3e Author: jlahoda Date: 2016-11-22 15:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/117386f5ab3e --add-exports-private changed to --add-opens. ! test/tools/javac/platform/PlatformProviderTest.java From andrey.x.nazarov at oracle.com Tue Nov 22 16:29:16 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 22 Nov 2016 19:29:16 +0300 Subject: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures In-Reply-To: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> References: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> Message-ID: Hi, Looks OK to me. ?Andrey > On 22 Nov 2016, at 15:51, Denis Kononenko wrote: > > > Hi, > > Could someone please review this small fix. > > Recently several failing test cases were delivered into jdk9-dev by my mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed these test cases to temporarily avoid their execution. They should be renamed back when appropriate fixes for 4 product bugs are delivered. > Also I've fixed testcase JImageVerifyTest.testVerifyNotExistingImage, it contained a regrettable error and duplicated another test case (testVerifyImageNotSpecified). > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170120 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8170120/webrev.00 > > > Now the tests have 100% pass rate. > > JImageListTest: > > Invoking testList > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListHelp > jimage [list, -h] > jimage [list, --help] > Invoking testListVerbose > jimage [list, --verbose, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, **, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, /java.base/java/util/zip/**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithGlob > jimage [list, --include, not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithExplicitGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:/java.base/java/text/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithRegex > jimage [list, --include, regex:not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeMultiplePatterns > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:/java.base/java/time/**,regex:/java.base/java/util/zip/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListNotExistingImage > jimage [list, ./not_existing_image] > Invoking testListWithUnknownOption > jimage [list, --unknown] > STDERR: > STATUS:Passed. > > > JImageExtractTest: > > Invoking testExtract > jimage [extract, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractHelp > jimage [extract, --help] > jimage [extract, --help] > Invoking testExtractToDir > jimage [extract, --dir, ./JImageExtractTest3092688479608335903, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractNotExistingImage > jimage [extract, ./not_existing_image] > Invoking testExtractToUnspecifiedDir > jimage [extract, --dir, --, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractToNotExistingDir > jimage [extract, --dir, ./JImageExtractTest9794403129293432977, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractFromDir > jimage [extract, home/dnk/projects/oracle/jdk-9/lib] > Invoking testExtractToDirBySymlink > jimage [extract, --dir, ./symlink, /home/dnk/projects/oracle/jdk-9/lib/modules] > STDERR: > STATUS:Passed. > > > JImageVerifyTest: > > Invoking testVerify > jimage [verify, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testVerifyHelp > jimage [verify, -h] > jimage [verify, --help] > Invoking testVerifyNotExistingImage > jimage [verify, ./not_existing_image] > Invoking testVerifyWithUnknownOption > jimage [verify, --unknown] > STDERR: > STATUS:Passed. > > Also I need a sponsor to push the change into jdk9-dev. > > Thank you, > Denis. > > From alan.bateman at oracle.com Tue Nov 22 16:45:49 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Nov 2016 16:45:49 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201611221645.uAMGjnDf000140@aojmv0008.oracle.com> Changeset: 755476f7207d Author: alanb Date: 2016-11-22 13:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/755476f7207d @throws SecurityManager instead of SecurityException ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: f5010fea98b1 Author: alanb Date: 2016-11-22 14:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f5010fea98b1 extraProvides needs to be List to align with updated Provides ! 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: 4fed951f548c Author: alanb Date: 2016-11-22 14:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4fed951f548c Update javadoc for ordering of multiple providers in module ! src/java.base/share/classes/java/util/ServiceLoader.java Changeset: 497d75ea3196 Author: alanb Date: 2016-11-22 16:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/497d75ea3196 requires/exports to should be in internal form ! 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/jdk/internal/module/ModuleInfoWriter.java From james.laskey at oracle.com Tue Nov 22 16:49:58 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 22 Nov 2016 12:49:58 -0400 Subject: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures In-Reply-To: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> References: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> Message-ID: <9940A44B-7FA3-4260-BA60-0F9B9837811E@oracle.com> +1 > On Nov 22, 2016, at 8:51 AM, Denis Kononenko wrote: > > > Hi, > > Could someone please review this small fix. > > Recently several failing test cases were delivered into jdk9-dev by my mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed these test cases to temporarily avoid their execution. They should be renamed back when appropriate fixes for 4 product bugs are delivered. > Also I've fixed testcase JImageVerifyTest.testVerifyNotExistingImage, it contained a regrettable error and duplicated another test case (testVerifyImageNotSpecified). > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170120 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8170120/webrev.00 > > > Now the tests have 100% pass rate. > > JImageListTest: > > Invoking testList > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListHelp > jimage [list, -h] > jimage [list, --help] > Invoking testListVerbose > jimage [list, --verbose, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, **, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, /java.base/java/util/zip/**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithGlob > jimage [list, --include, not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithExplicitGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:/java.base/java/text/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithRegex > jimage [list, --include, regex:not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeMultiplePatterns > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:/java.base/java/time/**,regex:/java.base/java/util/zip/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListNotExistingImage > jimage [list, ./not_existing_image] > Invoking testListWithUnknownOption > jimage [list, --unknown] > STDERR: > STATUS:Passed. > > > JImageExtractTest: > > Invoking testExtract > jimage [extract, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractHelp > jimage [extract, --help] > jimage [extract, --help] > Invoking testExtractToDir > jimage [extract, --dir, ./JImageExtractTest3092688479608335903, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractNotExistingImage > jimage [extract, ./not_existing_image] > Invoking testExtractToUnspecifiedDir > jimage [extract, --dir, --, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractToNotExistingDir > jimage [extract, --dir, ./JImageExtractTest9794403129293432977, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractFromDir > jimage [extract, home/dnk/projects/oracle/jdk-9/lib] > Invoking testExtractToDirBySymlink > jimage [extract, --dir, ./symlink, /home/dnk/projects/oracle/jdk-9/lib/modules] > STDERR: > STATUS:Passed. > > > JImageVerifyTest: > > Invoking testVerify > jimage [verify, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testVerifyHelp > jimage [verify, -h] > jimage [verify, --help] > Invoking testVerifyNotExistingImage > jimage [verify, ./not_existing_image] > Invoking testVerifyWithUnknownOption > jimage [verify, --unknown] > STDERR: > STATUS:Passed. > > Also I need a sponsor to push the change into jdk9-dev. > > Thank you, > Denis. > > From alan.bateman at oracle.com Tue Nov 22 17:53:30 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Nov 2016 17:53:30 +0000 Subject: hg: jigsaw/jake/hotspot: Missing since= in new JVMTI functions Message-ID: <201611221753.uAMHrULg021070@aojmv0008.oracle.com> Changeset: 4e2ce42c5ef8 Author: alanb Date: 2016-11-22 17:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4e2ce42c5ef8 Missing since= in new JVMTI functions ! src/share/vm/prims/jvmti.xml From alan.bateman at oracle.com Tue Nov 22 20:51:05 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Nov 2016 20:51:05 +0000 Subject: hg: jigsaw/jake/jdk: Residual references to exports-private in tests Message-ID: <201611222051.uAMKp6bG013686@aojmv0008.oracle.com> Changeset: 73203c93bde8 Author: alanb Date: 2016-11-22 20:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/73203c93bde8 Residual references to exports-private in tests ! test/java/awt/patchlib/java.desktop/java/awt/Helper.java ! test/java/lang/instrument/RedefineModuleAgent.java From mandy.chung at oracle.com Tue Nov 22 21:07:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Nov 2016 13:07:03 -0800 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory Message-ID: This patch moves src.zip and jrt-fs.jar from the top-level into the `lib` directory in the run-time image as we proposed [1]. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ thanks Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html From mandy.chung at oracle.com Tue Nov 22 21:23:22 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 22 Nov 2016 21:23:22 +0000 Subject: hg: jigsaw/jake/jdk: Minor typo in com.sun.jdi.ModuleReference class spec Message-ID: <201611222123.uAMLNM7R023586@aojmv0008.oracle.com> Changeset: ea07cfe18be3 Author: mchung Date: 2016-11-22 13:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ea07cfe18be3 Minor typo in com.sun.jdi.ModuleReference class spec ! src/jdk.jdi/share/classes/com/sun/jdi/ModuleReference.java From james.laskey at oracle.com Tue Nov 22 23:31:38 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 22 Nov 2016 19:31:38 -0400 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: References: Message-ID: <1D6891E9-2D66-4972-8F45-3FB5C881F20A@oracle.com> +1 > On Nov 22, 2016, at 5:07 PM, Mandy Chung wrote: > > This patch moves src.zip and jrt-fs.jar from the top-level into > the `lib` directory in the run-time image as we proposed [1]. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ > > thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html From mandy.chung at oracle.com Wed Nov 23 00:26:18 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 23 Nov 2016 00:26:18 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611230026.uAN0QINP016385@aojmv0008.oracle.com> Changeset: 58f07216d2e7 Author: mchung Date: 2016-11-22 15:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/58f07216d2e7 Fix test to check ACC_MODULE before getting this_class name ! test/jdk/internal/reflect/CallerSensitive/CallerSensitiveFinder.java Changeset: 8aecfe7850e9 Author: alanb Date: 2016-11-22 15:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8aecfe7850e9 Revise Module attribute per #ClassFileModuleName ! 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/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java From mandy.chung at oracle.com Wed Nov 23 00:26:23 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 23 Nov 2016 00:26:23 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201611230026.uAN0QNu4016521@aojmv0008.oracle.com> Changeset: 0ade799cfe9d Author: mchung Date: 2016-11-22 15:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0ade799cfe9d Check ACC_MODULE before getting this_class name ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java Changeset: ec19be6d1e19 Author: jjg Date: 2016-11-22 15:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ec19be6d1e19 Revise Module attribute per #ClassFileModuleName ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.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/jvm/ModuleNameReader.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/javap/4870651/T4870651.java ! test/tools/javap/MethodParameters.java ! test/tools/javap/T4975569.java From mandy.chung at oracle.com Wed Nov 23 00:38:07 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 23 Nov 2016 00:38:07 +0000 Subject: hg: jigsaw/jake/jdk: Fix FieldSetAccessibleTest test to work with setAccessible Message-ID: <201611230038.uAN0c7Ig019974@aojmv0008.oracle.com> Changeset: 6a19edab7f47 Author: mchung Date: 2016-11-22 16:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6a19edab7f47 Fix FieldSetAccessibleTest test to work with setAccessible ! test/ProblemList.txt ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java From jonathan.gibbons at oracle.com Wed Nov 23 01:50:19 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Nov 2016 01:50:19 +0000 Subject: hg: jigsaw/jake/langtools: fix 2 failing tests after Module attribute changes Message-ID: <201611230150.uAN1oJEI010574@aojmv0008.oracle.com> Changeset: ecda27ca1011 Author: jjg Date: 2016-11-22 17:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ecda27ca1011 fix 2 failing tests after Module attribute changes ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java ! test/tools/javac/modules/OpenModulesTest.java From jonathan.gibbons at oracle.com Wed Nov 23 02:19:08 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Nov 2016 02:19:08 +0000 Subject: hg: jigsaw/jake/langtools: remove support for old-style Module attribute Message-ID: <201611230219.uAN2J84t022083@aojmv0008.oracle.com> Changeset: ea87091ceefc Author: jjg Date: 2016-11-22 18:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ea87091ceefc remove support for old-style Module attribute ! 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 ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java From jonathan.gibbons at oracle.com Wed Nov 23 02:42:54 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Nov 2016 02:42:54 +0000 Subject: hg: jigsaw/jake/langtools: Add classfile Module_attribute.OPensEntry Message-ID: <201611230242.uAN2gsav029282@aojmv0008.oracle.com> Changeset: 51f0bf95d616 Author: jjg Date: 2016-11-22 18:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/51f0bf95d616 Add classfile Module_attribute.OPensEntry ! 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 From chris.hegarty at oracle.com Wed Nov 23 09:56:07 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Nov 2016 09:56:07 +0000 Subject: hg: jigsaw/jake/jdk: Replace exported-private with open Message-ID: <201611230956.uAN9u7dg027493@aojmv0008.oracle.com> Changeset: 3750898360d0 Author: chegar Date: 2016-11-23 09:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3750898360d0 Replace exported-private with open ! src/java.base/share/classes/java/lang/Class.java From erik.joelsson at oracle.com Wed Nov 23 10:14:42 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 11:14:42 +0100 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: References: Message-ID: <49ae59ea-53f8-0e48-90bd-782ca20d3422@oracle.com> Build changes look good. /Erik On 2016-11-22 22:07, Mandy Chung wrote: > This patch moves src.zip and jrt-fs.jar from the top-level into > the `lib` directory in the run-time image as we proposed [1]. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ > > thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html From Alan.Bateman at oracle.com Wed Nov 23 11:55:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2016 11:55:11 +0000 Subject: Moving the changes in jake to jdk9/dev Message-ID: We've been accumulating changes in the jake forest that are tied to JSR issues for the last few months. Some of the changes (such as #ClassLoaderNames) have already been pushed upstream to jdk9/dev but we've still sitting on a large patch. We would like to move the changes that we have in jake to jdk9/dev soon, early December if possible. One motivation is to get the changes and new APIs into JDK 9 main line so that they can be used and tested more widely. This should help reduce some of the confusion with having two builds too. Another motivation is that the merging is getting painful, esp. the langtools repository where we have regular conflicts with changes to javac pushed via jdk9/dev. To that end, I will start a code review soon that will be a snapshot of the changes in the jake forest. Once these changes are reviewed and in jdk9/dev then we will continue in the jake forest where appropriate - particularly in areas that are tied to JSR issues where we need to iterate and prototype, also in areas where we need to re-work some areas of the implementation. As people on this mailing list know, jake has the changes for #AwkwardStrongEncapsulation [1] where setAccessible has been changed so it can't be used to break into non-public members/types in exported packages of JDK modules. It was changed more than a year ago to fail when attempting to use it to break into non-exported packages. Dialing it up further is a disruptive change that will expose a lot of hacks and issues with existing code that is used to accessing non-public fields/methods in JDK classes. It will take some libraries and tools a bit of time to digest this change, even with the --add-opens command line option and Add-Opens manifest in application JAR files to keep existing code going. I plan to send mail to jdk9-dev in advance of this integration to create wider awareness of this change. -Alan [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation From alan.bateman at oracle.com Wed Nov 23 13:32:52 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 Nov 2016 13:32:52 +0000 Subject: hg: jigsaw/jake/langtools: Rename new attributes to ModuleXXX Message-ID: <201611231332.uANDWqPl003968@aojmv0008.oracle.com> Changeset: f3be37a11045 Author: alanb Date: 2016-11-23 13:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f3be37a11045 Rename new attributes to ModuleXXX ! 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/Hashes_attribute.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/MainClass_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleHashes_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleMainClass_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModulePackages_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleTarget_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleVersion_attribute.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/Packages_attribute.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/TargetPlatform_attribute.java - src/jdk.jdeps/share/classes/com/sun/tools/classfile/Version_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 From alan.bateman at oracle.com Wed Nov 23 13:33:10 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 Nov 2016 13:33:10 +0000 Subject: hg: jigsaw/jake/jdk: Rename new attributes to ModuleXXX Message-ID: <201611231333.uANDXApj004080@aojmv0008.oracle.com> Changeset: 6c9428da24a4 Author: alanb Date: 2016-11-23 13:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c9428da24a4 Rename new attributes to ModuleXXX ! 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/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 ! test/java/lang/reflect/Module/AnnotationsTest.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From forax at univ-mlv.fr Wed Nov 23 13:36:22 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 23 Nov 2016 14:36:22 +0100 (CET) Subject: Moving the changes in jake to jdk9/dev In-Reply-To: References: Message-ID: <1079693153.1498149.1479908182169.JavaMail.zimbra@u-pem.fr> Hi Alan, With my ASM hat, we've planned to make a new beta of ASM as soon as the module class file format patches are merged into jdk9 :) R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "jigsaw-dev" > Envoy?: Mercredi 23 Novembre 2016 12:55:11 > Objet: Moving the changes in jake to jdk9/dev > We've been accumulating changes in the jake forest that are tied to JSR > issues for the last few months. Some of the changes (such as > #ClassLoaderNames) have already been pushed upstream to jdk9/dev but > we've still sitting on a large patch. > > We would like to move the changes that we have in jake to jdk9/dev soon, > early December if possible. One motivation is to get the changes and new > APIs into JDK 9 main line so that they can be used and tested more > widely. This should help reduce some of the confusion with having two > builds too. Another motivation is that the merging is getting painful, > esp. the langtools repository where we have regular conflicts with > changes to javac pushed via jdk9/dev. > > To that end, I will start a code review soon that will be a snapshot of > the changes in the jake forest. Once these changes are reviewed and in > jdk9/dev then we will continue in the jake forest where appropriate - > particularly in areas that are tied to JSR issues where we need to > iterate and prototype, also in areas where we need to re-work some areas > of the implementation. > > As people on this mailing list know, jake has the changes for > #AwkwardStrongEncapsulation [1] where setAccessible has been changed so > it can't be used to break into non-public members/types in exported > packages of JDK modules. It was changed more than a year ago to fail > when attempting to use it to break into non-exported packages. Dialing > it up further is a disruptive change that will expose a lot of hacks and > issues with existing code that is used to accessing non-public > fields/methods in JDK classes. It will take some libraries and tools a > bit of time to digest this change, even with the --add-opens command > line option and Add-Opens manifest in application JAR files to keep > existing code going. I plan to send mail to jdk9-dev in advance of this > integration to create wider awareness of this change. > > -Alan > > [1] > http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation From Alan.Bateman at oracle.com Wed Nov 23 13:59:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2016 13:59:17 +0000 Subject: Moving the changes in jake to jdk9/dev In-Reply-To: <1079693153.1498149.1479908182169.JavaMail.zimbra@u-pem.fr> References: <1079693153.1498149.1479908182169.JavaMail.zimbra@u-pem.fr> Message-ID: <3e90429e-2e2a-2bdd-2f16-96ccec31e208@oracle.com> On 23/11/2016 13:36, Remi Forax wrote: > Hi Alan, > With my ASM hat, > we've planned to make a new beta of ASM as soon as the module class file format patches are merged into jdk9 :) > Great. One thing that we've had to do in the JDK copy of ASM is update ClassWriter.visit to be able to take a null name (#ClassFileModuleName issue where this_class is 0). That is probably something that the update beta should handle for those using it to create a module-info.class. -Alan From Alan.Bateman at oracle.com Wed Nov 23 14:05:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2016 14:05:37 +0000 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: References: Message-ID: <3c4bcffb-cb61-de97-ae5b-98022a988aed@oracle.com> On 22/11/2016 21:07, Mandy Chung wrote: > This patch moves src.zip and jrt-fs.jar from the top-level into > the `lib` directory in the run-time image as we proposed [1]. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ > > This looks good. A minor point in SystemImage.findHome is that it's probably an InternalError if we are somehow loaded from a jrt-fs.jar that is not in the lib directory. -Alan From jan.lahoda at oracle.com Wed Nov 23 17:51:29 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 23 Nov 2016 17:51:29 +0000 Subject: hg: jigsaw/jake/langtools: Adjusting attribute name. Message-ID: <201611231751.uANHpTCb000885@aojmv0008.oracle.com> Changeset: 12008d1dd118 Author: jlahoda Date: 2016-11-23 16:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/12008d1dd118 Adjusting attribute name. ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java From mandy.chung at oracle.com Wed Nov 23 18:36:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Nov 2016 10:36:07 -0800 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: <3c4bcffb-cb61-de97-ae5b-98022a988aed@oracle.com> References: <3c4bcffb-cb61-de97-ae5b-98022a988aed@oracle.com> Message-ID: <09BFA0C3-FFC8-4F2C-BE8F-C839EB2DAE17@oracle.com> > On Nov 23, 2016, at 6:05 AM, Alan Bateman wrote: > > > > On 22/11/2016 21:07, Mandy Chung wrote: >> This patch moves src.zip and jrt-fs.jar from the top-level into >> the `lib` directory in the run-time image as we proposed [1]. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ >> >> > This looks good. A minor point in SystemImage.findHome is that it's probably an InternalError if we are somehow loaded from a jrt-fs.jar that is not in the lib directory. Agree. The existing check if non ?file? URL should also throw InternalError instead. Fixed. @@ -113,12 +113,16 @@ if (cs == null) return System.getProperty("java.home"); - // assume loaded from $TARGETJDK/jrt-fs.jar + // assume loaded from $TARGETJDK/lib/jrt-fs.jar URL url = cs.getLocation(); if (!url.getProtocol().equalsIgnoreCase("file")) - throw new RuntimeException(url + " loaded in unexpected way"); + throw new InternalError(url + " loaded in unexpected way"); try { - return Paths.get(url.toURI()).getParent().toString(); + Path lib = Paths.get(url.toURI()).getParent(); + if (!lib.getFileName().toString().equals("lib")) + throw new InternalError(url + " unexpected path"); + + return lib.getParent().toString(); } catch (URISyntaxException e) { throw new InternalError(e); } Mandy From alan.bateman at oracle.com Wed Nov 23 21:56:06 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 Nov 2016 21:56:06 +0000 Subject: hg: jigsaw/jake/jdk: 6 new changesets Message-ID: <201611232156.uANLu7UM019165@aojmv0008.oracle.com> Changeset: 29468cd5ce06 Author: alanb Date: 2016-11-23 15:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/29468cd5ce06 redefineModule should throw IAE if attempt to export/open to empty set ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! test/java/lang/instrument/RedefineModuleTest.java Changeset: b50194becf1e Author: alanb Date: 2016-11-23 15:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b50194becf1e ClassLoaders created by defineModulesWithManyLoaders can be named ! src/java.base/share/classes/jdk/internal/loader/Loader.java Changeset: cd5158cc58a3 Author: alanb Date: 2016-11-23 16:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd5158cc58a3 Further clarification to Class/ClassLoader getResourceXXXX methods ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java Changeset: 7765f0b6f887 Author: alanb Date: 2016-11-23 16:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7765f0b6f887 layers() should not be public ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java Changeset: fc06254e7c66 Author: alanb Date: 2016-11-23 21:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fc06254e7c66 More clean-up of services catalog ! 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/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java Changeset: c58c5cbfcfac Author: alanb Date: 2016-11-23 21:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c58c5cbfcfac More javadoc clarifications ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/util/ServiceLoader.java From jonathan.gibbons at oracle.com Wed Nov 23 22:02:14 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Nov 2016 22:02:14 +0000 Subject: hg: jigsaw/jake/langtools: 8168766: javadoc should support deprecation on modules. Message-ID: <201611232202.uANM2ERj021351@aojmv0008.oracle.com> Changeset: 98a2842ec26a Author: bpatel Date: 2016-11-23 14:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/98a2842ec26a 8168766: javadoc should support deprecation on modules. Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.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/ModuleWriterImpl.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/util/DeprecatedAPIListBuilder.java ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/jdk/javadoc/doclet/testModules/module1/module-info.java ! test/jdk/javadoc/doclet/testModules/module2/module-info.java ! test/jdk/javadoc/doclet/testModules/moduletags/module-info.java From jonathan.gibbons at oracle.com Wed Nov 23 22:16:06 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Nov 2016 22:16:06 +0000 Subject: hg: jigsaw/jake/langtools: remove interim/compatbility support for 'requires public' Message-ID: <201611232216.uANMG6JT025757@aojmv0008.oracle.com> Changeset: 1dcda080bb13 Author: jjg Date: 2016-11-23 14:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1dcda080bb13 remove interim/compatbility support for 'requires public' ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From jonathan.gibbons at oracle.com Wed Nov 23 23:30:44 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Nov 2016 23:30:44 +0000 Subject: hg: jigsaw/jake/langtools: 8159607: Update javadoc to support annotations on module-info.java Message-ID: <201611232330.uANNUiKS017278@aojmv0008.oracle.com> Changeset: 7678462efbc3 Author: bpatel Date: 2016-11-23 15:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7678462efbc3 8159607: Update javadoc to support annotations on module-info.java Reviewed-by: jjg ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/jdk/javadoc/doclet/testModules/module2/module-info.java + test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationType.java + test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationTypeUndocumented.java From forax at univ-mlv.fr Thu Nov 24 08:08:14 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 24 Nov 2016 09:08:14 +0100 (CET) Subject: uses is useless ? In-Reply-To: <3599517b-8e7c-819c-6ef4-e314810182f1@oracle.com> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> <1427011145.2137503.1479325277850.JavaMail.zimbra@u-pem.fr> <3599517b-8e7c-819c-6ef4-e314810182f1@oracle.com> Message-ID: <720089099.1694927.1479974894731.JavaMail.zimbra@u-pem.fr> I've resolved my problem of delegation of uses myself, trying to re-explain my problem, i wanted to provide a method on top of ServiceLoader and force modules that use that API to declare a directive uses. In fact, you don't need any additional support from the jdk because you can already use the new StackWalker API to get the caller module and do the check using methods of java.lang.reflect.Module. cheers, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: forax at univ-mlv.fr > Cc: "jigsaw-dev" > Envoy?: Jeudi 17 Novembre 2016 09:43:41 > Objet: Re: uses is useless ? > On 16/11/2016 19:41, forax at univ-mlv.fr wrote: > >> : >> My point is that in teory, that's cool but in reality the module-info of >> java.base (or java.sql) declares a lot of 'uses' making the whole idea moot. >> To avoid java.base to use 'uses', we need a way to be able to have a way to >> delegate the power of the ServiceLoader to another code, so the other code will >> have to use 'uses'. > If a consumer is making use of an API in java.base and the > implementation of that API makes use of services under the covers then > it is transparent to the consumer of the API. The consumer of the API > shouldn't need to know anything about the "SPI" types and would be very > surprising if the user of an API needed to declare `uses` on such types. > > In the JDK then I'm only aware of two cases where the consumer passes a > service type to an API that doesn't know anything about the service type > (the two cases are JVMCI and a utility method in javac). Both of these > cases use addUses to get through the hygiene check. > > jlink is a bit special in that the user of the tool needs at least some > global knowledge when choosing the service provider modules to include > in the run time image. As I said, the tool could help more but having it > do eager service binding is problematic as it tends to maximize rather > than minimize the number of the modules. > > -Alan. From alan.bateman at oracle.com Thu Nov 24 08:37:51 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 08:37:51 +0000 Subject: hg: jigsaw/jake/jdk: java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java needs :open Message-ID: <201611240837.uAO8bpVD029674@aojmv0008.oracle.com> Changeset: c853c037270d Author: alanb Date: 2016-11-24 08:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c853c037270d java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java needs :open ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java From forax at univ-mlv.fr Thu Nov 24 08:46:29 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 24 Nov 2016 09:46:29 +0100 (CET) Subject: modules and tests Message-ID: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> We already have discussed how to do testing in the new modular environment, but i'm not satisfied by the current state (but maybe i'm wrong). Here, i will focus on unit testing, which is the most intrusive kind of testing. Historically, unit testing was easy because you can have several source directories (src and test) containing the same package, note that this doesn't create split packages, because during the compilation, the classes inside src and test are compiled together and later executed together. Having a separation between a folder containing the sources and the on containing the tests allow to produce two jars, one based only on sources and one based on the merging between the sources and the tests. Because the tests can have dependencies not needed by the sources (think junit.jar by example), the classpath when compiling and running the sources and the tests was slightly differents, the classpath of the test having more dependencies. Now, we have introduced modules and modules define their own dependencies. At compile-time/runtime, source and test have to be in the same module otherwise, there will be a gap between the sources environment and the test environment. So like before, the idea is to generate two jars, representing the same module. Also, because sources and tests do not have exactly the same dependencies, the source folder and the test folder should have their own module-info.java. But when compiling the test, javac raises an error, because it doesn't allow to have two module-info files. I believe this is a bug that should be fixed. It's not obvious at it seems, it requires javac to be able to merge several module-info.java into one, and because the module descriptor allows to restrict exports or opens, the merging rules* as to be specified. But i think we should support modules AND tests by default as we have done since more than 20 years. regards, R?mi * here is an executable specification of the merging rules: https://github.com/forax/pro/blob/master/src/main/java/com.github.forax.pro.helper/com/github/forax/pro/helper/ModuleHelper.java#L258 From Alan.Bateman at oracle.com Thu Nov 24 09:04:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2016 09:04:54 +0000 Subject: uses is useless ? In-Reply-To: <720089099.1694927.1479974894731.JavaMail.zimbra@u-pem.fr> References: <249470150.1626689.1479289699963.JavaMail.zimbra@u-pem.fr> <3435cfa6-92a6-ff87-ab63-d9c477bce3d9@oracle.com> <1651466605.1688207.1479291949878.JavaMail.zimbra@u-pem.fr> <7cf4dafb-de6c-2b4f-4e22-a073d49893cf@oracle.com> <1427011145.2137503.1479325277850.JavaMail.zimbra@u-pem.fr> <3599517b-8e7c-819c-6ef4-e314810182f1@oracle.com> <720089099.1694927.1479974894731.JavaMail.zimbra@u-pem.fr> Message-ID: <700593b0-2dab-94f3-3644-4e5fc09ef9c9@oracle.com> On 24/11/2016 08:08, forax at univ-mlv.fr wrote: > I've resolved my problem of delegation of uses myself, > trying to re-explain my problem, i wanted to provide a method on top of ServiceLoader and force modules that use that API to declare a directive uses. This should work fine, assuming that the service types are accessible to the middleman and it makes use of addUses. -Alan > In fact, you don't need any additional support from the jdk because you can already use the new StackWalker API to get the caller module and do the check using methods of java.lang.reflect.Module. > > cheers, > R?mi > > From erik.joelsson at oracle.com Thu Nov 24 10:37:43 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 24 Nov 2016 10:37:43 +0000 Subject: hg: jigsaw/jake: Regenerated configure after merge Message-ID: <201611241037.uAOAbhQk007097@aojmv0008.oracle.com> Changeset: 13e19d185301 Author: erikj Date: 2016-11-24 11:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/13e19d185301 Regenerated configure after merge ! common/autoconf/generated-configure.sh From alan.bateman at oracle.com Thu Nov 24 12:55:05 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 12:55:05 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201611241255.uAOCt50V020016@aojmv0008.oracle.com> Changeset: 633cacfb9b2f Author: alanb Date: 2016-11-24 12:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/633cacfb9b2f Drop implAddExportsPrivate, no longer needed ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: a27f80d73f0d Author: alanb Date: 2016-11-24 12:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a27f80d73f0d Restore SL behavior when META-INF/services lists class that cannot be loaded ! src/java.base/share/classes/java/util/ServiceLoader.java From Alan.Bateman at oracle.com Thu Nov 24 13:31:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2016 13:31:49 +0000 Subject: modules and tests In-Reply-To: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> Message-ID: <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> On 24/11/2016 08:46, Remi Forax wrote: > : > > It's not obvious at it seems, it requires javac to be able to merge several module-info.java into one, and because the module descriptor allows to restrict exports or opens, the merging rules* as to be specified. > Have you run into anything that isn't solved by compiling with -Xmodule: and/or specify --add-reads and --add-exports to augment the module declaration? I realize it's awkward to specify these options but in time then I would expect the build tools and test runners to make this a lot easier. -Alan From sander.mak at luminis.eu Thu Nov 24 13:44:08 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Thu, 24 Nov 2016 13:44:08 +0000 Subject: modules and tests In-Reply-To: <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> Message-ID: <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> On 24 Nov 2016, at 14:31, Alan Bateman > wrote: On 24/11/2016 08:46, Remi Forax wrote: : It's not obvious at it seems, it requires javac to be able to merge several module-info.java into one, and because the module descriptor allows to restrict exports or opens, the merging rules* as to be specified. Have you run into anything that isn't solved by compiling with -Xmodule: and/or specify --add-reads and --add-exports to augment the module declaration? I realize it's awkward to specify these options but in time then I would expect the build tools and test runners to make this a lot easier. For a concrete example of this: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006594.html (modulo the old-style flags). Later I ported the same example to the a Maven build, which takes care of all this setup under the hood. Worked fine, without having to fiddle with -Xmodule/-Xpatch and readability to test-scope dependencies happens automatically in that case. Sander From alan.bateman at oracle.com Thu Nov 24 13:49:18 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:18 +0000 Subject: hg: jigsaw/jake/jaxp: 5 new changesets Message-ID: <201611241349.uAODnIvK008515@aojmv0008.oracle.com> Changeset: 53a255be3abc Author: dfuchs Date: 2016-11-15 17:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/53a255be3abc 8169723: remove jaxp/src/java.xml/share/classes/org/w3c/dom/xpath/COPYRIGHT.html Reviewed-by: rriggs - src/java.xml/share/classes/org/w3c/dom/xpath/COPYRIGHT.html Changeset: 16a430f8bed7 Author: aefimov Date: 2016-11-15 23:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/16a430f8bed7 8164479: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT) Reviewed-by: alanb, joehw, lancea, mchung Contributed-by: roman.grigoriadi at oracle.com ! src/java.xml/share/classes/module-info.java Changeset: 09eda28b98e4 Author: lana Date: 2016-11-21 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/09eda28b98e4 Merge Changeset: f1042f0aa643 Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f1042f0aa643 Added tag jdk-9+146 for changeset 09eda28b98e4 ! .hgtags Changeset: f5bb326c9dd4 Author: alanb Date: 2016-11-24 13:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f5bb326c9dd4 Merge ! src/java.xml/share/classes/module-info.java - src/java.xml/share/classes/org/w3c/dom/xpath/COPYRIGHT.html From alan.bateman at oracle.com Thu Nov 24 13:49:20 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:20 +0000 Subject: hg: jigsaw/jake/jaxws: 5 new changesets Message-ID: <201611241349.uAODnKqm008593@aojmv0008.oracle.com> Changeset: 26c9b9c51052 Author: aefimov Date: 2016-11-15 23:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/26c9b9c51052 8164479: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT) Reviewed-by: alanb, joehw, lancea, mchung Contributed-by: roman.grigoriadi at oracle.com ! src/java.activation/share/classes/javax/activation/CommandInfo.java ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/util/Which.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBContext.java ! src/java.xml.bind/share/classes/javax/xml/bind/attachment/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/util/package.html ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/encoding/XmlDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JCodeModel.java + src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JExportsDirective.java + src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JModule.java + src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JModuleDirective.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JPackage.java + src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JRequiresDirective.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/writer/FileCodeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/writer/FilterCodeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/writer/ProgressCodeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/writer/PrologCodeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/writer/SingleStreamCodeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/writer/ZipCodeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/Messages.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/Options.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/ProgressCodeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/ObjectFactoryGeneratorImpl.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CBuiltinLeafInfo.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/Constructor.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIInterface.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/NGCCRuntimeEx.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/group.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/TypeModeler.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceAp.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceWrapperGenerator.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/FilerCodeWriter.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java Changeset: b8671d61613c Author: aefimov Date: 2016-11-16 00:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b8671d61613c 8160999: GPL header missing comma in year Reviewed-by: mchung ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java Changeset: 1461e3e07876 Author: lana Date: 2016-11-21 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/1461e3e07876 Merge Changeset: baf914f0e298 Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/baf914f0e298 Added tag jdk-9+146 for changeset 1461e3e07876 ! .hgtags Changeset: 4db876cd4449 Author: alanb Date: 2016-11-24 13:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/4db876cd4449 Merge ! src/java.activation/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 From alan.bateman at oracle.com Thu Nov 24 13:49:17 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:17 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201611241349.uAODnHqt008465@aojmv0008.oracle.com> Changeset: dc49e0922a8e Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/dc49e0922a8e Added tag jdk-9+146 for changeset ecd74b41ab65 ! .hgtags Changeset: f02fa6dd4e0b Author: alanb Date: 2016-11-24 09:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f02fa6dd4e0b Merge From alan.bateman at oracle.com Thu Nov 24 13:49:17 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:17 +0000 Subject: hg: jigsaw/jake: 11 new changesets Message-ID: <201611241349.uAODnHjn008483@aojmv0008.oracle.com> Changeset: 0ec12d231af9 Author: ehelin Date: 2016-09-28 16:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0ec12d231af9 8166790: Add stress test GCBasher Reviewed-by: dfazunen, dholmes, erikj, tschatzl, lmesnik ! make/jprt.properties Changeset: a26dbefcc658 Author: dpochepk Date: 2016-10-20 16:53 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a26dbefcc658 8155219: [TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java Reviewed-by: kvn ! test/jtreg-ext/requires/VMProps.java Changeset: f04a8e69ec8f Author: amurillo Date: 2016-10-20 17:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f04a8e69ec8f Merge Changeset: 49aa366f9afc Author: sla Date: 2016-10-21 15:40 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/49aa366f9afc 8168412: Reduce buffering in jtreg timeouthandler Reviewed-by: mlarsson ! test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlSection.java ! 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: 281a14e87a3b Author: sla Date: 2016-10-24 09:12 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/281a14e87a3b 8168414: Various timeouthandler fixes Reviewed-by: mlarsson ! test/failure_handler/Makefile ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/ActionHelper.java Changeset: eeb794d72bbf Author: dsamersoff Date: 2016-10-25 14:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/eeb794d72bbf 8165500: TestJpsJar shouldn't jar all test.classpath directories Summary: Refactor test to better handle errors Reviewed-by: sspitsyn ! test/lib/jdk/test/lib/apps/LingeredApp.java Changeset: ca7f2d2fa460 Author: jwilhelm Date: 2016-11-09 15:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ca7f2d2fa460 Merge Changeset: a22e2671d88f Author: lana Date: 2016-11-21 18:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a22e2671d88f Merge Changeset: 3e3e158ef45f Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3e3e158ef45f Added tag jdk-9+146 for changeset a22e2671d88f ! .hgtags Changeset: dfa387b4ba02 Author: alanb Date: 2016-11-24 13:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/dfa387b4ba02 Merge ! common/autoconf/generated-configure.sh ! make/jprt.properties ! 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: 3d8def3e9ed0 Author: alanb Date: 2016-11-24 13:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3d8def3e9ed0 Merge ! common/autoconf/generated-configure.sh From alan.bateman at oracle.com Thu Nov 24 13:49:20 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:20 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201611241349.uAODnKoS008603@aojmv0008.oracle.com> Changeset: d715163cd7c5 Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d715163cd7c5 Added tag jdk-9+146 for changeset 26f972dc2d17 ! .hgtags Changeset: 7178621e9e1f Author: alanb Date: 2016-11-24 09:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7178621e9e1f Merge ! .hgtags From alan.bateman at oracle.com Thu Nov 24 13:49:22 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:22 +0000 Subject: hg: jigsaw/jake/nashorn: 5 new changesets Message-ID: <201611241349.uAODnNiE008615@aojmv0008.oracle.com> Changeset: 1e7049278c4c Author: sla Date: 2016-10-24 09:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1e7049278c4c 8168483: Remove jtreg timeout handler timeout Reviewed-by: dholmes, tbell ! test/Makefile Changeset: ce057a78b44c Author: jwilhelm Date: 2016-11-09 13:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ce057a78b44c Merge Changeset: 55f5a96988de Author: lana Date: 2016-11-21 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/55f5a96988de Merge Changeset: 82281fffea7c Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/82281fffea7c Added tag jdk-9+146 for changeset 55f5a96988de ! .hgtags Changeset: 75b099ddc58a Author: alanb Date: 2016-11-24 09:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/75b099ddc58a Merge ! .hgtags From alan.bateman at oracle.com Thu Nov 24 13:49:27 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:27 +0000 Subject: hg: jigsaw/jake/jdk: 20 new changesets Message-ID: <201611241349.uAODnSwd008673@aojmv0008.oracle.com> Changeset: 892fde66a95e Author: darcy Date: 2016-11-15 13:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/892fde66a95e 8169736: Mark RmiIiopReturnValueTest.java as intermittently failing Reviewed-by: lancea ! test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java Changeset: ff9c1d07969e Author: vtewari Date: 2016-10-20 15:07 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff9c1d07969e 8167294: MXBean javadoc should be updated to take modules into account Summary: Updated MXBean class javadoc to take modules into account Reviewed-by: alanb Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/javax/management/MXBean.java Changeset: 4a837dd80453 Author: amurillo Date: 2016-10-20 17:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a837dd80453 Merge - src/java.base/share/classes/jdk/internal/misc/JavaNetAccess.java - src/jdk.jlink/share/classes/jdk/tools/jlink/Jlink.java - src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkPermission.java - test/sun/net/www/protocol/https/HttpsClient/OriginServer.java - test/sun/security/tools/jarsigner/ts.sh Changeset: 50851d9db89f Author: sla Date: 2016-10-24 09:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/50851d9db89f 8168483: Remove jtreg timeout handler timeout Reviewed-by: dholmes, tbell ! test/Makefile Changeset: 11932b04e6a0 Author: rehn Date: 2016-10-24 09:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/11932b04e6a0 8164501: Uninitialised memory in byteArrayToPacket of SharedMemoryConnection.c Reviewed-by: sla, dsamersoff ! src/jdk.jdi/share/native/libdt_shmem/SharedMemoryConnection.c Changeset: 0b19d27ee4dc Author: rehn Date: 2016-10-24 11:47 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0b19d27ee4dc Merge Changeset: 7a5fa747419d Author: dsamersoff Date: 2016-10-24 14:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7a5fa747419d 8160376: DebuggerException: Can't attach symbolicator to the process Summary: Make SA link to JavaRuntimeSupport in MacOS X Reviewed-by: dsamersoff, dcubed Contributed-by: Sharath Ballal ! test/ProblemList.txt Changeset: b60ef7010504 Author: dsamersoff Date: 2016-10-25 14:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b60ef7010504 8165500: TestJpsJar shouldn't jar all test.classpath directories Summary: Refactor test to better handle errors Reviewed-by: sspitsyn ! test/ProblemList.txt - test/sun/tools/jps/JpsBase.java ! test/sun/tools/jps/JpsHelper.java + test/sun/tools/jps/LingeredApp.java + test/sun/tools/jps/LingeredAppForJps.java + test/sun/tools/jps/TestJps.java - test/sun/tools/jps/TestJpsClass.java - test/sun/tools/jps/TestJpsJar.java - test/sun/tools/jps/TestJpsJarRelative.java ! test/sun/tools/jps/TestJpsSanity.java Changeset: 016c12cbe397 Author: vtewari Date: 2016-10-26 15:08 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/016c12cbe397 8151099: java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. Summary: Removed dependency of java.management over jdk.management. Reviewed-by: mchung, dfuchs, dholmes Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/java.management/share/native/libmanagement/VMManagementImpl.c ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java + test/java/lang/management/ManagementFactory/DefaultManagementProviderTest.java Changeset: 0f7b50cc702f Author: psandoz Date: 2016-10-14 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f7b50cc702f 8166974: invokedynamic implementation should not wrap Errors Reviewed-by: smarks, jrose ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/lang/invoke/package-info.java ! test/java/lang/invoke/8022701/InvokeSeveralWays.java Changeset: 71457eaca096 Author: dsamersoff Date: 2016-10-28 11:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/71457eaca096 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build Summary: Remove BasicLauncherTest.java and HeapDumpTest.java from quarantine list. Reviewed-by: sla, dsamersoff Contributed-by: sharath.ballal at oracle.com ! test/ProblemList.txt Changeset: 8c9df9fa7104 Author: psandoz Date: 2016-11-01 17:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c9df9fa7104 8163553: java.lang.LinkageError from test java/lang/ThreadGroup/Stop.java Reviewed-by: redestad ! 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/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 21d90fa8d825 Author: vtewari Date: 2016-11-03 12:04 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/21d90fa8d825 8006078: [findbugs] java.lang.management.ThreadInfo returns mutable objects Summary: Cloned the array before returning to caller. Reviewed-by: dholmes, fparain Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/java/lang/management/ThreadInfo.java Changeset: 93fb16cbdf7f Author: jwilhelm Date: 2016-11-09 13:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93fb16cbdf7f Merge ! test/ProblemList.txt - test/sun/tools/jps/JpsBase.java - test/sun/tools/jps/TestJpsClass.java - test/sun/tools/jps/TestJpsJar.java - test/sun/tools/jps/TestJpsJarRelative.java Changeset: 7d2e6e2438c2 Author: weijun Date: 2016-11-16 12:55 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d2e6e2438c2 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris Reviewed-by: xuelei ! test/sun/security/krb5/auto/ReplayCacheTestProc.java ! test/sun/security/krb5/auto/rcache_usemd5.sh Changeset: 6e4ff59afb5d Author: lana Date: 2016-11-21 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e4ff59afb5d Merge Changeset: c9d97eff6bfd Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c9d97eff6bfd Added tag jdk-9+146 for changeset 6e4ff59afb5d ! .hgtags Changeset: fa2c225bbcaa Author: alanb Date: 2016-11-24 13:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa2c225bbcaa Merge ! .hgtags ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/java.management/share/native/libmanagement/VMManagementImpl.c ! test/Makefile ! test/ProblemList.txt ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java ! test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java - test/sun/tools/jps/JpsBase.java - test/sun/tools/jps/TestJpsClass.java - test/sun/tools/jps/TestJpsJar.java - test/sun/tools/jps/TestJpsJarRelative.java ! test/sun/tools/jps/TestJpsSanity.java Changeset: 0f91d4d7b0d8 Author: alanb Date: 2016-11-24 13:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f91d4d7b0d8 Merge Changeset: 6ff9009ce6cf Author: yan Date: 2016-11-24 13:39 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6ff9009ce6cf 2 JavaSound tests failing ! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java From alan.bateman at oracle.com Thu Nov 24 13:49:36 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 13:49:36 +0000 Subject: hg: jigsaw/jake/hotspot: 81 new changesets Message-ID: <201611241349.uAODna6p008710@aojmv0008.oracle.com> Changeset: d5c67c13e5f9 Author: mcberg Date: 2016-10-18 19:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d5c67c13e5f9 8167987: change merge context to clear for mask register usage model Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp Changeset: f5c44b9b4ff9 Author: hshi Date: 2016-10-17 05:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5c44b9b4ff9 8167421: AArch64: in one core system, fatal error: Illegal threadstate encountered Summary: adding missing thread state store when os::is_MP() is false Reviewed-by: aph ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Changeset: efcbf5de754e Author: ehelin Date: 2016-10-06 16:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/efcbf5de754e 8166790: Add stress test GCBasher Reviewed-by: dfazunen, dholmes, erikj, tschatzl, lmesnik ! test/TEST.groups + test/gc/stress/gcbasher/ByteCursor.java + test/gc/stress/gcbasher/Bytecode.java + test/gc/stress/gcbasher/ClassInfo.java + test/gc/stress/gcbasher/ConstantPoolEntry.java + test/gc/stress/gcbasher/Decompiler.java + test/gc/stress/gcbasher/Dependency.java + test/gc/stress/gcbasher/MethodInfo.java + test/gc/stress/gcbasher/TestGCBasher.java + test/gc/stress/gcbasher/TestGCBasherWithCMS.java + test/gc/stress/gcbasher/TestGCBasherWithG1.java + test/gc/stress/gcbasher/TestGCBasherWithParallel.java + test/gc/stress/gcbasher/TestGCBasherWithSerial.java Changeset: 844f8dd1e097 Author: kzhaldyb Date: 2016-09-28 17:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/844f8dd1e097 8166804: Convert TestMetachunk_test to GTest Reviewed-by: iignatyev ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/memory/test_metachunk.cpp Changeset: b426373a34a3 Author: kzhaldyb Date: 2016-09-28 17:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b426373a34a3 8166563: Convert GuardedMemory_test to Gtest Reviewed-by: iignatyev ! src/share/vm/memory/guardedMemory.cpp ! src/share/vm/memory/guardedMemory.hpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/memory/test_guardedMemory.cpp Changeset: 817bb013257f Author: kzhaldyb Date: 2016-10-19 12:10 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/817bb013257f Merge Changeset: 5fd2019b77bd Author: akulyakh Date: 2016-10-18 14:27 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fd2019b77bd 8166289: RuntimeException: canRead() reports false for reading from the same module: expected true, was false Summary: A fix in the JDWP test along with some extra logging added Reviewed-by: sspitsyn ! test/serviceability/jdwp/AllModulesCommandTest.java ! test/serviceability/jdwp/JdwpCanReadReply.java ! test/serviceability/jdwp/JdwpCmd.java + test/serviceability/jdwp/JdwpModuleCmd.java + test/serviceability/jdwp/JdwpModuleReply.java + test/serviceability/jdwp/JdwpVisibleClassesCmd.java + test/serviceability/jdwp/JdwpVisibleClassesReply.java Changeset: 7e0181d2ca46 Author: lmesnik Date: 2016-10-19 10:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7e0181d2ca46 8155570: serviceability/tmtools/jstat/GcTest02.java fails with parallel GC Reviewed-by: jwilhelm ! test/serviceability/tmtools/jstat/GcTest02.java ! test/serviceability/tmtools/jstat/utils/GcProvokerImpl.java Changeset: 99096bf79f31 Author: lmesnik Date: 2016-10-19 10:06 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/99096bf79f31 8166724: gc/g1/TestHumongousShrinkHeap.java fails with OOME Reviewed-by: dfazunen, jwilhelm ! test/gc/g1/TestHumongousShrinkHeap.java Changeset: 4c2ce2515ad0 Author: dfazunen Date: 2016-10-19 16:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c2ce2515ad0 Merge Changeset: bc41ec244c94 Author: mwalsh Date: 2016-10-19 10:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc41ec244c94 8164002: Add a new CPU family (S_family) for SPARC S7 and above processors Reviewed-by: dholmes, ecaspole, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp Changeset: 51277d8704af Author: kvn Date: 2016-10-19 17:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/51277d8704af Merge Changeset: d7f89a030d77 Author: dnsimon Date: 2016-10-19 20:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d7f89a030d77 8168295: [JVMCI] -XX:+JVMCIPrintProperties should exit after printing Reviewed-by: kvn, twisti ! .mx.jvmci/.pydevproject ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! src/share/vm/jvmci/jvmci_globals.hpp ! test/compiler/jvmci/TestJVMCIPrintProperties.java Changeset: 77f3076526fc Author: dnsimon Date: 2016-10-19 18:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/77f3076526fc Merge Changeset: 204391ad6da1 Author: kzhaldyb Date: 2016-10-20 10:51 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/204391ad6da1 8166910: Convert TestNewSize_test to GTest 8166911: Convert TestOldSize_test to GTest Reviewed-by: jwilhelm ! src/share/vm/gc/shared/collectorPolicy.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/shared/test_collectorPolicy.cpp Changeset: c702e121cc7d Author: dpochepk Date: 2016-10-20 16:53 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c702e121cc7d 8155219: [TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java Reviewed-by: kvn ! test/TEST.ROOT + test/compiler/ciReplay/CiReplayBase.java + test/compiler/ciReplay/SABase.java + test/compiler/ciReplay/TestClientVM.java - test/compiler/ciReplay/TestSA.sh + test/compiler/ciReplay/TestSAClient.java + test/compiler/ciReplay/TestSAServer.java + test/compiler/ciReplay/TestServerVM.java - test/compiler/ciReplay/TestVM.sh + test/compiler/ciReplay/TestVMNoCompLevel.java - test/compiler/ciReplay/TestVM_no_comp_level.sh + test/compiler/ciReplay/VMBase.java - test/compiler/ciReplay/common.sh Changeset: aa0eb810845d Author: kzhaldyb Date: 2016-10-20 23:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aa0eb810845d 8159817: Convert FreeRegionList_test to GTest Reviewed-by: kbarrett ! src/share/vm/gc/g1/heapRegionSet.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/g1/test_freeRegionList.cpp Changeset: 89101c8b05cf Author: iklam Date: 2016-10-20 13:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89101c8b05cf 8166203: NoClassDefFoundError should not be thrown if class is in_error_state at link time Reviewed-by: coleenp, dholmes, sspitsyn ! src/share/vm/oops/instanceKlass.cpp ! test/runtime/lambda-features/InterfaceInitializationStates.java Changeset: 983636b47638 Author: iklam Date: 2016-10-20 21:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/983636b47638 Merge Changeset: 732e5293c173 Author: amurillo Date: 2016-10-20 17:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/732e5293c173 Merge Changeset: 0f2a78897867 Author: mdoerr Date: 2016-10-21 10:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0f2a78897867 8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() Reviewed-by: simonis, mdoerr Contributed-by: Michihiro Horie ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.cpp Changeset: ce3eaa22b582 Author: dsamersoff Date: 2016-10-21 12:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ce3eaa22b582 8164383: jhsdb dumps core on Solaris 12 when loading dumped core Summary: Add the required extra parameters to Plookup_by_addr() and proc_arg_grab() as per the change to libproc with Solaris 12. Reviewed-by: dsamersoff, sspitsyn Contributed-by: jini.george at oracle.com ! make/lib/Lib-jdk.hotspot.agent.gmk ! src/jdk.hotspot.agent/solaris/native/libsaproc/libproc.h ! src/jdk.hotspot.agent/solaris/native/libsaproc/salibproc.h ! src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp Changeset: 720ce1221cd2 Author: akulyakh Date: 2016-10-21 17:04 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/720ce1221cd2 8168479: Quarantine serviceability/jdwp/AllModulesCommandTest.java test Summary: Quarantining a test Reviewed-by: sla ! test/serviceability/jdwp/AllModulesCommandTest.java Changeset: bb6799e62761 Author: mgronlun Date: 2016-10-21 16:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bb6799e62761 8166806: Add intrinsic support for writer used in event based tracing Reviewed-by: kvn, egahlin ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/trace/traceMacros.hpp Changeset: 272fd21a0917 Author: mgronlun Date: 2016-10-21 17:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/272fd21a0917 Merge Changeset: 138e5abe35a9 Author: kvn Date: 2016-10-21 10:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/138e5abe35a9 8165381: Update for x86 SHA512 using AVX2 Summary: Add intrinsics for x86 AVX2 architecture with no SHA instructions. Reviewed-by: kvn Contributed-by: smita.kamath at intel.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86_sha.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java Changeset: aa7e3876ea74 Author: neliasso Date: 2016-10-21 20:12 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aa7e3876ea74 8166377: is_compiled_by_jvmci hot in some profiles - improve nmethod compiler type detection Summary: Refactor code removing virtual call Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/compiledMethod.cpp ! src/share/vm/code/compiledMethod.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/abstractCompiler.hpp + src/share/vm/compiler/compilerDefinitions.cpp + src/share/vm/compiler/compilerDefinitions.hpp ! src/share/vm/jvmci/jvmciCompiler.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/rtmLocking.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 560423724f98 Author: rraghavan Date: 2016-10-21 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/560423724f98 8165661: SPECjvm2008-crypto.signverify regression in 9-b105 Summary: Reverted part change done earlier for 8145322 - removed the (CastII (AddI x const)) -> (AddI (CastII x) const) transformation Reviewed-by: roland, kvn, thartmann ! src/share/vm/opto/castnode.cpp Changeset: d005924be65c Author: dlong Date: 2016-10-21 17:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d005924be65c 8160411: SIGSEGV in frame::safe_for_sender on incomplete DeoptimizationBlob frame Summary: add range check for sender_sp Reviewed-by: aph, dcubed ! src/cpu/aarch64/vm/frame_aarch64.cpp ! src/cpu/x86/vm/frame_x86.cpp Changeset: 820e8a4db30d Author: kbarrett Date: 2016-10-21 22:26 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/820e8a4db30d 8166862: CMS needs klass_or_null_acquire Summary: Change CMS non-assert uses of klass_or_null to klass_or_null_acquire. Reviewed-by: tschatzl, mgerdin ! src/share/vm/gc/cms/compactibleFreeListSpace.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Changeset: 3577291c1a50 Author: simonis Date: 2016-10-06 18:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3577291c1a50 8167299: -XX:+PrintRelocations crashes the VM Reviewed-by: kvn ! src/share/vm/code/relocInfo.cpp Changeset: 65e6e008235f Author: sla Date: 2016-10-24 09:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/65e6e008235f 8168483: Remove jtreg timeout handler timeout Reviewed-by: dholmes, tbell ! test/Makefile Changeset: 830b86a4ead5 Author: sla Date: 2016-10-24 09:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/830b86a4ead5 Merge Changeset: ad402ced3a63 Author: dsamersoff Date: 2016-10-24 14:51 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ad402ced3a63 8160376: DebuggerException: Can't attach symbolicator to the process Summary: Make SA link to JavaRuntimeSupport in MacOS X Reviewed-by: dsamersoff, dcubed Contributed-by: Sharath Ballal ! make/lib/Lib-jdk.hotspot.agent.gmk ! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m ! test/runtime/SharedArchiveFile/SASymbolTableTest.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Changeset: 47e5864ea577 Author: jprovino Date: 2016-10-24 10:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/47e5864ea577 8160055: Misplaced call to ClassLoaderDataGraph::clear_claimed_marks during initial mark Summary: The call to ClassLoaderDataGraph::clear_claimed_marks() during initial mark in g1CollectedHeap.cpp:4420 is misplaced. Reviewed-by: tschatzl, kbarrett ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.hpp ! test/gc/g1/TestGCLogMessages.java Changeset: 22635dbb3f84 Author: jprovino Date: 2016-10-24 16:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/22635dbb3f84 Merge Changeset: a47416372bd6 Author: kvn Date: 2016-10-24 11:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a47416372bd6 8168317: [JVMCI] use reflection instead of jdk 9 Module API in Services.java Reviewed-by: iveresov, twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java Changeset: dbbfe9e68ad9 Author: cjplummer Date: 2016-10-24 14:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dbbfe9e68ad9 8166679: JNI AsyncGetCallTrace replaces topmost frame name with starting with Java 9 b133 Summary: Partly undid the changes for 8159284, which are the cause of this CR. Reviewed-by: dholmes, coleenp, dcubed ! src/cpu/aarch64/vm/frame_aarch64.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp Changeset: 0207c729b674 Author: vtewari Date: 2016-10-26 14:58 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0207c729b674 8151099: java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. Summary: Removed dependency of java.management over jdk.management. Reviewed-by: mchung, dfuchs, dholmes Contributed-by: amit.sapre at oracle.com ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp Changeset: 95c6654fa2ee Author: drwhite Date: 2016-10-24 13:36 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/95c6654fa2ee 8168567: Fix for 8166972 breaks aarch64 build Summary: Addded missing #endif for aarch64 code. Reviewed-by: kvn, aph Contributed-by: Ningsheng Jian ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp Changeset: ed468ebf42b3 Author: jwilhelm Date: 2016-05-11 23:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ed468ebf42b3 8156800: Convert QuickSort_test to GTest Reviewed-by: rehn, kzhaldyb, rprotacio, mlarsson ! src/share/vm/utilities/internalVMTests.cpp - src/share/vm/utilities/quickSort.cpp ! test/native/utilities/test_quicksort.cpp Changeset: dfe9fb173b3e Author: jwilhelm Date: 2016-05-20 16:45 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dfe9fb173b3e 8157453: Convert DependencyContext_test to GTest Reviewed-by: dholmes, rehn, kzhaldyb ! src/share/vm/code/dependencyContext.cpp ! src/share/vm/code/dependencyContext.hpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/code/test_dependencyContext.cpp Changeset: 572f4f11a35f Author: jwilhelm Date: 2016-05-23 19:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/572f4f11a35f 8157455: Convert TestOS_test to GTest Reviewed-by: dholmes, rehn ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/internalVMTests.cpp ! test/native/runtime/test_os.cpp Changeset: a5fdf2f30c6e Author: thartmann Date: 2016-10-26 14:36 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a5fdf2f30c6e 8164612: NoSuchMethodException when method name contains NULL or Latin-1 supplement character Summary: String length needs to be updated when converting from unicode to utf8. Reviewed-by: kvn, coleenp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp + test/runtime/CompactStrings/TestMethodNames.java Changeset: 1ca21e468b1b Author: bmoloden Date: 2016-10-26 17:29 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ca21e468b1b 8165451: Convert WorkerDataArray_test to GTest Reviewed-by: jwilhelm ! src/share/vm/gc/g1/workerDataArray.cpp ! src/share/vm/utilities/internalVMTests.cpp + test/native/gc/g1/test_workerDataArray.cpp Changeset: 46c8f9b67187 Author: rprotacio Date: 2016-10-26 15:46 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/46c8f9b67187 8167995: -Xlog:defaultmethods=debug: lengthy method descriptor triggers "StringStream is re-allocated with a different ResourceMark" Summary: Removed nested ResourceMark declarations Reviewed-by: dholmes, hseigel ! src/share/vm/classfile/defaultMethods.cpp Changeset: 9ce79aaf2e0b Author: rprotacio Date: 2016-10-26 20:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ce79aaf2e0b Merge - src/share/vm/utilities/quickSort.cpp - test/compiler/ciReplay/TestSA.sh - test/compiler/ciReplay/TestVM.sh - test/compiler/ciReplay/TestVM_no_comp_level.sh - test/compiler/ciReplay/common.sh Changeset: d9aa9adb7dd2 Author: simonis Date: 2016-10-25 16:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9aa9adb7dd2 8168490: Use the LL/ULL suffixes to define 64-bit integer literals on Windows Reviewed-by: dholmes, mgerdin, stuefe ! src/os/aix/vm/globals_aix.hpp ! src/os/aix/vm/os_aix.cpp ! src/share/vm/memory/virtualspace.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/globalDefinitions_xlc.hpp Changeset: 59da89afe788 Author: goetz Date: 2016-09-22 18:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59da89afe788 8166560: [s390] Basic enablement of s390 port. Summary: Also fix problem with ARM Elf configuration. Reviewed-by: dholmes, coleenp ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h ! src/os/linux/vm/os_linux.cpp ! src/share/tools/hsdis/hsdis.c ! src/share/vm/code/codeCache.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/macros.hpp Changeset: c1715eaaa820 Author: goetz Date: 2016-09-22 18:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c1715eaaa820 8166561: [s390] Adaptions needed for s390 port in C1 and C2. Reviewed-by: kvn ! src/cpu/aarch64/vm/c2_globals_aarch64.hpp ! src/cpu/ppc/vm/c2_globals_ppc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp Changeset: a0cf41abef5d Author: goetz Date: 2016-10-05 15:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a0cf41abef5d 8167184: [s390] Extend relocations for pc-relative instructions. Reviewed-by: kvn ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: 2844bdfd7a99 Author: goetz Date: 2016-10-13 14:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2844bdfd7a99 8167673: [s390] The s390 port. Summary: template interpreter, C1, C2 Reviewed-by: kvn, simonis + src/cpu/s390/vm/abstractInterpreter_s390.cpp + src/cpu/s390/vm/assembler_s390.cpp + src/cpu/s390/vm/assembler_s390.hpp + src/cpu/s390/vm/assembler_s390.inline.hpp + src/cpu/s390/vm/bytes_s390.hpp + src/cpu/s390/vm/c1_CodeStubs_s390.cpp + src/cpu/s390/vm/c1_Defs_s390.hpp + src/cpu/s390/vm/c1_FpuStackSim_s390.hpp + src/cpu/s390/vm/c1_FrameMap_s390.cpp + src/cpu/s390/vm/c1_FrameMap_s390.hpp + src/cpu/s390/vm/c1_LIRAssembler_s390.cpp + src/cpu/s390/vm/c1_LIRAssembler_s390.hpp + src/cpu/s390/vm/c1_LIRGenerator_s390.cpp + src/cpu/s390/vm/c1_LIR_s390.cpp + src/cpu/s390/vm/c1_LinearScan_s390.cpp + src/cpu/s390/vm/c1_LinearScan_s390.hpp + src/cpu/s390/vm/c1_MacroAssembler_s390.cpp + src/cpu/s390/vm/c1_MacroAssembler_s390.hpp + src/cpu/s390/vm/c1_Runtime1_s390.cpp + src/cpu/s390/vm/c1_globals_s390.hpp + src/cpu/s390/vm/c2_globals_s390.hpp + src/cpu/s390/vm/c2_init_s390.cpp + src/cpu/s390/vm/codeBuffer_s390.hpp + src/cpu/s390/vm/compiledIC_s390.cpp + src/cpu/s390/vm/copy_s390.hpp + src/cpu/s390/vm/debug_s390.cpp + src/cpu/s390/vm/depChecker_s390.hpp + src/cpu/s390/vm/disassembler_s390.hpp + src/cpu/s390/vm/frame_s390.cpp + src/cpu/s390/vm/frame_s390.hpp + src/cpu/s390/vm/frame_s390.inline.hpp + src/cpu/s390/vm/globalDefinitions_s390.hpp + src/cpu/s390/vm/globals_s390.hpp + src/cpu/s390/vm/icBuffer_s390.cpp + src/cpu/s390/vm/icache_s390.cpp + src/cpu/s390/vm/icache_s390.hpp + src/cpu/s390/vm/interp_masm_s390.cpp + src/cpu/s390/vm/interp_masm_s390.hpp + src/cpu/s390/vm/interpreterRT_s390.cpp + src/cpu/s390/vm/interpreterRT_s390.hpp + src/cpu/s390/vm/javaFrameAnchor_s390.hpp + src/cpu/s390/vm/jniFastGetField_s390.cpp + src/cpu/s390/vm/jniTypes_s390.hpp + src/cpu/s390/vm/jni_s390.h + src/cpu/s390/vm/jvmciCodeInstaller_s390.cpp + src/cpu/s390/vm/macroAssembler_s390.cpp + src/cpu/s390/vm/macroAssembler_s390.hpp + src/cpu/s390/vm/macroAssembler_s390.inline.hpp + src/cpu/s390/vm/metaspaceShared_s390.cpp + src/cpu/s390/vm/methodHandles_s390.cpp + src/cpu/s390/vm/methodHandles_s390.hpp + src/cpu/s390/vm/nativeInst_s390.cpp + src/cpu/s390/vm/nativeInst_s390.hpp + src/cpu/s390/vm/registerMap_s390.hpp + src/cpu/s390/vm/registerSaver_s390.hpp + src/cpu/s390/vm/register_definitions_s390.cpp + src/cpu/s390/vm/register_s390.cpp + src/cpu/s390/vm/register_s390.hpp + src/cpu/s390/vm/relocInfo_s390.cpp + src/cpu/s390/vm/relocInfo_s390.hpp + src/cpu/s390/vm/runtime_s390.cpp + src/cpu/s390/vm/s390.ad + src/cpu/s390/vm/sharedRuntime_s390.cpp + src/cpu/s390/vm/stubGenerator_s390.cpp + src/cpu/s390/vm/stubRoutines_s390.cpp + src/cpu/s390/vm/stubRoutines_s390.hpp + src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp + src/cpu/s390/vm/templateTable_s390.cpp + src/cpu/s390/vm/templateTable_s390.hpp + src/cpu/s390/vm/vmStructs_s390.hpp + src/cpu/s390/vm/vm_version_s390.cpp + src/cpu/s390/vm/vm_version_s390.hpp + src/cpu/s390/vm/vmreg_s390.cpp + src/cpu/s390/vm/vmreg_s390.hpp + src/cpu/s390/vm/vmreg_s390.inline.hpp + src/cpu/s390/vm/vtableStubs_s390.cpp + src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp + src/os_cpu/linux_s390/vm/bytes_linux_s390.inline.hpp + src/os_cpu/linux_s390/vm/globals_linux_s390.hpp + src/os_cpu/linux_s390/vm/orderAccess_linux_s390.inline.hpp + src/os_cpu/linux_s390/vm/os_linux_s390.cpp + src/os_cpu/linux_s390/vm/os_linux_s390.hpp + src/os_cpu/linux_s390/vm/prefetch_linux_s390.inline.hpp + src/os_cpu/linux_s390/vm/thread_linux_s390.cpp + src/os_cpu/linux_s390/vm/thread_linux_s390.hpp + src/os_cpu/linux_s390/vm/vmStructs_linux_s390.hpp Changeset: abb2824d2dfd Author: mlarsson Date: 2016-10-21 10:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/abb2824d2dfd 8166117: Add UTC timestamp decorator for UL Reviewed-by: rehn, rprotacio ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/logging/logDecorations.cpp ! src/share/vm/logging/logDecorators.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! test/native/logging/test_logDecorations.cpp ! test/native/logging/test_logDecorators.cpp Changeset: 46a9564b8513 Author: mlarsson Date: 2016-10-21 10:14 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/46a9564b8513 8146009: "pure virtual method called" with using new GC logging mechanism Reviewed-by: dsamersoff, dholmes, mchernov Contributed-by: marcus.larsson at oracle.com, michail.chernov at oracle.com ! src/share/vm/logging/logConfiguration.cpp ! src/share/vm/logging/logDecorations.hpp ! src/share/vm/logging/logFileStreamOutput.cpp ! src/share/vm/logging/logFileStreamOutput.hpp ! src/share/vm/logging/logOutput.cpp ! src/share/vm/logging/logOutput.hpp ! src/share/vm/logging/logTagSet.cpp + test/gc/g1/logging/TestG1LoggingFailure.java ! test/native/logging/test_logConfiguration.cpp ! test/native/logging/test_logOutputList.cpp ! test/native/logging/test_logTagSet.cpp Changeset: 8cd9f7147af1 Author: mdoerr Date: 2016-10-27 11:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8cd9f7147af1 8168083: PPC64: Cleanup template interpreter after 8154580 and 8154867 Reviewed-by: goetz, coleenp ! src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp ! src/cpu/ppc/vm/templateTable_ppc_64.cpp Changeset: 3609eb7f27fa Author: mgronlun Date: 2016-10-27 11:14 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3609eb7f27fa 8168662: Intrinsic support for event based tracing needs explicit control dependency Reviewed-by: kvn, rehn ! src/share/vm/opto/library_call.cpp Changeset: 0b1e2f0e62b5 Author: mgronlun Date: 2016-10-27 11:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b1e2f0e62b5 Merge Changeset: d13e2c90fcef Author: mgronlun Date: 2016-10-27 12:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d13e2c90fcef Merge Changeset: 622d3fe587f2 Author: goetz Date: 2016-10-27 12:22 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/622d3fe587f2 8168318: PPC64: Use cmpldi instead of li/cmpld Reviewed-by: goetz Contributed-by: igor.nunes at eldorado.org.br ! src/cpu/ppc/vm/ppc.ad Changeset: 5633d5463a8b Author: gziemski Date: 2016-10-27 09:42 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5633d5463a8b 8166145: runtime/threads/ThreadInterruptTest3 fails with ExitCode 0 Summary: Added new hashtables logging tag and used it print out the table performance details. Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/packageEntry.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 2a2b71f87249 Author: psandoz Date: 2016-10-14 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2a2b71f87249 8166974: invokedynamic implementation should not wrap Errors Reviewed-by: dholmes, jrose ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! test/runtime/ConstantPool/TestMethodHandleConstant.java ! test/runtime/invokedynamic/BootstrapMethodErrorTest.java Changeset: 2839c246aa76 Author: sla Date: 2016-10-28 08:40 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2839c246aa76 8168305: GC.class_stats should not require -XX:+UnlockDiagnosticVMOptions Reviewed-by: rehn, mlarsson, iklam ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! test/serviceability/sa/TestInstanceKlassSize.java ! test/serviceability/sa/TestInstanceKlassSizeForInterface.java Changeset: 308a53dd5aee Author: kvn Date: 2016-10-28 12:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/308a53dd5aee 8067744: XMM/SSE float register values corrupted by JNI_CreateVM call in JRE 8 (Windows) Summary: save/restore registers in generate_get_cpu_info() code which checks interrupts. Reviewed-by: kvn, mcberg Contributed-by: dmitry.chuyko at oracle.com ! make/test/JtregNative.gmk ! src/cpu/x86/vm/vm_version_x86.cpp + test/runtime/jni/CalleeSavedRegisters/FPRegs.java + test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c Changeset: 11c368034e2b Author: kvn Date: 2016-10-28 19:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/11c368034e2b Merge Changeset: 276657e0e3b4 Author: thartmann Date: 2016-10-31 09:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/276657e0e3b4 8168770: Fix for 8151988 causes performance regression on SPARC Summary: Reversed and re-implemented fix for 8151988 to eagerly cut off control input of Div and Mod nodes. Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/divnode.cpp Changeset: 52bc6603d080 Author: dnsimon Date: 2016-10-29 01:09 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52bc6603d080 8168915: [JVMCI] use MethodParameters attribute instead of depending on -g option for sanity checks Reviewed-by: kvn ! 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.meta/src/jdk/vm/ci/meta/ResolvedJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java Changeset: c09080eab7ac Author: roland Date: 2016-10-13 12:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c09080eab7ac 8167298: assert(tp->base() != Type::AnyPtr) crash with Unsafe.compareAndExchangeObject* Summary: Unsafe.compareAndExchangeObject should keep track of returned type after matching Reviewed-by: shade, vlivanov ! src/share/vm/adlc/formssel.cpp + test/compiler/intrinsics/unsafe/TestCAEAntiDep.java Changeset: dab623e5a387 Author: roland Date: 2016-10-10 17:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dab623e5a387 8167300: Scheduling failures during gcm should be fatal Reviewed-by: kvn, mcberg ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 916006f85f92 Author: goetz Date: 2016-10-19 11:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/916006f85f92 8168283: adlc: fix error expanding expanded nodes. Reviewed-by: kvn ! src/share/vm/adlc/output_c.cpp Changeset: 9ea71fc781fe Author: mchernov Date: 2016-10-31 18:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ea71fc781fe 8168535: Quarantine GcCauseTest02 and GcTest02 Reviewed-by: jwilhelm, sjohanss ! test/serviceability/tmtools/jstat/GcCauseTest02.java ! test/serviceability/tmtools/jstat/GcTest02.java Changeset: d3a54fa06ec2 Author: mchernov Date: 2016-10-31 17:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d3a54fa06ec2 Merge Changeset: 6996f14f9d02 Author: zmajo Date: 2016-11-01 09:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6996f14f9d02 8167578: C1: compiler.escapeAnalysis.TestArrayCopy fails to throw ArrayStoreException Summary: Remove code that causes C1's arraycopy to skip type checks if the length argument is 0 Reviewed-by: kvn ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Changeset: 031e87605d21 Author: simonis Date: 2016-10-06 18:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/031e87605d21 8159611: C2: ArrayCopy elimination skips required parameter checks Reviewed-by: kvn, zmajo, thartmann ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/opto/arraycopynode.cpp ! src/share/vm/opto/arraycopynode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macroArrayCopy.cpp + test/compiler/escapeAnalysis/TestArrayCopy.java Changeset: 8c2f220c759c Author: vtewari Date: 2016-11-03 11:53 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c2f220c759c 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure Summary: Do the special handling for invokedynamic bytecodes while printing out the bytecodes in a method Reviewed-by: dsamersoff, sundar Contributed-by: jini.george at oracle.com ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/BytecodeInvoke.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java + test/serviceability/sa/LingeredAppWithInvokeDynamic.java + test/serviceability/sa/TestCpoolForInvokeDynamic.java Changeset: 246f6fb74bf1 Author: bobv Date: 2016-11-03 10:44 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/246f6fb74bf1 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems Reviewed-by: dcubed ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 9c41df0356bc Author: jwilhelm Date: 2016-11-11 16:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9c41df0356bc Merge - src/share/vm/utilities/quickSort.cpp - test/compiler/ciReplay/TestSA.sh - test/compiler/ciReplay/TestVM.sh - test/compiler/ciReplay/TestVM_no_comp_level.sh - test/compiler/ciReplay/common.sh Changeset: 5a574ef5a4ee Author: jwilhelm Date: 2016-11-11 16:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5a574ef5a4ee 8169597: Quarantine TestCpoolForInvokeDynamic.java until JDK-8169232 is solved Reviewed-by: egahlin, gtriantafill ! test/serviceability/sa/TestCpoolForInvokeDynamic.java Changeset: a82cb5350cad Author: lana Date: 2016-11-21 18:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a82cb5350cad Merge Changeset: 1ae8e92ed3e4 Author: lana Date: 2016-11-23 16:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ae8e92ed3e4 Added tag jdk-9+146 for changeset a82cb5350cad ! .hgtags Changeset: e11ce1266692 Author: alanb Date: 2016-11-24 13:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e11ce1266692 Merge ! .hgtags ! make/lib/Lib-jdk.hotspot.agent.gmk ! make/test/JtregNative.gmk ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h ! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/BytecodeInvoke.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/jdk.hotspot.agent/solaris/native/libsaproc/libproc.h ! src/jdk.hotspot.agent/solaris/native/libsaproc/salibproc.h ! src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp ! src/os/aix/vm/os_aix.cpp ! 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/dictionary.cpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/packageEntry.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/frame.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/services/management.cpp ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/utilities/hashtable.hpp - src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! test/TEST.ROOT - test/compiler/ciReplay/TestSA.sh - test/compiler/ciReplay/TestVM.sh - test/compiler/ciReplay/TestVM_no_comp_level.sh - test/compiler/ciReplay/common.sh ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/gc/g1/TestHumongousShrinkHeap.java ! test/runtime/SharedArchiveFile/SASymbolTableTest.java ! test/serviceability/jdwp/AllModulesCommandTest.java ! test/serviceability/sa/TestInstanceKlassSize.java ! test/serviceability/sa/TestInstanceKlassSizeForInterface.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Changeset: 7de2c2ff2628 Author: alanb Date: 2016-11-24 13:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7de2c2ff2628 Liberate AllModulesCommandTest ! test/serviceability/jdwp/AllModulesCommandTest.java From snicoll at pivotal.io Thu Nov 24 14:22:29 2016 From: snicoll at pivotal.io (=?UTF-8?Q?St=C3=A9phane_Nicoll?=) Date: Thu, 24 Nov 2016 23:22:29 +0900 Subject: Replacement for JDK8 APIs Message-ID: Hi, I am working on the Spring Boot project[1] and I am trying to make sure our codebase compiles with the current JDK9 build[2]. So far I've hit two major issues: We use "sun.misc.VMSupport" to retrieve the port being used by the Java remote debugging. You can find the actual code in RemoteDebugPortProvider[3] We have an annotation processor that inspects all classes annotated with @ConfigurationProperties and generates some meta-data about them. One important piece of this is to extract the default value assigned to fields. Consider the following example @ConfigurationProperties public class Foo { private static final String DEFAULT_NAME = "name"; private String name = DEFAULT_NAME; private Integer counter = 42; private List hosts = Collections.singletonList("localhost"); } What we've build is a visitor that navigates to those elements and extracts the default values assigned to each field, including navigating to parent element (the "name" constant there) or inferring value from method parameters ("localhost"). The current code relies on a feature of the JDK that is no longer exported[4]: java.lang.IllegalAccessException: class org.springframework.boot.configurationprocessor.fieldvalues.javac.Trees cannot access class com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.api to unnamed module @5a7fe64 Does anybody has some insight as how we could migrate those two use cases? In particular, the second use case could be implemented with a contract of javax.lang.model but we haven't found how to do it. Thank you, S. [1] https://github.com/spring-projects/spring-boot [2] https://github.com/spring-projects/spring-boot/issues/7226 [3] https://github.com/spring-projects/spring-boot/blob/master/spring-boot-devtools/src/main/java/org/springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java [4] https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Trees.java From forax at univ-mlv.fr Thu Nov 24 14:39:19 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 24 Nov 2016 15:39:19 +0100 (CET) Subject: modules and tests In-Reply-To: <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> Message-ID: <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Sander Mak" > ?: "jigsaw-dev" > Envoy?: Jeudi 24 Novembre 2016 14:44:08 > Objet: Re: modules and tests >> On 24 Nov 2016, at 14:31, Alan Bateman >> > wrote: >> >> On 24/11/2016 08:46, Remi Forax wrote: >> >> : >> >> It's not obvious at it seems, it requires javac to be able to merge several >> module-info.java into one, and because the module descriptor allows to restrict >> exports or opens, the merging rules* as to be specified. >> >> Have you run into anything that isn't solved by compiling with -Xmodule: >> and/or specify --add-reads and --add-exports to augment the module declaration? >> I realize it's awkward to specify these options but in time then I would expect >> the build tools and test runners to make this a lot easier. > > For a concrete example of this: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006594.html > (modulo the old-style flags). Later I ported the same example to the a Maven > build, which takes care of all this setup under the hood. Worked fine, without > having to fiddle with -Xmodule/-Xpatch and readability to test-scope > dependencies happens automatically in that case. > > > Sander to Alan: currently you can not get your test framework as a service and you can not declare your test as a provider for a test infrastructure like jenkins (i.e. there is no --uses and --provides). to Alan and Sander: setting command line arguments or using a build tool to fiddle them for you is exactly what we do not want here! We want fidelity between the compile time configuration and the runtime configuration. Having to play with -Xpatch at runtime is conceptually exactly like setting the classpath. I don't want to explain to the Java devs that we have fidelity between compile-time and runtime on source code but not on test code. regards, R?mi From Alan.Bateman at oracle.com Thu Nov 24 15:25:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2016 15:25:20 +0000 Subject: Code review for jigsaw/jake -> jdk9/dev sync up Message-ID: <6da3ac71-ca2b-3284-576d-055c19a65521@oracle.com> Folks on jigsaw-dev will know that we are on a mission to bring the changes accumulated in the jake forest to jdk9/dev. We can think of this as a refresh of the module system in JDK 9, the last big refresh was in May with many small updates since then. The focus this time is to bring the changes that are tied to JSR issues into jdk9/dev, specifically the issues that are tracked on the JSR issues list [1] as: #CompileTimeDependences #AddExportsInManifest #ClassFileModuleName #ClassFileAccPublic #ServiceLoaderEnhancements #ResourceEncapsulation/#ClassFilesAsResources #ReflectiveAccessToNonExportedTypes #AwkwardStrongEncapsulation #ReadabilityAddedByLayerCreator #IndirectQualifiedReflectiveAccess (partial) #VersionsInModuleNames #NonHierarchicalLayers #ModuleAnnotations/#ModuleDeprecation #ReflectiveAccessByInstrumentationAgents Some of these issues are not "Resolved" yet, meaning there is still ongoing discussion on the EG mailing list. That is okay, there is nothing final here. If there are changes to these proposals then the implementation changes will follow. Also, as I said in a mail to jigsaw-dev yesterday [2], is that we will keep the jake forest open for ongoing prototyping and iteration, also ongoing implementation improvements where iteration or bake time is important. For the code review then the focus is therefore on sanity checking the changes that we would like to bring into jdk9/dev. We will not use this review thread to debate alternative designs or other big implementation changes that are more appropriate to bake in jake. To get going, I've put the webrevs with a snapshot of the changes in jake here: http://cr.openjdk.java.net/~alanb/8169069/0/ The changes are currently sync'ed against jdk-9+146 and will be rebased (and re-tested) against jdk9/dev prior to integration. There are a number of small changes that need to be added to this in the coming days, I will refresh the webrev every few days to take account of these updates. A few important points to mention, even if you aren't reviewing the changes: 1. This refresh requires a new version of jtreg to run the tests. The changes for this new version are in the code-tools/jtreg repository and the plan is to tag a new build (jtreg4.2-b04) next week. Once the tag has been added then we'll update the requiredVersion property in each TEST.ROOT to force everyone to update. 2. For developers trying out modules with the main line JDK 9 builds then be aware that `requires public` changes to `requires transitive` and the `provides` clause changes to require all providers for a specific service type to be in the same clause. Also be aware that the binary form of the module declaration (module-info.class) changes so you will need to recompile any modules. 3. Those running existing code on JDK 9 and ignoring modules will need to be aware of a disruptive change in this refresh. The disruptive change is #AwkwardStrongEncapsulation where setAccessible(true) is changed so that it can't be used to break into non-public fields/methods of JDK classes. This change is going to expose a lot of hacks in existing code. We plan to send mail to jdk9-dev in advance of this integration to create awareness of this change. As per the original introduction of strong encapsulation then command line options (and now the manifest of application JAR files) can be used to keep existing code working. The new option is `--add-opens` to open a package in a module for deep reflection by other modules. As an example, if you find yourself with code that hacks into the private `comparator` field in java.util.TreeMap then running with `--add-opens java.base/java.util=ALL-UNNAMED` will keep that code working. A few miscellaneous notes for those that are reviewing: 1. We have some temporary/transition code in the top-level repo to deal with the importing of the JavaFX modules. This will be removed once the changes are in JDK 9 for the OpenJFX project to use. 2. In the jdk repo then it's important to understand that the module system is initialized at startup and there are many places where we need to keep startup performance in mind. This sometimes means less elegant code than might be used if startup wasn't such a big concern. 3. The changes in the jaxws repo make use of new APIs that means the code doesn't compile with JDK 7 or JDK 8. Our intention is to work with the JAXB and JAX-WS maintainers to address the issues in the upstream project and then bring those changes into jdk9/dev to replace the patches that we are forced to push for the short term. 4. You will see several tests where the value of the @modules tag has `:open` or `:+open`. This is new jtreg speak. The former means the test is run with --add-opens to open the package, the latter means the test is exported at compile-time and exported + open at run-time (the latter usage will be rare, it's where tests have static references to JDK internal types and are also doing deep reflection with setAccessible). In terms of dates then we are aiming to integrate these changes into jdk9/dev in early December. I will send a follow-up mail next week on this as we work through the logistics. -Alan [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010219.html From Alan.Bateman at oracle.com Thu Nov 24 15:41:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2016 15:41:03 +0000 Subject: modules and tests In-Reply-To: <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> Message-ID: On 24/11/2016 14:39, Remi Forax wrote: > : > to Alan: > currently you can not get your test framework as a service and you can not declare your test as a provider for a test infrastructure like jenkins (i.e. there is no --uses and --provides). Fair point, uses/provides can't currently be augmented via the command-line but this is only because it hasn't been needed. > > to Alan and Sander: > setting command line arguments or using a build tool to fiddle them for you is exactly what we do not want here! We want fidelity between the compile time configuration and the runtime configuration. Having to play with -Xpatch at runtime is conceptually exactly like setting the classpath. I don't want to explain to the Java devs that we have fidelity between compile-time and runtime on source code but not on test code. > I hope in time that there will be support from the tools, plugins, test runners ... so that regular developers don't need to be concerned with this. -Alan From alan.bateman at oracle.com Thu Nov 24 16:19:37 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Nov 2016 16:19:37 +0000 Subject: hg: jigsaw/jake/jdk: Fixed typos in javadoc Message-ID: <201611241619.uAOGJbfk025667@aojmv0008.oracle.com> Changeset: 09b3083d7de2 Author: alanb Date: 2016-11-24 16:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/09b3083d7de2 Fixed typos in javadoc ! src/java.base/share/classes/java/util/ServiceLoader.java From blackdrag at gmx.org Thu Nov 24 16:35:54 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 24 Nov 2016 17:35:54 +0100 Subject: modules and tests In-Reply-To: References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> Message-ID: <309fbf53-3563-6a25-db95-2aa6210ade43@gmx.org> On 24.11.2016 16:41, Alan Bateman wrote: [...] >> to Alan and Sander: >> setting command line arguments or using a build tool to fiddle them >> for you is exactly what we do not want here! We want fidelity between >> the compile time configuration and the runtime configuration. Having >> to play with -Xpatch at runtime is conceptually exactly like setting >> the classpath. I don't want to explain to the Java devs that we have >> fidelity between compile-time and runtime on source code but not on >> test code. >> > I hope in time that there will be support from the tools, plugins, test > runners ... so that regular developers don't need to be concerned with > this. I don't understand why it is better if a tool does -Xpatch, than when I do it myself. Anything else will require several classes be loaded that will change how the modules work and influence the tests with their present and their dependencies bye Jochen From Alan.Bateman at oracle.com Thu Nov 24 18:14:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2016 18:14:40 +0000 Subject: Replacement for JDK8 APIs In-Reply-To: References: Message-ID: <84ee2ec3-afc8-fca5-77ef-46e8b3f28b7a@oracle.com> On 24/11/2016 14:22, St?phane Nicoll wrote: > : > > We use "sun.misc.VMSupport" to retrieve the port being used by the Java > remote debugging. You can find the actual code in RemoteDebugPortProvider[3] > This class was never intended to be used directly of course. It doesn't exist (or rather it has moved) in JDK 9. Are you grabbing the port so that it can be published for debuggers to attach? Have you considered publishing the pid instead - that would allow debuggers to use the ProcessAttachingConnector to attach. -Alan From mandy.chung at oracle.com Thu Nov 24 21:51:27 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 24 Nov 2016 21:51:27 +0000 Subject: hg: jigsaw/jake/jdk: jar tool to handle entries with META-INF/versions path Message-ID: <201611242151.uAOLpSHJ005772@aojmv0008.oracle.com> Changeset: c0170badab7d Author: mchung Date: 2016-11-24 13:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c0170badab7d jar tool to handle entries with META-INF/versions path ! src/java.base/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 + test/tools/jar/multiRelease/Basic1.java From mandy.chung at oracle.com Fri Nov 25 06:33:29 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 25 Nov 2016 06:33:29 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201611250633.uAP6XTFd021828@aojmv0008.oracle.com> Changeset: e1d07d9c9e64 Author: mchung Date: 2016-11-24 22:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e1d07d9c9e64 Remove temporary copying of copyright/license to jmod ! make/copy/Copy-java.base.gmk ! make/copy/CopyCommon.gmk Changeset: 673f6b89cd09 Author: mchung Date: 2016-11-24 22:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/673f6b89cd09 Clean up jlink system module plugin code ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ResourcePoolEntry.java Changeset: b20b41370415 Author: mchung Date: 2016-11-24 22:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b20b41370415 --list-modules to print automatic module ! src/java.base/share/classes/sun/launcher/LauncherHelper.java From rfscholte at apache.org Fri Nov 25 10:48:37 2016 From: rfscholte at apache.org (Robert Scholte) Date: Fri, 25 Nov 2016 11:48:37 +0100 Subject: modules and tests In-Reply-To: <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> Message-ID: On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax wrote: > setting command line arguments or using a build tool to fiddle them for > you is exactly what we do not want here! We want fidelity between the > compile time configuration and the runtime configuration. Having to play > with -Xpatch at runtime is conceptually exactly like setting the > classpath. I don't want to explain to the Java devs that we have > fidelity between compile-time and runtime on source code but not on test > code. I agree on this one. I've been thinking about this a lot and I'm wondering if this is a Java issue or test-tool issue. What I see with JUnit is that everything is added to the (class)path. I've been wondering if having separate arguments for the main classes and test classes would make it possible to prevent the patch argument while chaining classloaders. e.g. java -jar junit.jar -DmainPath= -DtestPath= ... in Maven terms: mainPath will contain all compile-dependencies, testPath will contain all test-dependencies WITHOUT the compile-dependencies. However, is this enough to support split packages? Robert From snicoll at pivotal.io Fri Nov 25 12:11:26 2016 From: snicoll at pivotal.io (=?UTF-8?Q?St=C3=A9phane_Nicoll?=) Date: Fri, 25 Nov 2016 21:11:26 +0900 Subject: Replacement for JDK8 APIs In-Reply-To: <84ee2ec3-afc8-fca5-77ef-46e8b3f28b7a@oracle.com> References: <84ee2ec3-afc8-fca5-77ef-46e8b3f28b7a@oracle.com> Message-ID: On Fri, Nov 25, 2016 at 3:14 AM, Alan Bateman wrote: > On 24/11/2016 14:22, St?phane Nicoll wrote: > > : >> >> We use "sun.misc.VMSupport" to retrieve the port being used by the Java >> remote debugging. You can find the actual code in >> RemoteDebugPortProvider[3] >> >> This class was never intended to be used directly of course. It doesn't > exist (or rather it has moved) in JDK 9. Are you grabbing the port so that > it can be published for debuggers to attach? Have you considered publishing > the pid instead - that would allow debuggers to use the > ProcessAttachingConnector to attach. Yes, there is a feature in Spring Boot called devtools that allows you do remote debugging via SSH[1] - Is there any way to achieve the same feature with JDK 9? Thanks, S. [1] http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-devtools-remote-debugtunnel > > > -Alan > From eirbjo at gmail.com Fri Nov 25 12:37:01 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 25 Nov 2016 13:37:01 +0100 Subject: Replacement for JDK8 APIs In-Reply-To: References: <84ee2ec3-afc8-fca5-77ef-46e8b3f28b7a@oracle.com> Message-ID: St?phane, Could you inspect the JVM command line and parse the debugging agent options? Eirik. On Fri, Nov 25, 2016 at 1:11 PM, St?phane Nicoll wrote: > On Fri, Nov 25, 2016 at 3:14 AM, Alan Bateman > wrote: > > > On 24/11/2016 14:22, St?phane Nicoll wrote: > > > > : > >> > >> We use "sun.misc.VMSupport" to retrieve the port being used by the Java > >> remote debugging. You can find the actual code in > >> RemoteDebugPortProvider[3] > >> > >> This class was never intended to be used directly of course. It doesn't > > exist (or rather it has moved) in JDK 9. Are you grabbing the port so > that > > it can be published for debuggers to attach? Have you considered > publishing > > the pid instead - that would allow debuggers to use the > > ProcessAttachingConnector to attach. > > > Yes, there is a feature in Spring Boot called devtools that allows you do > remote debugging via SSH[1] - Is there any way to achieve the same feature > with JDK 9? > > Thanks, > S. > > [1] > http://docs.spring.io/spring-boot/docs/current/reference/ > htmlsingle/#using-boot-devtools-remote-debugtunnel > > > > > > > > -Alan > > > From eirbjo at gmail.com Fri Nov 25 12:40:23 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 25 Nov 2016 13:40:23 +0100 Subject: Replacement for JDK8 APIs In-Reply-To: References: <84ee2ec3-afc8-fca5-77ef-46e8b3f28b7a@oracle.com> Message-ID: Except that wouldn't work with random ports.. Eirik. On Fri, Nov 25, 2016 at 1:37 PM, Eirik Bj?rsn?s wrote: > > > St?phane, > > Could you inspect the JVM command line and parse the debugging agent > options? > > Eirik. > > On Fri, Nov 25, 2016 at 1:11 PM, St?phane Nicoll > wrote: > >> On Fri, Nov 25, 2016 at 3:14 AM, Alan Bateman >> wrote: >> >> > On 24/11/2016 14:22, St?phane Nicoll wrote: >> > >> > : >> >> >> >> We use "sun.misc.VMSupport" to retrieve the port being used by the Java >> >> remote debugging. You can find the actual code in >> >> RemoteDebugPortProvider[3] >> >> >> >> This class was never intended to be used directly of course. It doesn't >> > exist (or rather it has moved) in JDK 9. Are you grabbing the port so >> that >> > it can be published for debuggers to attach? Have you considered >> publishing >> > the pid instead - that would allow debuggers to use the >> > ProcessAttachingConnector to attach. >> >> >> Yes, there is a feature in Spring Boot called devtools that allows you do >> remote debugging via SSH[1] - Is there any way to achieve the same feature >> with JDK 9? >> >> Thanks, >> S. >> >> [1] >> http://docs.spring.io/spring-boot/docs/current/reference/htm >> lsingle/#using-boot-devtools-remote-debugtunnel >> >> >> > >> > >> > -Alan >> > >> > > From Alan.Bateman at oracle.com Fri Nov 25 12:49:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2016 12:49:24 +0000 Subject: Replacement for JDK8 APIs In-Reply-To: References: <84ee2ec3-afc8-fca5-77ef-46e8b3f28b7a@oracle.com> Message-ID: On 25/11/2016 12:11, St?phane Nicoll wrote: > : > > Yes, there is a feature in Spring Boot called devtools that allows you > do remote debugging via SSH[1] - Is there any way to achieve the same > feature with JDK 9? > Nothing has really changed here, it's just that some JDK internal classes have moved and of course they are no longer accessible. So if understand correctly then you want the debugger agent to create a listener on an ephemeral port when started over ssh. That should work fine and the listener port will be printed to stdout (and hence sent over the ssh session) so that the user can connect with the socket transport. The alternative is of course to invert the setup so that the user starts the debugger configured to use a ListeningConnector and have the debuggee started with the `address` sub-option specifying the host/port of the debugger to connect to (no server=y). If there isn't a solution then serviceability-dev would be a good place to bring up this topic as there has never been a supported way to publish the debugger port (the sun.jdwp.listenerAddress property is for the ProcessAttachingConnector). -Alan From forax at univ-mlv.fr Fri Nov 25 15:23:56 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 25 Nov 2016 16:23:56 +0100 (CET) Subject: modules and tests In-Reply-To: References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> Message-ID: <323196414.2369410.1480087436978.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "Sander Mak" > Cc: "jigsaw-dev" > Envoy?: Jeudi 24 Novembre 2016 16:41:03 > Objet: Re: modules and tests > On 24/11/2016 14:39, Remi Forax wrote: >> : >> to Alan: >> currently you can not get your test framework as a service and you can not >> declare your test as a provider for a test infrastructure like jenkins (i.e. >> there is no --uses and --provides). > Fair point, uses/provides can't currently be augmented via the > command-line but this is only because it hasn't been needed. maybe, (it's a rhetorical maybe), instead of sending all the directives of the module descriptor as command line arguments, a simpler solution is to use a module descriptor ... > >> >> to Alan and Sander: >> setting command line arguments or using a build tool to fiddle them for you is >> exactly what we do not want here! We want fidelity between the compile time >> configuration and the runtime configuration. Having to play with -Xpatch at >> runtime is conceptually exactly like setting the classpath. I don't want to >> explain to the Java devs that we have fidelity between compile-time and runtime >> on source code but not on test code. >> > I hope in time that there will be support from the tools, plugins, test > runners ... so that regular developers don't need to be concerned with this. Let me try to summarize this issue, because javac doesn't merge module descriptors, the recommended solution is to use some javac command line options and the corresponding java options. These options were first introduced to ease the transition from the classpath world to modulepath world but you want to re-target them to make them part of the whole jigsaw experience. For build tools like Maven or Gradle, they do not need to use these java options because they can merge the module descriptors because they control the compilation and the execution of the tests. For other tools, because they only see part of the process, either the compilation or the execution of the tests, people will have to send the options by hands or as Jochen has suggested, for test runners, you can create a Layer and programmatically do what the options does but it change the environment and you still have to know the test configuration one way or the other. Instead of waiting for tools to cope, i think it's far easier to change javac (one tool) to restore the semantics that exists before the introduction of jigsaw which is that you can have two folders one for the source and one for the test and it just works. > > -Alan R?mi From russell.gold at oracle.com Fri Nov 25 16:15:44 2016 From: russell.gold at oracle.com (Russell Gold) Date: Fri, 25 Nov 2016 11:15:44 -0500 Subject: modules and tests In-Reply-To: References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> Message-ID: <0BC9B399-955B-4C09-A909-390C5FB0CE32@oracle.com> If you are doing unit testing, all you presumably care about is the classes themselves; not the configuration. I would think that tests which care about configuration - including what classes are accessible - is properly a functional test. So, why not simply handle unit tests, as you say, with everything on the class path - and then also do functional tests with those tests in a separate package so that they are subject to the same access rules that any outside code would experience? We want unit tests in the same package as the code they are testing, not only to make the correspondences clear, but also so that we can access package-private class members, but that isn?t the case for functional tests. Russ > On Nov 25, 2016, at 5:48 AM, Robert Scholte wrote: > > On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax wrote: > >> setting command line arguments or using a build tool to fiddle them for you is exactly what we do not want here! We want fidelity between the compile time configuration and the runtime configuration. Having to play with -Xpatch at runtime is conceptually exactly like setting the classpath. I don't want to explain to the Java devs that we have fidelity between compile-time and runtime on source code but not on test code. > > I agree on this one. I've been thinking about this a lot and I'm wondering if this is a Java issue or test-tool issue. > What I see with JUnit is that everything is added to the (class)path. I've been wondering if having separate arguments for the main classes and test classes would make it possible to prevent the patch argument while chaining classloaders. > e.g. java -jar junit.jar -DmainPath= -DtestPath= ... > > in Maven terms: mainPath will contain all compile-dependencies, testPath will contain all test-dependencies WITHOUT the compile-dependencies. > > However, is this enough to support split packages? > > Robert From forax at univ-mlv.fr Fri Nov 25 18:56:06 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 25 Nov 2016 19:56:06 +0100 (CET) Subject: modules and tests In-Reply-To: <0BC9B399-955B-4C09-A909-390C5FB0CE32@oracle.com> References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> <0BC9B399-955B-4C09-A909-390C5FB0CE32@oracle.com> Message-ID: <1556129523.2445076.1480100166838.JavaMail.zimbra@u-pem.fr> Hi Russel, part of the code i test use Layers and annotations on Modules, it just doesn't work with in a non module environment :( regards, R?mi > De: "Russell Gold" > ?: "jigsaw-dev" > Cc: "Robert Scholte" , "Sander Mak" > , "Remi Forax" > Envoy?: Vendredi 25 Novembre 2016 17:15:44 > Objet: Re: modules and tests > If you are doing unit testing, all you presumably care about is the classes > themselves; not the configuration. I would think that tests which care about > configuration - including what classes are accessible - is properly a > functional test. > So, why not simply handle unit tests, as you say, with everything on the class > path - and then also do functional tests with those tests in a separate package > so that they are subject to the same access rules that any outside code would > experience? We want unit tests in the same package as the code they are > testing, not only to make the correspondences clear, but also so that we can > access package-private class members, but that isn?t the case for functional > tests. > Russ >> On Nov 25, 2016, at 5:48 AM, Robert Scholte < rfscholte at apache.org > wrote: >> On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax < forax at univ-mlv.fr > wrote: >>> setting command line arguments or using a build tool to fiddle them for you is >>> exactly what we do not want here! We want fidelity between the compile time >>> configuration and the runtime configuration. Having to play with -Xpatch at >>> runtime is conceptually exactly like setting the classpath. I don't want to >>> explain to the Java devs that we have fidelity between compile-time and runtime >>> on source code but not on test code. >> I agree on this one. I've been thinking about this a lot and I'm wondering if >> this is a Java issue or test-tool issue. >> What I see with JUnit is that everything is added to the (class)path. I've been >> wondering if having separate arguments for the main classes and test classes >> would make it possible to prevent the patch argument while chaining >> classloaders. >> e.g. java -jar junit.jar -DmainPath= -DtestPath= ... >> in Maven terms: mainPath will contain all compile-dependencies, testPath will >> contain all test-dependencies WITHOUT the compile-dependencies. >> However, is this enough to support split packages? >> Robert From forax at univ-mlv.fr Fri Nov 25 19:12:39 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 25 Nov 2016 20:12:39 +0100 (CET) Subject: modules and tests In-Reply-To: References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> Message-ID: <1431839283.2447532.1480101159172.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Robert Scholte" > ?: "Sander Mak" , "Remi Forax" > Cc: "jigsaw-dev" > Envoy?: Vendredi 25 Novembre 2016 11:48:37 > Objet: Re: modules and tests > On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax wrote: > >> setting command line arguments or using a build tool to fiddle them for >> you is exactly what we do not want here! We want fidelity between the >> compile time configuration and the runtime configuration. Having to play >> with -Xpatch at runtime is conceptually exactly like setting the >> classpath. I don't want to explain to the Java devs that we have >> fidelity between compile-time and runtime on source code but not on test >> code. > > I agree on this one. I've been thinking about this a lot and I'm wondering > if this is a Java issue or test-tool issue. > What I see with JUnit is that everything is added to the (class)path. I've > been wondering if having separate arguments for the main classes and test > classes would make it possible to prevent the patch argument while > chaining classloaders. > e.g. java -jar junit.jar -DmainPath= -DtestPath= ... > > in Maven terms: mainPath will contain all compile-dependencies, testPath > will contain all test-dependencies WITHOUT the compile-dependencies. > > However, is this enough to support split packages? Technically, having a source folder and a test folder is not a split packages case, because everything goes in the same module at the end. What i've done is creating two artifacts, one modular jar with only the source code and one modular jar that contains the source code and the test code, they are stored in two different folders, target/src/artifact and target/test/artifact. Both jars do not have the samefile name (test modular jar are prefixed by test to avoid to use them in production) but both define the same module name. The requires directives all the requires directive of the source modular jar merged with the one of the test modular jar (like JUnit). All dependencies (comp?le-dependencies and test-dependencies) are stored in the same folder, because the VM pick the right modules using the requires directives. At runtime, my test runner creates a new layer, with 3 module finders, the first one only find the test module i want to test (so i do the test of each module in isolation and not all test modules altogether), the second one contains the modular jars from the sources and the last one resolve all external dependencies. > > Robert R?mi From webczat_200 at poczta.onet.pl Fri Nov 25 19:33:53 2016 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Fri, 25 Nov 2016 20:33:53 +0100 Subject: Few questions Message-ID: Hello. I have a few questions about project jigsaw and things that are related. - Does, or will, the jlink tool allow creating executables? I mean, packing app with the runtime not in a directory, but in an executable file of some sort? Or, will it be extendable in such a direction? Some people would like something similar, although such an exe would be really big. - Is it possible to, in any way, circumvent module access control? Reflection works to see, currently, all classes and interfaces, all methods/fields/constructors of theirs whether private, protected or whatever, and may be used to circumvent all such access restrictions. What about deliberate circumventing of access from one module to another, when an accessed class would be from a package that is not exported? How does it all work with serialization? - And, what about module unloading? From what I know, classes are never unloaded, unless they have no active references to any of their objects and class object/etc, and unless their class loader is collectable, that requires all other classes not to be referenced/etc. How does this extend to modules? When modules are unloaded? - How to dynamically load modules? Does it require a new layer to be created? Can you base a layer you create directly on the empty layer? for example to run an app in a different environment, isolated from most of the modules of another app... - Probably the last question: are security providers per module/layer, or per java virtual machine? Sometimes it at least seems useful for two... javaee apps to have two versions of bouncycastle jcajce provider running without conflict. From russell.gold at oracle.com Fri Nov 25 19:58:19 2016 From: russell.gold at oracle.com (Russell Gold) Date: Fri, 25 Nov 2016 14:58:19 -0500 Subject: modules and tests In-Reply-To: <1556129523.2445076.1480100166838.JavaMail.zimbra@u-pem.fr> References: <1210354730.1732532.1479977189553.JavaMail.zimbra@u-pem.fr> <22e26ba0-e8cf-74c3-10af-395678a891e4@oracle.com> <6ACA77A5-13F7-40F0-9A28-5C940B7DECC6@luminis.eu> <2030534008.1912952.1479998359807.JavaMail.zimbra@u-pem.fr> <0BC9B399-955B-4C09-A909-390C5FB0CE32@oracle.com> <1556129523.2445076.1480100166838.JavaMail.zimbra@u-pem.fr> Message-ID: <50D79EBB-505F-40F7-8EE3-C903D781E37C@oracle.com> In which case, your tests need to be from code *outside* the modules, right? So logically, since code that uses a module from the outside must be in other packages, it makes the most sense for your tests to be, as well. > On Nov 25, 2016, at 1:56 PM, forax at univ-mlv.fr wrote: > > Hi Russel, > part of the code i test use Layers and annotations on Modules, it just doesn't work with in a non module environment :( > > regards, > R?mi > > De: "Russell Gold" > ?: "jigsaw-dev" > Cc: "Robert Scholte" , "Sander Mak" , "Remi Forax" > Envoy?: Vendredi 25 Novembre 2016 17:15:44 > Objet: Re: modules and tests > If you are doing unit testing, all you presumably care about is the classes themselves; not the configuration. I would think that tests which care about configuration - including what classes are accessible - is properly a functional test. > > So, why not simply handle unit tests, as you say, with everything on the class path - and then also do functional tests with those tests in a separate package so that they are subject to the same access rules that any outside code would experience? We want unit tests in the same package as the code they are testing, not only to make the correspondences clear, but also so that we can access package-private class members, but that isn?t the case for functional tests. > > Russ > > On Nov 25, 2016, at 5:48 AM, Robert Scholte > wrote: > > On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax > wrote: > > setting command line arguments or using a build tool to fiddle them for you is exactly what we do not want here! We want fidelity between the compile time configuration and the runtime configuration. Having to play with -Xpatch at runtime is conceptually exactly like setting the classpath. I don't want to explain to the Java devs that we have fidelity between compile-time and runtime on source code but not on test code. > > I agree on this one. I've been thinking about this a lot and I'm wondering if this is a Java issue or test-tool issue. > What I see with JUnit is that everything is added to the (class)path. I've been wondering if having separate arguments for the main classes and test classes would make it possible to prevent the patch argument while chaining classloaders. > e.g. java -jar junit.jar -DmainPath= -DtestPath= ... > > in Maven terms: mainPath will contain all compile-dependencies, testPath will contain all test-dependencies WITHOUT the compile-dependencies. > > However, is this enough to support split packages? > > Robert > > From Alan.Bateman at oracle.com Fri Nov 25 22:05:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2016 22:05:00 +0000 Subject: Few questions In-Reply-To: References: Message-ID: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> On 25/11/2016 19:33, Micha? Zegan wrote: > Hello. > > I have a few questions about project jigsaw and things that are related. > > - Does, or will, the jlink tool allow creating executables? I mean, > packing app with the runtime not in a directory, but in an executable > file of some sort? Or, will it be extendable in such a direction? Some > people would like something similar, although such an exe would be > really big. jlink creates a run-time image so it's not a single .exe file. The details on the run-time image layout are in JEP 220 but might be easier to just try it out to see how it works. There are lots of opportunities to do static linking and other things but they beyond the current scope of JEP 282 and JEP 275. > - Is it possible to, in any way, circumvent module access control? > Reflection works to see, currently, all classes and interfaces, all > methods/fields/constructors of theirs whether private, protected or > whatever, and may be used to circumvent all such access restrictions. > What about deliberate circumventing of access from one module to > another, when an accessed class would be from a package that is not > exported? All places that do access checks have been updated to work with modules. In the case of core reflection then you can discover private fields and methods that aren't accessible so it's not really any different to how core reflection has always worked (ignoring setAccessible). > How does it all work with serialization? Java serialization works exactly as before, no changes. Custom serialization on the other hand is a challenge. There are specialized APIs in the jdk.unsupported module to allow custom serialization libraries to work with modules, even if the serial form includes fields of types in non-exported/non-open packages. > - And, what about module unloading? > From what I know, classes are never unloaded, unless they have no active > references to any of their objects and class object/etc, and unless > their class loader is collectable, that requires all other classes not > to be referenced/etc. How does this extend to modules? When modules are > unloaded? The granularity of unloading is the module layer, not individual modules. To be GC'ed then a strongly reachable object can't reference something in the module. > - How to dynamically load modules? Does it require a new layer to be > created? Can you base a layer you create directly on the empty layer? > for example to run an app in a different environment, isolated from most > of the modules of another app... Every module reads java.base which is in the boot layer so minimally you will have the boot layer as the parent rather than the empty layer. > - Probably the last question: are security providers per module/layer, > or per java virtual machine? Sometimes it at least seems useful for > two... javaee apps to have two versions of bouncycastle jcajce provider > running without conflict. The security provider mechanism was updated some time ago to use ServiceLoader and so works with modules. I believe it will only automatically locate service provider on the module path or class path. When doing dynamic configuration (and use the resolveRequiresAndUses) then security providers will be resolved but I don't think will be used by the security APIs by default. This is really a topic for the security-dev list. -Alan From webczat_200 at poczta.onet.pl Fri Nov 25 22:21:43 2016 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Fri, 25 Nov 2016 23:21:43 +0100 Subject: Few questions In-Reply-To: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> Message-ID: <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> Well, I specifically mean setAccessible usage between modules. Another question that comes to mind after reading some things: what about relation of jigsaw and osgi? Is jigsaw going to replace osgi? Well, what I exactly mean is, I know you try to make jigsaw and osgi work together. I just mean, is jigsaw module system going to work in such a way that you would be able to use it for modularizing applications without osgi, assuming that either the app does not use dynamic services, or it does, but there would be a service manager built on top of jigsaw? Specifically, what about multiple versions of the same module per jvm and multiple packages with the same name per jvm (either private, or exported non transitively)... W dniu 25.11.2016 o 23:05, Alan Bateman pisze: > On 25/11/2016 19:33, Micha? Zegan wrote: > >> Hello. >> >> I have a few questions about project jigsaw and things that are related. >> >> - Does, or will, the jlink tool allow creating executables? I mean, >> packing app with the runtime not in a directory, but in an executable >> file of some sort? Or, will it be extendable in such a direction? Some >> people would like something similar, although such an exe would be >> really big. > jlink creates a run-time image so it's not a single .exe file. The > details on the run-time image layout are in JEP 220 but might be easier > to just try it out to see how it works. There are lots of opportunities > to do static linking and other things but they beyond the current scope > of JEP 282 and JEP 275. > > >> - Is it possible to, in any way, circumvent module access control? >> Reflection works to see, currently, all classes and interfaces, all >> methods/fields/constructors of theirs whether private, protected or >> whatever, and may be used to circumvent all such access restrictions. >> What about deliberate circumventing of access from one module to >> another, when an accessed class would be from a package that is not >> exported? > All places that do access checks have been updated to work with modules. > In the case of core reflection then you can discover private fields and > methods that aren't accessible so it's not really any different to how > core reflection has always worked (ignoring setAccessible). > >> How does it all work with serialization? > Java serialization works exactly as before, no changes. Custom > serialization on the other hand is a challenge. There are specialized > APIs in the jdk.unsupported module to allow custom serialization > libraries to work with modules, even if the serial form includes fields > of types in non-exported/non-open packages. > > >> - And, what about module unloading? >> From what I know, classes are never unloaded, unless they have no active >> references to any of their objects and class object/etc, and unless >> their class loader is collectable, that requires all other classes not >> to be referenced/etc. How does this extend to modules? When modules are >> unloaded? > The granularity of unloading is the module layer, not individual > modules. To be GC'ed then a strongly reachable object can't reference > something in the module. > > >> - How to dynamically load modules? Does it require a new layer to be >> created? Can you base a layer you create directly on the empty layer? >> for example to run an app in a different environment, isolated from most >> of the modules of another app... > Every module reads java.base which is in the boot layer so minimally you > will have the boot layer as the parent rather than the empty layer. > >> - Probably the last question: are security providers per module/layer, >> or per java virtual machine? Sometimes it at least seems useful for >> two... javaee apps to have two versions of bouncycastle jcajce provider >> running without conflict. > The security provider mechanism was updated some time ago to use > ServiceLoader and so works with modules. I believe it will only > automatically locate service provider on the module path or class path. > When doing dynamic configuration (and use the resolveRequiresAndUses) > then security providers will be resolved but I don't think will be used > by the security APIs by default. This is really a topic for the > security-dev list. > > -Alan > From Alan.Bateman at oracle.com Sat Nov 26 08:34:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 26 Nov 2016 08:34:04 +0000 Subject: Few questions In-Reply-To: <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> Message-ID: On 25/11/2016 22:21, Micha? Zegan wrote: > Well, I specifically mean setAccessible usage between modules. All I can suggest is to read the javadoc, the proposal for #AwkwardStrongEncapsulation [1], and of course try out the EA builds [2]. > Another question that comes to mind after reading some things: what > about relation of jigsaw and osgi? Is jigsaw going to replace osgi? > Well, what I exactly mean is, I know you try to make jigsaw and osgi > work together. I just mean, is jigsaw module system going to work in > such a way that you would be able to use it for modularizing > applications without osgi, assuming that either the app does not use > dynamic services, or it does, but there would be a service manager built > on top of jigsaw? The module system has built-in support for services. See Alex's session on "Modules and Services" from JavaOne 2016 [3] for more on that. > Specifically, what about multiple versions of the same module per jvm > and multiple packages with the same name per jvm (either private, or > exported non transitively)... You can do this with dynamic configurations and the layer API. Alex's "Project Jigsaw: Under the Hook" session from JavaOne 2016 is the session to watch for more on that topic. -Alan [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html [2] https://jdk9.java.net/jigsaw/ [3] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016 From webczat_200 at poczta.onet.pl Sat Nov 26 10:50:22 2016 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Sat, 26 Nov 2016 11:50:22 +0100 Subject: Few questions In-Reply-To: References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> Message-ID: <9706644b-13d1-50aa-8c3e-8426a04dda05@poczta.onet.pl> well, about services, the problem is (probably) that services in jigsaw, last I've checked, were purely static in nature. That is they cannot dynamically appear and disappear and modules cannot be notified about it, that wuld be a reason for a service container. W dniu 26.11.2016 o 09:34, Alan Bateman pisze: > On 25/11/2016 22:21, Micha? Zegan wrote: > >> Well, I specifically mean setAccessible usage between modules. > All I can suggest is to read the javadoc, the proposal for > #AwkwardStrongEncapsulation [1], and of course try out the EA builds [2]. > >> Another question that comes to mind after reading some things: what >> about relation of jigsaw and osgi? Is jigsaw going to replace osgi? >> Well, what I exactly mean is, I know you try to make jigsaw and osgi >> work together. I just mean, is jigsaw module system going to work in >> such a way that you would be able to use it for modularizing >> applications without osgi, assuming that either the app does not use >> dynamic services, or it does, but there would be a service manager built >> on top of jigsaw? > The module system has built-in support for services. See Alex's session > on "Modules and Services" from JavaOne 2016 [3] for more on that. > > >> Specifically, what about multiple versions of the same module per jvm >> and multiple packages with the same name per jvm (either private, or >> exported non transitively)... > You can do this with dynamic configurations and the layer API. Alex's > "Project Jigsaw: Under the Hook" session from JavaOne 2016 is the > session to watch for more on that topic. > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html > > [2] https://jdk9.java.net/jigsaw/ > [3] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016 From blackdrag at gmx.org Sat Nov 26 11:41:32 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 26 Nov 2016 12:41:32 +0100 Subject: Few questions In-Reply-To: <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> Message-ID: <583974EC.3040701@gmx.org> On 25.11.2016 23:21, Micha? Zegan wrote: > Well, I specifically mean setAccessible usage between modules. If your code really requires setAccessible it is going to break with jigsaw. And there is no way to for example emulate that on java.base without using command line arguments intended only for the transition to "real" modules. > Another question that comes to mind after reading some things: what > about relation of jigsaw and osgi? they are different beasts > Is jigsaw going to replace osgi? No > Well, what I exactly mean is, I know you try to make jigsaw and osgi > work together. I just mean, is jigsaw module system going to work in > such a way that you would be able to use it for modularizing > applications without osgi, assuming that either the app does not use > dynamic services, or it does, but there would be a service manager built > on top of jigsaw? No. OSGI sits on top of jigsaw. > Specifically, what about multiple versions of the same module per jvm > and multiple packages with the same name per jvm (either private, or > exported non transitively)... multiple versions of the same module can be done... kinda... Just not at compile-time. You will be required to handle all the layers and read edges yourself. At compile-time jigsaw does not allow multiple versions of the same module - not even two distinct modules that use the same packages (I forgot if that was really only for the exported packages, or if the non-exported count as well, or if them counting as well was/is a bug). bye Jochen From webczat_200 at poczta.onet.pl Sat Nov 26 11:53:04 2016 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Sat, 26 Nov 2016 12:53:04 +0100 Subject: Few questions In-Reply-To: <583974EC.3040701@gmx.org> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> <583974EC.3040701@gmx.org> Message-ID: I know that osgi sits on top of jigsaw, but osgi was created when jigsaw did not exist, so it is itself a module system for java that does not need jigsaw. So then it would probably look like a module system on top of another module system... seems weird to me. What should I do when I would like to write a new application that would be modular? Use jigsaw directly or not? W dniu 26.11.2016 o 12:41, Jochen Theodorou pisze: > On 25.11.2016 23:21, Micha? Zegan wrote: >> Well, I specifically mean setAccessible usage between modules. > > If your code really requires setAccessible it is going to break with > jigsaw. And there is no way to for example emulate that on java.base > without using command line arguments intended only for the transition to > "real" modules. > >> Another question that comes to mind after reading some things: what >> about relation of jigsaw and osgi? > > they are different beasts > >> Is jigsaw going to replace osgi? > > No > >> Well, what I exactly mean is, I know you try to make jigsaw and osgi >> work together. I just mean, is jigsaw module system going to work in >> such a way that you would be able to use it for modularizing >> applications without osgi, assuming that either the app does not use >> dynamic services, or it does, but there would be a service manager built >> on top of jigsaw? > > No. OSGI sits on top of jigsaw. > >> Specifically, what about multiple versions of the same module per jvm >> and multiple packages with the same name per jvm (either private, or >> exported non transitively)... > > multiple versions of the same module can be done... kinda... Just not at > compile-time. You will be required to handle all the layers and read > edges yourself. At compile-time jigsaw does not allow multiple versions > of the same module - not even two distinct modules that use the same > packages (I forgot if that was really only for the exported packages, or > if the non-exported count as well, or if them counting as well was/is a > bug). > > bye Jochen From Alan.Bateman at oracle.com Sat Nov 26 14:28:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 26 Nov 2016 14:28:12 +0000 Subject: Few questions In-Reply-To: <583974EC.3040701@gmx.org> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> <583974EC.3040701@gmx.org> Message-ID: <94f9613f-be65-a7fb-7428-0f02a238dc9f@oracle.com> On 26/11/2016 11:41, Jochen Theodorou wrote: > On 25.11.2016 23:21, Micha? Zegan wrote: >> Well, I specifically mean setAccessible usage between modules. > > If your code really requires setAccessible it is going to break with > jigsaw. To be more specific, it will be a problem for code that attempts to use setAccessible to break into JDK classes (aside from jdk.unsupported then the JDK modules don't open any packages for deep reflection). > multiple versions of the same module can be done... kinda... Just not > at compile-time. You will be required to handle all the layers and > read edges yourself. At compile-time jigsaw does not allow multiple > versions of the same module - not even two distinct modules that use > the same packages (I forgot if that was really only for the exported > packages, or if the non-exported count as well, or if them counting as > well was/is a bug). The rule is that a module m can't read two or modules that export the same package to m. If you are doing dynamic configuration and using the layer APi then you usually don't need to do anything with "read edges". Applications or libraries doing code generation or using method handles may need to but they are advanced cases. -Alan From Alan.Bateman at oracle.com Sat Nov 26 14:44:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 26 Nov 2016 14:44:49 +0000 Subject: Few questions In-Reply-To: <9706644b-13d1-50aa-8c3e-8426a04dda05@poczta.onet.pl> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> <9706644b-13d1-50aa-8c3e-8426a04dda05@poczta.onet.pl> Message-ID: On 26/11/2016 10:50, Micha? Zegan wrote: > well, about services, the problem is (probably) that services in jigsaw, > last I've checked, were purely static in nature. > That is they cannot dynamically appear and disappear and modules cannot > be notified about it, that wuld be a reason for a service container. Layers can be created and be GC'ed. If you look at jlink or javac then you'll see that they create a layer to load service providers (jlink plugins in the case of jlink). So a different model so what you might be looking for. All I can suggest is to try things out to get familiar with how it all works. -Alan From alan.bateman at oracle.com Sat Nov 26 16:09:28 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 26 Nov 2016 16:09:28 +0000 Subject: hg: jigsaw/jake/langtools: Replace hashes in ModuleHashes with array Message-ID: <201611261609.uAQG9TjV027947@aojmv0008.oracle.com> Changeset: b5eae0a5878c Author: alanb Date: 2016-11-26 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b5eae0a5878c Replace hashes in ModuleHashes with array ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleHashes_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java From alan.bateman at oracle.com Sat Nov 26 16:09:39 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 26 Nov 2016 16:09:39 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201611261609.uAQG9dKv028004@aojmv0008.oracle.com> Changeset: a406b21f7748 Author: alanb Date: 2016-11-26 15:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a406b21f7748 Replace hashes in ModuleHashes with array ! 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/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.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/ModuleHashes.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java Changeset: 965ecf9a1e14 Author: alanb Date: 2016-11-26 15:17 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/965ecf9a1e14 Fix typo in method name ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java Changeset: 2aaf9b760ef9 Author: alanb Date: 2016-11-26 16:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2aaf9b760ef9 More SL cleanup ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java From blackdrag at gmx.org Sat Nov 26 17:18:53 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 26 Nov 2016 18:18:53 +0100 Subject: Few questions In-Reply-To: References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> <583974EC.3040701@gmx.org> Message-ID: <5839C3FD.8040808@gmx.org> On 26.11.2016 12:53, Micha? Zegan wrote: > I know that osgi sits on top of jigsaw, but osgi was created when jigsaw > did not exist, so it is itself a module system for java that does not > need jigsaw. > So then it would probably look like a module system on top of another > module system... seems weird to me. That is because jigsaw does not try to be a replacement for OSGI. OSGI for example does normally not do anything for you at compile time. jigsaw on the other hand does not allow you using multiple versions. > What should I do when I would like to write a new application that would > be modular? Use jigsaw directly or not? It depends then on your requirements bye Jochen From webczat_200 at poczta.onet.pl Sat Nov 26 17:29:52 2016 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Sat, 26 Nov 2016 18:29:52 +0100 Subject: Few questions In-Reply-To: <5839C3FD.8040808@gmx.org> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> <583974EC.3040701@gmx.org> <5839C3FD.8040808@gmx.org> Message-ID: well... But jigsaw itself can become a foundation for such a higher level framework build directly on top of jigsaw that adds such dynamic capabilities? W dniu 26.11.2016 o 18:18, Jochen Theodorou pisze: > On 26.11.2016 12:53, Micha? Zegan wrote: >> I know that osgi sits on top of jigsaw, but osgi was created when jigsaw >> did not exist, so it is itself a module system for java that does not >> need jigsaw. >> So then it would probably look like a module system on top of another >> module system... seems weird to me. > > That is because jigsaw does not try to be a replacement for OSGI. OSGI > for example does normally not do anything for you at compile time. > jigsaw on the other hand does not allow you using multiple versions. > >> What should I do when I would like to write a new application that would >> be modular? Use jigsaw directly or not? > > It depends then on your requirements > > bye Jochen From blackdrag at gmx.org Sat Nov 26 17:53:11 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 26 Nov 2016 18:53:11 +0100 Subject: Few questions In-Reply-To: References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> <583974EC.3040701@gmx.org> <5839C3FD.8040808@gmx.org> Message-ID: <5839CC07.4040006@gmx.org> On 26.11.2016 18:29, Micha? Zegan wrote: > well... > > But jigsaw itself can become a foundation for such a higher level > framework build directly on top of jigsaw that adds such dynamic > capabilities? if you want more than jigsaw offers out of the box, you have add runtime capabilities and you can do so to some extend. Like making a new layer and defining modules in their on your own, in which you then set the read edges and such. bye Jochen From webczat_200 at poczta.onet.pl Sat Nov 26 17:57:42 2016 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Sat, 26 Nov 2016 18:57:42 +0100 Subject: Few questions In-Reply-To: <5839CC07.4040006@gmx.org> References: <36214ee0-2dd8-7d0c-2287-e58e2f6d7328@oracle.com> <55e3deb7-9dd7-e809-0b81-c71304a3d031@poczta.onet.pl> <583974EC.3040701@gmx.org> <5839C3FD.8040808@gmx.org> <5839CC07.4040006@gmx.org> Message-ID: as for multiple version, there seems to be an open issue for that, do not remember the hashtag. But well, there seems to be only one month left. W dniu 26.11.2016 o 18:53, Jochen Theodorou pisze: > On 26.11.2016 18:29, Micha? Zegan wrote: >> well... >> >> But jigsaw itself can become a foundation for such a higher level >> framework build directly on top of jigsaw that adds such dynamic >> capabilities? > > if you want more than jigsaw offers out of the box, you have add runtime > capabilities and you can do so to some extend. Like making a new layer > and defining modules in their on your own, in which you then set the > read edges and such. > > bye Jochen From alan.bateman at oracle.com Sun Nov 27 08:33:07 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 27 Nov 2016 08:33:07 +0000 Subject: hg: jigsaw/jake/jdk: Update ProblemList to list JAX-WS issue Message-ID: <201611270833.uAR8X7mN019924@aojmv0008.oracle.com> Changeset: bf9c1eda7c6a Author: alanb Date: 2016-11-27 08:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bf9c1eda7c6a Update ProblemList to list JAX-WS issue ! test/ProblemList.txt From snicoll at pivotal.io Sun Nov 27 09:16:54 2016 From: snicoll at pivotal.io (=?UTF-8?Q?St=C3=A9phane_Nicoll?=) Date: Sun, 27 Nov 2016 10:16:54 +0100 Subject: Replacement for JDK8 APIs In-Reply-To: References: Message-ID: Hey, Thanks for all the feedback so far. Any idea about the annotation processor question? Is there a dedicated dev list for it maybe? Thank you, S. On Thu, Nov 24, 2016 at 3:22 PM, St?phane Nicoll wrote: > Hi, > > I am working on the Spring Boot project[1] and I am trying to make sure > our codebase compiles with the current JDK9 build[2]. So far I've hit two > major issues: > > We use "sun.misc.VMSupport" to retrieve the port being used by the Java > remote debugging. You can find the actual code in RemoteDebugPortProvider[3] > > We have an annotation processor that inspects all classes annotated with > @ConfigurationProperties and generates some meta-data about them. One > important piece of this is to extract the default value assigned to fields. > Consider the following example > > @ConfigurationProperties > public class Foo { > > private static final String DEFAULT_NAME = "name"; > > private String name = DEFAULT_NAME; > > private Integer counter = 42; > > private List hosts = Collections.singletonList("localhost"); > > > } > > What we've build is a visitor that navigates to those elements and > extracts the default values assigned to each field, including navigating to > parent element (the "name" constant there) or inferring value from method > parameters ("localhost"). The current code relies on a feature of the JDK > that is no longer exported[4]: > > > java.lang.IllegalAccessException: class org.springframework.boot. > configurationprocessor.fieldvalues.javac.Trees cannot access class > com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because > module jdk.compiler does not export com.sun.tools.javac.api to unnamed > module @5a7fe64 > > > Does anybody has some insight as how we could migrate those two use cases? > In particular, the second use case could be implemented with a contract of > javax.lang.model but we haven't found how to do it. > > Thank you, > S. > > > > [1] https://github.com/spring-projects/spring-boot > [2] https://github.com/spring-projects/spring-boot/issues/7226 > [3] https://github.com/spring-projects/spring-boot/blob/ > master/spring-boot-devtools/src/main/java/org/ > springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java > [4] https://github.com/spring-projects/spring-boot/blob/ > master/spring-boot-tools/spring-boot-configuration- > processor/src/main/java/org/springframework/boot/configurationprocessor/ > fieldvalues/javac/Trees.java > > > > > From Alan.Bateman at oracle.com Sun Nov 27 09:46:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Nov 2016 09:46:09 +0000 Subject: Replacement for JDK8 APIs In-Reply-To: References: Message-ID: <8c48530f-170e-24b8-e51b-da0c2d87b08d@oracle.com> On 27/11/2016 09:16, St?phane Nicoll wrote: > Hey, > > Thanks for all the feedback so far. Any idea about the annotation processor > question? Is there a dedicated dev list for it maybe? > compiler-dev is the place to bring it up. -Alan From peter.levart at gmail.com Sun Nov 27 11:15:43 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 27 Nov 2016 12:15:43 +0100 Subject: Code review for jigsaw/jake -> jdk9/dev sync up In-Reply-To: <6da3ac71-ca2b-3284-576d-055c19a65521@oracle.com> References: <6da3ac71-ca2b-3284-576d-055c19a65521@oracle.com> Message-ID: <8c6567ad-6c42-cebc-52b7-a28caad1c64b@gmail.com> Hi Alan, Overall this looks very good. I noticed a couple of nits... 1. I wonder if the new ServiceLoader API signature should be tweaked a bit... There is a new method in ServiceLoader with the following signature: public Stream> stream() ...where Provider declares the following two methods: Class type(); S get(); Which means that I can do the following: ServiceLoader loader = ServiceLoader.load(MyService.class); Class clazz = loader.stream().map(Provider::type).findFirst().get(); But 'clazz' now holds a Class object representing the implementation class (MyServiceImpl for example) not the MyService class/interface. Could this be characterized as heap pollution? For example, I can not do the following easily without unchecked casts: Class clazz = MyServiceImpl.class; Error: java: incompatible types: java.lang.Class cannot be converted to java.lang.Class So should Provider rather declare the following? Class type(); Or alternatively, should ServiceLoader rather declare the following? public Stream> stream(); 2. In Resolver::makeGraph, the initial 'g2' graph from parent configurations' "require transitive" is build this way: for (Configuration parent : parents) { if (parent != Configuration.empty()) { parent.configurations().forEach(c -> { c.modules().forEach(m1 -> { m1.descriptor().requires().stream() .filter(r -> r.modifiers().contains(Modifier.TRANSITIVE)) .forEach(r -> { String dn = r.name(); assert c.findModule(dn).isPresent() || r.modifiers().contains(Modifier.STATIC); c.findModule(dn).ifPresent(m2 -> { g2.computeIfAbsent(m1, k -> new HashSet<>()).add(m2); }); }); }); }); } } Now that there can be multiple parents of some configuration, those parents can have common parents, but since you iterate the transitive configurations of each individual parent in isolation, you can encounter a common "diamond" configuration multiple times. Logically all is well since you collect the required modules into Sets so multiplicity is taken care of. But this is not very optimal from algorithm point. It would be better to 1st make a stream of unique configurations of all parents: parents .stream() .flatMap(Configuration::configurations) .distinct() ...and then continute processing this stream further. You could even make this code more "functional" by using flatMap instead of forEach... Map> g2 = parents .stream() .flatMap(Configuration::configurations) .distinct() // optimization in case of common "diamond" parent(s) .flatMap(c -> c.modules().stream().flatMap(m1 -> m1.descriptor().requires().stream() .filter(req -> req.modifiers().contains(Modifier.TRANSITIVE)) .flatMap(req -> { Optional m2 = c.findModule(req.name()); assert m2.isPresent() || req.modifiers().contains(Modifier.STATIC); return m2.stream(); }) .map(m2 -> Map.entry(m1, m2)) ) ) .collect(Collectors.groupingBy( Map.Entry::getKey, () -> new HashMap<>(capacity), Collectors.mapping(Map.Entry::getValue, Collectors.toSet()) )); Regards, Peter On 11/24/2016 04:25 PM, Alan Bateman wrote: > Folks on jigsaw-dev will know that we are on a mission to bring the > changes accumulated in the jake forest to jdk9/dev. We can think of > this as a refresh of the module system in JDK 9, the last big refresh > was in May with many small updates since then. > > The focus this time is to bring the changes that are tied to JSR > issues into jdk9/dev, specifically the issues that are tracked on the > JSR issues list [1] as: > > #CompileTimeDependences > #AddExportsInManifest > #ClassFileModuleName > #ClassFileAccPublic > #ServiceLoaderEnhancements > #ResourceEncapsulation/#ClassFilesAsResources > #ReflectiveAccessToNonExportedTypes > #AwkwardStrongEncapsulation > #ReadabilityAddedByLayerCreator > #IndirectQualifiedReflectiveAccess (partial) > #VersionsInModuleNames > #NonHierarchicalLayers > #ModuleAnnotations/#ModuleDeprecation > #ReflectiveAccessByInstrumentationAgents > > Some of these issues are not "Resolved" yet, meaning there is still > ongoing discussion on the EG mailing list. That is okay, there is > nothing final here. If there are changes to these proposals then the > implementation changes will follow. Also, as I said in a mail to > jigsaw-dev yesterday [2], is that we will keep the jake forest open > for ongoing prototyping and iteration, also ongoing implementation > improvements where iteration or bake time is important. > > For the code review then the focus is therefore on sanity checking the > changes that we would like to bring into jdk9/dev. We will not use > this review thread to debate alternative designs or other big > implementation changes that are more appropriate to bake in jake. > > To get going, I've put the webrevs with a snapshot of the changes in > jake here: > http://cr.openjdk.java.net/~alanb/8169069/0/ > > The changes are currently sync'ed against jdk-9+146 and will be > rebased (and re-tested) against jdk9/dev prior to integration. There > are a number of small changes that need to be added to this in the > coming days, I will refresh the webrev every few days to take account > of these updates. > > > A few important points to mention, even if you aren't reviewing the > changes: > > 1. This refresh requires a new version of jtreg to run the tests. The > changes for this new version are in the code-tools/jtreg repository > and the plan is to tag a new build (jtreg4.2-b04) next week. Once the > tag has been added then we'll update the requiredVersion property in > each TEST.ROOT to force everyone to update. > > 2. For developers trying out modules with the main line JDK 9 builds > then be aware that `requires public` changes to `requires transitive` > and the `provides` clause changes to require all providers for a > specific service type to be in the same clause. Also be aware that the > binary form of the module declaration (module-info.class) changes so > you will need to recompile any modules. > > 3. Those running existing code on JDK 9 and ignoring modules will need > to be aware of a disruptive change in this refresh. The disruptive > change is #AwkwardStrongEncapsulation where setAccessible(true) is > changed so that it can't be used to break into non-public > fields/methods of JDK classes. This change is going to expose a lot of > hacks in existing code. We plan to send mail to jdk9-dev in advance of > this integration to create awareness of this change. As per the > original introduction of strong encapsulation then command line > options (and now the manifest of application JAR files) can be used to > keep existing code working. The new option is `--add-opens` to open a > package in a module for deep reflection by other modules. As an > example, if you find yourself with code that hacks into the private > `comparator` field in java.util.TreeMap then running with `--add-opens > java.base/java.util=ALL-UNNAMED` will keep that code working. > > > A few miscellaneous notes for those that are reviewing: > > 1. We have some temporary/transition code in the top-level repo to > deal with the importing of the JavaFX modules. This will be removed > once the changes are in JDK 9 for the OpenJFX project to use. > > 2. In the jdk repo then it's important to understand that the module > system is initialized at startup and there are many places where we > need to keep startup performance in mind. This sometimes means less > elegant code than might be used if startup wasn't such a big concern. > > 3. The changes in the jaxws repo make use of new APIs that means the > code doesn't compile with JDK 7 or JDK 8. Our intention is to work > with the JAXB and JAX-WS maintainers to address the issues in the > upstream project and then bring those changes into jdk9/dev to replace > the patches that we are forced to push for the short term. > > 4. You will see several tests where the value of the @modules tag has > `:open` or `:+open`. This is new jtreg speak. The former means the > test is run with --add-opens to open the package, the latter means the > test is exported at compile-time and exported + open at run-time (the > latter usage will be rare, it's where tests have static references to > JDK internal types and are also doing deep reflection with > setAccessible). > > > In terms of dates then we are aiming to integrate these changes into > jdk9/dev in early December. I will send a follow-up mail next week on > this as we work through the logistics. > > -Alan > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ > [2] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010219.html From jonathan.gibbons at oracle.com Sun Nov 27 15:57:29 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 27 Nov 2016 07:57:29 -0800 Subject: Replacement for JDK8 APIs In-Reply-To: References: Message-ID: St?phan, You say you are using com.sun.tools.javac.api.JavacTrees. Although that class is not exported from jdk.compiler, it is an implementation of the interface com.sun.source.util.Trees, which is exported. Is the interface sufficient to your needs? If not, what methods are you calling? -- Jon On 11/27/16 1:16 AM, St?phane Nicoll wrote: > Hey, > > Thanks for all the feedback so far. Any idea about the annotation processor > question? Is there a dedicated dev list for it maybe? > > Thank you, > S. > > > On Thu, Nov 24, 2016 at 3:22 PM, St?phane Nicoll wrote: > >> Hi, >> >> I am working on the Spring Boot project[1] and I am trying to make sure >> our codebase compiles with the current JDK9 build[2]. So far I've hit two >> major issues: >> >> We use "sun.misc.VMSupport" to retrieve the port being used by the Java >> remote debugging. You can find the actual code in RemoteDebugPortProvider[3] >> >> We have an annotation processor that inspects all classes annotated with >> @ConfigurationProperties and generates some meta-data about them. One >> important piece of this is to extract the default value assigned to fields. >> Consider the following example >> >> @ConfigurationProperties >> public class Foo { >> >> private static final String DEFAULT_NAME = "name"; >> >> private String name = DEFAULT_NAME; >> >> private Integer counter = 42; >> >> private List hosts = Collections.singletonList("localhost"); >> >> >> } >> >> What we've build is a visitor that navigates to those elements and >> extracts the default values assigned to each field, including navigating to >> parent element (the "name" constant there) or inferring value from method >> parameters ("localhost"). The current code relies on a feature of the JDK >> that is no longer exported[4]: >> >> >> java.lang.IllegalAccessException: class org.springframework.boot. >> configurationprocessor.fieldvalues.javac.Trees cannot access class >> com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because >> module jdk.compiler does not export com.sun.tools.javac.api to unnamed >> module @5a7fe64 >> >> >> Does anybody has some insight as how we could migrate those two use cases? >> In particular, the second use case could be implemented with a contract of >> javax.lang.model but we haven't found how to do it. >> >> Thank you, >> S. >> >> >> >> [1] https://github.com/spring-projects/spring-boot >> [2] https://github.com/spring-projects/spring-boot/issues/7226 >> [3] https://github.com/spring-projects/spring-boot/blob/ >> master/spring-boot-devtools/src/main/java/org/ >> springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java >> [4] https://github.com/spring-projects/spring-boot/blob/ >> master/spring-boot-tools/spring-boot-configuration- >> processor/src/main/java/org/springframework/boot/configurationprocessor/ >> fieldvalues/javac/Trees.java >> >> >> >> >> From vitaliy.pisarev at hpe.com Sun Nov 27 18:28:51 2016 From: vitaliy.pisarev at hpe.com (Pisarev, Vitaliy) Date: Sun, 27 Nov 2016 18:28:51 +0000 Subject: How many modules per jar? Message-ID: I am not sure I hit the right mailing list, kindly redirect me if needed. I am preparing a lecture for my team about the new module system and wondering whether there is already a set of best practices around this. For example: should we host each module in a separate jar or should a jar contain more than one module if the list is cohesive enough? Thanks, Vitaliy. From forax at univ-mlv.fr Sun Nov 27 19:14:17 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 27 Nov 2016 20:14:17 +0100 (CET) Subject: How many modules per jar? In-Reply-To: References: Message-ID: <1845609064.2629605.1480274057073.JavaMail.zimbra@u-pem.fr> Hi vitaliy, ----- Mail original ----- > De: "Pisarev, Vitaliy" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Dimanche 27 Novembre 2016 19:28:51 > Objet: How many modules per jar? > I am not sure I hit the right mailing list, kindly redirect me if needed. > > I am preparing a lecture for my team about the new module system and wondering > whether there is already a set of best practices around this. > > For example: should we host each module in a separate jar or should a jar > contain more than one module if the list is cohesive enough? C