Re: MethodHandles.Lookup and modules
On 10/12/2015 19:20, stanislav lukyanov wrote: This is connected to the second part of the question (2). If access to readable modules were allowed only if MODULE bit is set, transition from A to B would be safe, since only one transition could be made (actually, same as it is now, but not from unnamed module only). BTW, 'requires public' chain could be traversed safely even with PUBLIC mode: A.in(B).in(C).in(D) would have access to D's exported members and D's 'requires public' - same as A. The MODULE bit is for access to "module private" members, it has to be dropped when hopping to a lookup class in another module. In the A.in(B).in(C).in(D) example then each hop will preserve or degrade access. The modules for A, B, C and D may read very different sets of modules. The lookup class and mode bits aren't enough to represent this intersection so this is why access degrades quickly (or immediately) to 0. We have of course looked at preserving a snapshot of the intersection but this complicates things greatly and would diverge from bytecode behavior. Method handles API is really "conservative" in regard of access control and I believe it supposed to be nearly as safe as plain method calls (since Lookup basically reproduces bytecode-level checks). I think it shouldn't allow something just because reflection API is able to do the trick anyway. After all, it doesn't go easy with method access checks despite we have Method.setAccessible It might be a surprise but changing the readability graph at run-time via addReads changes the VM and bytecode behavior, it's not tied to core reflection. So yes, as things currently stand, then addReads will increase readability and therefore the types that can be accessed. Using addReads cannot be used to break encapsulation of course. : One more thing about javadoc. publicLookup() spec says - "As a matter of pure convention, the lookup class of this lookup object will be in an unnamed module." It's not about pure convention anymore - it really matters now where publicLookup() resides. You're right. This wording was mostly correct in early prototyping but isn't right now. It needs to be specified to be in an unnamed module, it can't be in a named module (at least not unless we get to the point where a named module can read all other modules). -Alan
Re: preliminary RFR: 8049365 - Update JDI and JDWP for modules
On 10/12/2015 20:44, serguei.spit...@oracle.com wrote: : 3. In the Module command set then we'll need to decide the reply to the Name command for the case that the module is an unnamed module. There is also an open issue for the runtime API too. The empty string is returned in the implementation. Would it be Ok to update the jdwp spec with this? We haven't decided what Module::getName should return for unnamed modules yet, it currently returns null. So we'll have to come back to it. For now then maybe JDWP can just return the stringID as 0 and we'll come back to it. : In ReferenceTypeImpl then I assume isModuleCached is not needed. Not sure, I understand this. Why? It seems there is some confusion here. This flag is similar to the flag isClassLoaderCached. I should have been clearer, I was just making the point that the flag isn't really needed as module == null will tell you that it hasn't been retreived from the target VM. Have you thought about SA yet? I can't recall if it is compiled with the boot JDK or will be compiled against the newly built jdk.jdi module. If the later then I assume that SA will need updates. If the former then I assume we will have issues with boot cycle builds. I'll ask Dmitry as he covers the SA. He had some plans on the Jigsaw update. Okay, although I'm just asking about the SA JDI connectors here. We just need to make sure that they build and I can't recall if they are compiled against the JDI in the boot JDK or the jdk.jdi module. If the former then we would only see issues with boot cycle builds. -Alan.
Re: preliminary RFR: 8049365 - Update JDI and JDWP for modules
On 12/11/15 00:40, Alan Bateman wrote: On 10/12/2015 20:44, serguei.spit...@oracle.com wrote: : 3. In the Module command set then we'll need to decide the reply to the Name command for the case that the module is an unnamed module. There is also an open issue for the runtime API too. The empty string is returned in the implementation. Would it be Ok to update the jdwp spec with this? We haven't decided what Module::getName should return for unnamed modules yet, it currently returns null. So we'll have to come back to it. For now then maybe JDWP can just return the stringID as 0 and we'll come back to it. In the jdwp.spec the 'stringObject' type is used instead of the 'stringID'. For the name command I used the 'string' type for consistency as the the only command where the 'stringObject' is returned is the VirtualMachine.CreateString. I'm Ok to convert to using the 'stringObject' for Module.Name if you still prefer it. : In ReferenceTypeImpl then I assume isModuleCached is not needed. Not sure, I understand this. Why? It seems there is some confusion here. This flag is similar to the flag isClassLoaderCached. I should have been clearer, I was just making the point that the flag isn't really needed as module == null will tell you that it hasn't been retreived from the target VM. I see now, thanks! The isClassLoaderCached was needed because a classLoader can be null. Fixed. Have you thought about SA yet? I can't recall if it is compiled with the boot JDK or will be compiled against the newly built jdk.jdi module. If the later then I assume that SA will need updates. If the former then I assume we will have issues with boot cycle builds. I'll ask Dmitry as he covers the SA. He had some plans on the Jigsaw update. Okay, although I'm just asking about the SA JDI connectors here. We just need to make sure that they build and I can't recall if they are compiled against the JDI in the boot JDK or the jdk.jdi module. If the former then we would only see issues with boot cycle builds. I see now, thanks! Will check what is needed for the SA JDI connectors and let you know. Thanks, Serguei -Alan.
Re: MethodHandles.Lookup and modules
John, Thanks for jumping in on this and the guidance. Comments inline. On 10/12/2015 23:08, John Rose wrote: This stuff makes my head hurt, but I'm fine with any semantics that preserves the following: 1. full power: MethodHandles.lookup() has the same privileges as (non-constructor) bytecode in the caller class Preserved, no changes. 2. downward monotonic 2a. L.in(A) never has more privileges than L (for all L, A) 2b. L.in(A) never has more privileges than a full power lookup on A (for all L, A) 2c. as a corollary, a chain L.in(A).in(B).in(C)… has no more privileges than L or any lookups in A, B, C, … Preserved with the exception of A, B and C in the same named module M and where the set modules that M reads increases (say where code in M reads additional modules). 3. graceful degradation: L.in(A) loses only privileges broken by the distance between LC=L.lookupClass and A 3a. if A==LC no privileges are lost; the identical L can be the result 3b. if A and LC are nestmates, only protected privileges may be lost (dynamic emulation of JLS nestmate access) 3c. if A and LC are in the same package, only private privileges may be lost 3d. if A and LC are in the same module, only package privileges may be lost Preserved but perhaps with the (initially surprising) consequence that all access is lost when m(LC) is a named module and m(A) is a different module. This arises because the two modules may read very different sets of modules, the intersection cannot be expressed via a lookup class + modes. 4. downward convergence (to publicLookup or empty privileges) 4a. if A is inaccessible to LC=L.lookupClass, L.in(A) has no privileges (less than publicLookup) 4b. if A is accessible to LC and L has non-empty privileges, L.in(A) is no less privileged than publicLookup 4c. for any L with non-empty privileges, there is a sequence of types A,B where L.in(A).in(B) is equivalent to publicLookup Downward convergence to zero access/empty privileges. No downward convergence to publicLookup because m(publicLookup.lookupClass) must read all modules, thus a superset of the modules that named modules will read. I should say of course that the publicLookup can only be used to create method handles to public members in packages that are exported unconditionally. So nothing that code in a named module couldn't otherwise access when it increases readability. 5. publicLookup has a reasonable minimal set of globally acceptable privileges 5a. this set of privileges is singular, and does not depend on the lookupClass 5b. the only possible results of publicLookup.in(A) are no change, and falling to empty privileges publicLookup is minimally trusted and so can only create method handles where the target type is public and exported (unconditionally). For 5b then publicLookup.in(A) may result in no change or degrade but not to empty privileges in one hop. The "no change" case is where A is in an unnamed module (think class path). The "degrade" case is where A is a named module and so the resulting lookup can only be used to access the public types that are exported unconditionally by modules that m(A) reads. Access can only be measured against the current state of the module graph, which means that certain results can vary over time, in a consistent way across the whole system. Yes, consistent with bytecode and also the access checks in core reflection. The above are my preferences; I can imaging tweaking some of those things in order to make the API fit more gracefully into modules. I rely on Alan & co. to figure that out! and we rely on you to ensure that what we do make sense. I hope this does not constitute a circular dependency :-) : (BTW, see https://bugs.openjdk.java.net/browse/JDK-8145070 ) The defining loader of publicLookup.lookupClass() is no longer null and looks like Nashorn trips up on the permission check in Class::getClassLoader. I agree with this. Lookups are primarily about emulating bytecode behavior (not reflection behavior), and providing a framework for safe and sane delegation. Adding edges to the readability graph impacts all access checks consistently and I think in a safe way. : Does publicLookup.in(A) create a new set of privileges depending on A? I think that is the current design; maybe it's best, but it's a little odd. If there really is a uniquely minimal set of public privileges, then that should be publicLookup, and PL.in(A) should not affect that minimal set. That's the intention of saying the LC of PL is mere convention. As publicLookup is no longer the minimal set of privileges then publicLookup.in(A) will impact reduce access for the case that m(A) is a named module. Stanislav makes a good point about the javadoc as a named module may not read all modules and so publicLookup needs to be in an unnamed module for now. We can modify axiom #5 to say: PL accesses a unique family of privileges sets, in
Re: MethodHandles.Lookup and modules
On Dec 11, 2015, at 6:02 AM, Alan Bateman wrote: > > John, > > Thanks for jumping in on this and the guidance. Comments inline. Nice, thanks. > > > On 10/12/2015 23:08, John Rose wrote: >> >> This stuff makes my head hurt, but I'm fine with any semantics that >> preserves the following: >> >> 1. full power: MethodHandles.lookup() has the same privileges as >> (non-constructor) bytecode in the caller class > Preserved, no changes. > >> >> 2. downward monotonic >> 2a. L.in(A) never has more privileges than L (for all L, A) >> 2b. L.in(A) never has more privileges than a full power lookup on A (for all >> L, A) >> 2c. as a corollary, a chain L.in(A).in(B).in(C)… has no more privileges than >> L or any lookups in A, B, C, … > Preserved with the exception of A, B and C in the same named module M and > where the set modules that M reads increases (say where code in M reads > additional modules). Does this mean adding edges to the readability graph at M? If so, then that's covered by the blanket exception mentioned later. If you mean something else, maybe we need a point 2d. > >> >> 3. graceful degradation: L.in(A) loses only privileges broken by the >> distance between LC=L.lookupClass and A >> 3a. if A==LC no privileges are lost; the identical L can be the result >> 3b. if A and LC are nestmates, only protected privileges may be lost >> (dynamic emulation of JLS nestmate access) >> 3c. if A and LC are in the same package, only private privileges may be lost >> 3d. if A and LC are in the same module, only package privileges may be lost > Preserved but perhaps with the (initially surprising) consequence that all > access is lost when m(LC) is a named module and m(A) is a different module. > This arises because the two modules may read very different sets of modules, > the intersection cannot be expressed via a lookup class + modes. That's fine. There are two main use cases for Lookup.in, neither of which require the tracking of long chains of L.in(A/B/C…). A. Agent with full-power lookup wants to invoke another agent with the lookup, but wants to limit access, because he doesn't fully trust the other agent. He does a single L.in(A) to a remote-enough type A, creating a non-full-power lookup. (Note: Picking A is sometimes non-trivial. This might be an API flaw.) B. Agent with full-power lookup wants to get access to private nestmate in A. He does a single L.in(A) where LC and A are in the same package member. This works around differences between access checks at JVM and JLS levels, just as the package-private accessor methods from javac do. (Yuck!) > >> >> 4. downward convergence (to publicLookup or empty privileges) >> 4a. if A is inaccessible to LC=L.lookupClass, L.in(A) has no privileges >> (less than publicLookup) >> 4b. if A is accessible to LC and L has non-empty privileges, L.in(A) is no >> less privileged than publicLookup >> 4c. for any L with non-empty privileges, there is a sequence of types A,B >> where L.in(A).in(B) is equivalent to publicLookup > Downward convergence to zero access/empty privileges. So points 4abc are just wrong. I can live with that. And, publicLookup can be used to get a lookup object that provides controlled access to a given module's M unconditional exports, without at the same time conferring access to M's internals. This is an important kind of weakened lookup. Going back to graceful degradation: 3e. If A is in a named module and LC in the unnamed module (or L is a public lookup), only public names readable from A are retained And then we get: 4. downward convergence to empty privileges 4a. if A is inaccessible to LC=L.lookupClass, L.in(A) has no privileges 4b. if A and LC are in different named modules, L.in(A) has no privileges (there is no attempt to retain an intersection of readability sets) > No downward convergence to publicLookup because m(publicLookup.lookupClass) > must read all modules, thus a superset of the modules that named modules will > read. I should say of course that the publicLookup can only be used to create > method handles to public members in packages that are exported > unconditionally. So nothing that code in a named module couldn't otherwise > access when it increases readability. Right. (FWIW, the term "unconditional" is not in the Lookup javadoc.) Should there be a way to build a lookup, for two modules M1/M2, which reads those names of M2 which M1 can read, except no internals of M1? I wonder if such a thing would be useful? Probably not. But it would be useful to have a lookup in a module M1 which can read the exports of *every* M2 that M1 can see, except no M1 internals. (This includes the unconditionally exported public names of M1.) This would be a Lookup with an LC in M1 and flags of PUBLIC only. I guess that is the effect of PL.in(M1) and point 3a, right? > > >> >> 5. publicLookup has a reasonable minimal set of globally acceptable >> privileges >> 5a. this set of privile
hg: jigsaw/jake: 29 new changesets
Changeset: 1a889daf7eb0 Author:attila Date: 2015-11-24 10:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1a889daf7eb0 8141338: Move jdk.internal.dynalink package to jdk.dynalink Reviewed-by: alanb, mchung, sundar ! make/CompileJavaModules.gmk ! make/Images.gmk ! modules.xml Changeset: 015cff85d10d Author:erikj Date: 2015-11-24 11:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/015cff85d10d 8143236: Update devkit creation makefiles for linux Reviewed-by: ihse ! make/devkit/Makefile ! make/devkit/Tools.gmk Changeset: 11b31df300ae Author:erikj Date: 2015-11-24 15:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/11b31df300ae 8143296: javac-server/sjavac not compatible with LogFailures on Windows Reviewed-by: ihse ! common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/src/fixpath.c ! make/InitSupport.gmk ! make/common/SetupJavaCompilers.gmk Changeset: b2a9c5ef147e Author:erikj Date: 2015-11-24 15:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b2a9c5ef147e 8143141: Bring in minor build changes from the jigsaw/jake forest Reviewed-by: ihse, mchung ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/Jprt.gmk ! make/Main.gmk ! make/common/JavaCompilation.gmk ! make/common/NativeCompilation.gmk Changeset: 358fb90ae6e6 Author:erikj Date: 2015-11-24 17:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/358fb90ae6e6 8142983: Enable builds with icecc/icecream Reviewed-by: ihse ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in Changeset: f069169dc66f Author:erikj Date: 2015-11-25 15:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f069169dc66f 8144039: Enable javac server by default Reviewed-by: ihse ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh Changeset: 12d27df4933e Author:erikj Date: 2015-11-27 16:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/12d27df4933e 8144172: Problem with bootcycle-images and sjavac Reviewed-by: ihse ! common/autoconf/bootcycle-spec.gmk.in ! make/Main.gmk Changeset: 8407c45c9379 Author:jbachorik Date: 2015-11-20 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8407c45c9379 8043138: Attach API should not require jvmstat rmi protocol Reviewed-by: alanb, mchung, erikj, ihse ! make/Images.gmk ! modules.xml Changeset: 5711553c7b41 Author:joehw Date: 2015-11-30 08:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5711553c7b41 8144094: Add Catalog API to java.xml module Reviewed-by: lancea ! make/common/CORE_PKGS.gmk ! modules.xml Changeset: 62351f9def8e Author:robm Date: 2015-11-30 17:37 + URL: http://hg.openjdk.java.net/jigsaw/jake/rev/62351f9def8e 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 Reviewed-by: alanb, simonis ! make/CompileJavaModules.gmk Changeset: 8f3c139771af Author:lana Date: 2015-11-30 13:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8f3c139771af Merge Changeset: 09d04e9badce Author:neliasso Date: 2015-11-16 20:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/09d04e9badce Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/Main.gmk Changeset: 3701b7e11a21 Author:neliasso Date: 2015-11-23 11:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3701b7e11a21 Merge Changeset: d430479aa7bc Author:amurillo Date: 2015-11-27 11:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d430479aa7bc Merge Changeset: f8e40a86242f Author:iklam Date: 2015-07-22 20:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f8e40a86242f 8140802: Clean up and refactor of class loading code for CDS Reviewed-by: jiangli, acorn ! modules.xml ! test/lib/sun/hotspot/WhiteBox.java Changeset: 260c0796b4c7 Author:jiangli Date: 2015-11-19 19:30 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/260c0796b4c7 Merge ! modules.xml Changeset: 5af41a2286d0 Author:jiangli Date: 2015-11-23 14:41 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5af41a2286d0 Merge ! modules.xml Changeset: fdbe1b5e0eb6 Author:erikj Date: 2015-11-24 12:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/fdbe1b5e0eb6 8142336: Convert the SA agent build to modular build-infra makefiles Reviewed-by: ihse, sla, dsamersoff, twisti ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/Main.gmk ! make/common/Modules
hg: jigsaw/jake/corba: 2 new changesets
Changeset: 10a482b86358 Author:lana Date: 2015-12-10 08:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/10a482b86358 Added tag jdk-9+96 for changeset feb1bd85d799 ! .hgtags Changeset: 99620e004719 Author:mchung Date: 2015-12-10 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/99620e004719 Merge
hg: jigsaw/jake/jaxp: 6 new changesets
Changeset: e2fbfb7ed78a Author:joehw Date: 2015-11-30 16:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e2fbfb7ed78a 8142463: Xml schema validation failing after Xerces update; maxOccurs ignored Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSDFACM.java + test/javax/xml/jaxp/unittest/validation/tck/ParticleTest.java + test/javax/xml/jaxp/unittest/validation/tck/upa01.xml + test/javax/xml/jaxp/unittest/validation/tck/upa01.xsd Changeset: 1cefe0c8447c Author:lana Date: 2015-12-02 09:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1cefe0c8447c Merge Changeset: 2b4a2f136208 Author:joehw Date: 2015-12-03 11:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/2b4a2f136208 8132091: Clean up JAXP code that has dependency on Java version string Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java Changeset: 1f3182529f2c Author:lana Date: 2015-12-07 14:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1f3182529f2c Merge Changeset: b078d4258d9c Author:lana Date: 2015-12-10 08:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/b078d4258d9c Added tag jdk-9+96 for changeset 1f3182529f2c ! .hgtags Changeset: 23a6fe4172e8 Author:mchung Date: 2015-12-10 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/23a6fe4172e8 Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
hg: jigsaw/jake/jaxws: 6 new changesets
Changeset: c9651a1f9063 Author:mkos Date: 2015-11-27 11:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/c9651a1f9063 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader Reviewed-by: lancea ! src/java.xml.ws/share/classes/javax/xml/soap/FactoryFinder.java ! src/java.xml.ws/share/classes/javax/xml/soap/MessageFactory.java ! src/java.xml.ws/share/classes/javax/xml/soap/SAAJMetaFactory.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPConnectionFactory.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPFactory.java + src/java.xml.ws/share/classes/javax/xml/soap/ServiceLoaderUtil.java + src/java.xml.ws/share/classes/javax/xml/soap/package-info.java Changeset: 2f21153bea9d Author:lana Date: 2015-11-30 13:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2f21153bea9d Merge Changeset: b55cebc47555 Author:lana Date: 2015-12-07 14:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b55cebc47555 Merge Changeset: 7293db4716ee Author:lana Date: 2015-12-10 08:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7293db4716ee Added tag jdk-9+96 for changeset b55cebc47555 ! .hgtags Changeset: fe38ca1dc4a9 Author:mchung Date: 2015-12-10 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fe38ca1dc4a9 Merge ! src/java.xml.ws/share/classes/javax/xml/soap/FactoryFinder.java Changeset: c171b34ce2ae Author:mchung Date: 2015-12-11 00:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/c171b34ce2ae Ensure readable after merge ! src/java.xml.ws/share/classes/javax/xml/soap/FactoryFinder.java ! src/java.xml.ws/share/classes/javax/xml/soap/ServiceLoaderUtil.java
hg: jigsaw/jake/nashorn: 16 new changesets
Changeset: aac8413d3bb7 Author:hannesw Date: 2015-11-23 15:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/aac8413d3bb7 8141407: Wrong evaluation of a != a when a = NaN Reviewed-by: sundar, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8141407.js Changeset: a685736f225b Author:hannesw Date: 2015-11-23 17:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a685736f225b 8143821: Wrong test name in JDK-8143304 Reviewed-by: attila, sundar - test/script/basic/JDK-8059934.js + test/script/basic/JDK-8143304.js Changeset: f3b883bec2d0 Author:attila Date: 2015-11-24 10:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f3b883bec2d0 8141338: Move jdk.internal.dynalink package to jdk.dynalink Reviewed-by: hannesw, sundar ! make/BuildNashorn.gmk ! make/build.xml ! make/nbproject/project.xml ! make/project.properties + src/jdk.dynalink/share/classes/jdk/dynalink/CallSiteDescriptor.java + src/jdk.dynalink/share/classes/jdk/dynalink/ClassMap.java + src/jdk.dynalink/share/classes/jdk/dynalink/CompositeOperation.java + src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinkerFactory.java + src/jdk.dynalink/share/classes/jdk/dynalink/LinkerServicesImpl.java + src/jdk.dynalink/share/classes/jdk/dynalink/NamedOperation.java + src/jdk.dynalink/share/classes/jdk/dynalink/NoSuchDynamicMethodException.java + src/jdk.dynalink/share/classes/jdk/dynalink/Operation.java + src/jdk.dynalink/share/classes/jdk/dynalink/RelinkableCallSite.java + src/jdk.dynalink/share/classes/jdk/dynalink/StandardOperation.java + src/jdk.dynalink/share/classes/jdk/dynalink/TypeConverterFactory.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/AbstractJavaLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/AccessibleMembersLookup.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanIntrospector.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/CallerSensitiveDynamicMethod.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/ClassLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/ClassString.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/DynamicMethod.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/DynamicMethodLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/FacetIntrospector.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/GuardedInvocationComponent.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/MaximallySpecific.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/OverloadedDynamicMethod.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/OverloadedMethod.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/SimpleDynamicMethod.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/SingleDynamicMethod.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/StaticClass.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/StaticClassIntrospector.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/StaticClassLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/beans/messages.properties + src/jdk.dynalink/share/classes/jdk/dynalink/beans/package-info.java + src/jdk.dynalink/share/classes/jdk/dynalink/internal/AccessControlContextFactory.java + src/jdk.dynalink/share/classes/jdk/dynalink/internal/InternalTypeUtilities.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/ConversionComparator.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardedInvocation.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardedInvocationTransformer.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingDynamicLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingDynamicLinkerExporter.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingTypeConverterFactory.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/LinkRequest.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/LinkerServices.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/MethodHandleTransformer.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/MethodTypeConversionStrategy.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/package-info.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/CompositeGuardingDynamicLinker.java + src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java + src/jdk.dyna
hg: jigsaw/jake/jdk: 125 new changesets
Changeset: 74bc089000c8 Author:ksrini Date: 2015-09-28 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/74bc089000c8 8066272: pack200 must support Multi-Release Jars Reviewed-by: jrose, sdrach ! src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java + test/tools/pack200/MultiRelease.java Changeset: e9b7db0341f6 Author:amlu Date: 2015-11-23 16:14 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e9b7db0341f6 8143583: Several tests don't work with latest jtreg due to non-existing files in @build Reviewed-by: alanb, sla ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/SuspendNoFlagTest.java ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/sun/tools/jmap/BasicJMapTest.java Changeset: e36cbc6ac95b Author:darcy Date: 2015-11-23 08:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e36cbc6ac95b 8143813: Problem list PKCS8Test.java Reviewed-by: mullan ! test/ProblemList.txt Changeset: caba60c122b6 Author:sherman Date: 2015-11-23 10:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/caba60c122b6 8143553: StringBuffer.getByte(byte[], int, byte) should be package private (not protected) Reviewed-by: thartmann ! src/java.base/share/classes/java/lang/StringBuffer.java Changeset: 25b577ea72d5 Author:shurailine Date: 2015-11-23 11:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/25b577ea72d5 8139430: Refactor test library to decrease module dependencies of tests Reviewed-by: mchung, alanb ! test/java/util/logging/TestLoggerWeakRefLeak.java - test/lib/testlibrary/jdk/testlibrary/InputArguments.java ! test/lib/testlibrary/jdk/testlibrary/JcmdBase.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/lib/testlibrary/jdk/testlibrary/TestThread.java + test/lib/testlibrary/jdk/testlibrary/management/InputArguments.java + test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java ! test/sun/tools/jcmd/TestJcmdSanity.java ! test/sun/tools/jinfo/JInfoHelper.java ! test/sun/tools/jmap/BasicJMapTest.java ! test/sun/tools/jps/JpsBase.java ! test/sun/tools/jstack/BasicJStackTest.java Changeset: 0c0366bc27b3 Author:okutsu Date: 2015-11-24 13:22 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c0366bc27b3 8073211: javadoc of Format parseObject methods should specify NullPointerExceptions Reviewed-by: naoto, peytoia, okutsu Contributed-by: Naveen Kumar ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/Format.java ! src/java.base/share/classes/java/text/MessageFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java Changeset: 1326072e44bf Author:attila Date: 2015-11-24 10:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1326072e44bf 8141338: Move jdk.internal.dynalink package to jdk.dynalink Reviewed-by: alanb, mchung, sundar ! make/src/classes/build/tools/module/ext.modules Changeset: 6ad5d252b55c Author:erikj Date: 2015-11-24 15:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6ad5d252b55c 8143141: Bring in minor build changes from the jigsaw/jake forest Reviewed-by: ihse, mchung ! make/gendata/GendataBreakIterator.gmk ! make/gensrc/GensrcCommon.gmk ! make/gensrc/GensrcMisc.gmk ! make/gensrc/GensrcProperties.gmk ! make/launcher/Launcher-jdk.jcmd.gmk ! make/launcher/Launcher-jdk.jconsole.gmk ! make/launcher/Launcher-jdk.jdi.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/Lib-jdk.crypto.ucrypto.gmk Changeset: 715972927a17 Author:shade Date: 2015-11-24 19:02 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/715972927a17 8136500: Integer/Long getChars and stringSize should be more idiomatic Reviewed-by: igerasim, sherman, psandoz, jrose ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java + test/java/lang/Integer/ToString.java + test/java/lang/Long/ToString.java Changeset: db013eafc5c3 Author:rgoel Date: 2015-11-24 14:46 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/db013eafc5c3 7011840: TEST_BUG java/util/Locale/LocaleEnhanceTest.java Summary: Outputting extra information in LocaleEnhanceTest.java Reviewed-by: peytoia, naoto ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 33fd40487d6d Author:amjiang Date: 2015-11-25 09:42 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33fd40487d6d 8143377: Test PKCS8Test.java fails Reviewed-by: weijun ! test/ProblemList.txt ! test/sun/security/pkcs/pkcs8/PKCS8Test.java Changeset: 000dd74c5ad7 Author:weijun Date: 2015-11-25 11:58 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/000dd74c5ad7 8143913: MSCAPI keystore should accept Certificate[] in setEntry() Reviewed-by: vinnie ! src/jdk.crypto.mscapi/windows
hg: jigsaw/jake/langtools: 13 new changesets
Changeset: 73adc11fd50f Author:sadayapalam Date: 2015-11-26 07:44 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/73adc11fd50f 8143647: Javac compiles method reference that allows results in an IllegalAccessError Summary: Lambda implementation method synthesized by javac should not mention inaccessible types. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference75.java + test/tools/javac/lambda/pkg/PublicDerived8143647.java Changeset: 130ae42e6da7 Author:alundblad Date: 2015-11-26 09:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/130ae42e6da7 8144009: ToolBox should have a cleanDirectory method Summary: Added cleanDirectory method to ToolBox. Reviewed-by: jjg ! test/tools/lib/ToolBox.java ! test/tools/sjavac/CompileCircularSources.java ! test/tools/sjavac/CompileExcludingDependency.java ! test/tools/sjavac/CompileWithAtFile.java ! test/tools/sjavac/CompileWithInvisibleSources.java ! test/tools/sjavac/CompileWithOverrideSources.java ! test/tools/sjavac/IncCompileChangeNative.java ! test/tools/sjavac/IncCompileDropClasses.java ! test/tools/sjavac/IncCompileNoChanges.java ! test/tools/sjavac/IncCompileUpdateNative.java ! test/tools/sjavac/NoState.java ! test/tools/sjavac/PermittedArtifact.java ! test/tools/sjavac/SJavacTester.java ! test/tools/sjavac/StateDir.java Changeset: ab5e0a945e78 Author:sadayapalam Date: 2015-11-26 17:38 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ab5e0a945e78 8078660: Misleading recommendation from diamond finder. Summary: javac should recommend diamond usage if that could lead to a change in program behavior. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/DiamondRedundantArgs1.java ! test/tools/javac/generics/diamond/6939780/T6939780_7.out ! test/tools/javac/generics/diamond/6939780/T6939780_8.out ! test/tools/javac/generics/diamond/6939780/T6939780_9.out ! test/tools/javac/generics/diamond/7002837/T7002837.java - test/tools/javac/generics/diamond/7002837/T7002837.out ! test/tools/javac/generics/diamond/neg/T8078473.java - test/tools/javac/generics/diamond/neg/T8078473.out ! test/tools/javac/generics/diamond/neg/T8078473_2.java - test/tools/javac/generics/diamond/neg/T8078473_2.out Changeset: 853c77f8193c Author:jlahoda Date: 2015-11-30 17:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/853c77f8193c 8143037: JShell should determine commands by prefix Reviewed-by: rfield, mcimadamore, briangoetz ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/ToolBasicTest.java Changeset: 38910274fc6f Author:lana Date: 2015-11-30 13:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/38910274fc6f Merge - test/tools/javac/diags/examples/DiamondRedundantArgs1.java - test/tools/javac/generics/diamond/7002837/T7002837.out - test/tools/javac/generics/diamond/neg/T8078473.out - test/tools/javac/generics/diamond/neg/T8078473_2.out Changeset: d2713a6edc13 Author:rfield Date: 2015-12-01 10:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d2713a6edc13 8142447: JShell tool: Command change: re-run n-th command should be re-run by id Reviewed-by: rfield Contributed-by: bitterf...@gmail.com ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/jdk/jshell/ToolBasicTest.java Changeset: 218a0c168db3 Author:lana Date: 2015-12-02 09:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/218a0c168db3 Merge - test/tools/javac/diags/examples/DiamondRedundantArgs1.java - test/tools/javac/generics/diamond/7002837/T7002837.out - test/tools/javac/generics/diamond/neg/T8078473.out - test/tools/javac/generics/diamond/neg/T8078473_2.out Changeset: 17ac95d2a6ec Author:vromero Date: 2015-12-04 09:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/17ac95d2a6ec 8008685: DPrinter should include MethodType.recvtype Reviewed-by: jjg ! test/tools/javac/lib/DPrinter.java Changeset: 9006c168c651 Author:jjg Date: 2015-12-04 14:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9006c168c651 8143268: Langtools tools should create output directories as needed. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties - test/tools/javac/T6413876.java + test/tools/javac/file/T8143268.java ! test/tools/javac/options/modes/OutputDirTest.java Changeset: baf0f4ce55e1 Author:rfield Date: 2015-12-07 09:18 -0800 URL: http://hg.openjdk.java.net/jigs
hg: jigsaw/jake/hotspot: Missing closing bracket breaks hotspot build
Changeset: df521234d197 Author:mchung Date: 2015-12-11 15:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/df521234d197 Missing closing bracket breaks hotspot build ! src/share/vm/classfile/systemDictionaryShared.hpp
hg: jigsaw/jake/jdk: Problem list JAX-WS tests
Changeset: 0d1c1ba783b8 Author:mchung Date: 2015-12-11 16:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d1c1ba783b8 Problem list JAX-WS tests ! test/ProblemList.jake.txt
hg: jigsaw/jake: Fixup jdk.hotspot.agent workaround
Changeset: 90ba04818266 Author:mchung Date: 2015-12-11 16:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/90ba04818266 Fixup jdk.hotspot.agent workaround ! make/CompileJavaModules.gmk
hg: jigsaw/jake/nashorn: Update -XaddExports to access jdk.dynalink internal API
Changeset: f356eb048b4e Author:mchung Date: 2015-12-11 16:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f356eb048b4e Update -XaddExports to access jdk.dynalink internal API ! make/project.properties
Re: preliminary RFR: 8049365 - Update JDI and JDWP for modules
> On Dec 11, 2015, at 12:40 AM, Alan Bateman wrote: > > We just need to make sure that they build and I can't recall if they are > compiled against the JDI in the boot JDK or the jdk.jdi module. If the former > then we would only see issues with boot cycle builds. jdk.hotspot.agent is built in the same way as other JDK modules. Thanks to Erik’s recent change converting converting the SA agent build to modular build. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8142336
