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
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() ?
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
> 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
>>> 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
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
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
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
>>> 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
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
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
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
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
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
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
> 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
> 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
- 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,
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
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
- 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:
>>
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
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
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
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
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
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
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
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
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
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
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
- 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
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",
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.
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/
36 matches
Mail list logo
