Re: Request Review: JDK-6479237 (cl) Add support for classloader names

2016-11-01 Thread Alan Bateman
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/

Re: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments.

2016-11-01 Thread Alan Bateman
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.

Re: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments.

2016-11-01 Thread Alan Bateman
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",

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Remi Forax
- Mail original - > De: "Remi Forax" > À: "Paul Bakker" > Cc: jigsaw-dev@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 implementat

hg: jigsaw/jake/jdk: Import of 8168980: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class, Constructor)

2016-11-01 Thread chris . hegarty
Changeset: 7992a052c7fa Author:chegar Date: 2016-11-01 12:37 + 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

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread David M. Lloyd
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 re

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread John Rose
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 woul

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

2016-11-01 Thread Daniel Fuchs
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

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Jochen Theodorou
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 privi

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread John Rose
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 impl

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread David M. Lloyd
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

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Andrew Dinn
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

How to check for an internal class in another module from java.base?

2016-11-01 Thread Wang Weijun
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

Re: How to check for an internal class in another module from java.base?

2016-11-01 Thread Alan Bateman
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 expo

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Andrew Dinn
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 interna

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Remi Forax
- Mail original - > De: "John Rose" > À: "David M. Lloyd" > Cc: jigsaw-dev@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: >>

Re: How to check for an internal class in another module from java.base?

2016-11-01 Thread Daniel Fuchs
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

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Andrew Dinn
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 Secu

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Remi Forax
- Mail original - > De: "David M. Lloyd" > À: jigsaw-dev@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,

Re: How to check for an internal class in another module from java.base?

2016-11-01 Thread Wang Weijun
> 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. I

Re: How to check for an internal class in another module from java.base?

2016-11-01 Thread Wang Weijun
> 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 chec

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Jochen Theodorou
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

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread David M. Lloyd
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 priv

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Alan Bateman
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 chec

Re: How to check for an internal class in another module from java.base?

2016-11-01 Thread Alan Bateman
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

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Jochen Theodorou
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 a

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Andrew Dinn
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

Re: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

2016-11-01 Thread Steve Drach
>>> 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

Re: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments.

2016-11-01 Thread Alexandre (Shura) Iline
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

JDK 9 Early Access with Project Jigsaw, build 142 on 10-31-2016 (#5670)

2016-11-01 Thread Alan Bateman
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.o

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread David M. Lloyd
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

Re: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

2016-11-01 Thread Steve Drach
>>> 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 modul

Re: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

2016-11-01 Thread Mandy Chung
> 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

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread Remi Forax
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

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

2016-11-01 Thread Mandy Chung
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() ?

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

2016-11-01 Thread John Rose
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 us