Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On Sep 29, 2016, at 2:29 AM, Remi Forax wrote: > > This bug only talk about the callee side, i.e. accessing to a non accessible > class by a framework. > The other part, the caller side, is to have a way to emit a call that send > the caller lookup to a framework, > the easy

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

Hi David, I'm not the one to answer your queries, but may I ask you some questions about your requirements and also give some comments... On 09/28/2016 02:13 PM, David M. Lloyd wrote: Hi all, I've been requested to ask if the OpenJDK development team have had a chance to review this email,

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

te...@oracle.com> > À: "Andrew Dinn" <ad...@redhat.com> > Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 28 Septembre 2016 20:09:00 > Objet: Re: Alternative mechanism for reflective access control > (#ReflectiveAccessToNonExp

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 28/09/16 19:09, Alan Bateman wrote: > On 28/09/2016 13:22, Andrew Dinn wrote: >> I'd be happy to try to conduct such an experiment. Can you provide links >> to the relevant JIRAs. > The javadoc for MethodsHandes.Lookup is probably the best place to > start, assuming you haven't used it before.

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 09/28/2016 07:01 AM, Alan Bateman wrote: On 28/09/2016 10:37, Gunnar Morling wrote: : I don't think that is what those folks asking about using the SM had in mind. Rather, the idea would be - IIUC - to grant code in module B (say an ORM tool) reflective access to non-exported (and of

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 28/09/16 13:01, Alan Bateman wrote: > In general then I think that we need to find ways to reduce the use of > setAccessible over time. We really need a long term plan to degrade, > deprecate and eventually remove it. This would of course mean working on > some challenging problems and

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

Hi all, I've been requested to ask if the OpenJDK development team have had a chance to review this email, and when we might expect a response. Thanks! On 09/21/2016 11:39 AM, David M. Lloyd wrote: In our internal discussion of the proposal for #ReflectiveAccessToNonExportedTypes, we

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 09/28/2016 04:37 AM, Gunnar Morling wrote: If I'm compiling a class A that has a reference to a member in type B then do you really want the compiler calling into a security manager to ask if this access is allowed? I don't think that is what those folks asking about using the SM had in

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 09/28/2016 05:31 AM, Gunnar Morling wrote: David, there is too much existing work out there, and the requirements go far beyond what can be satisfied by these simple questions. What are examples for such requirements? I.e. what from the list of your requirements cannot be mapped to the

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

David, > there is too much existing work out there, and the requirements go far beyond > what can be satisfied by these simple questions. What are examples for such requirements? I.e. what from the list of your requirements cannot be mapped to the mechanism suggested by Stephen? I find his

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

> If I'm compiling a class A that has a reference to a member in type B > then do you really want the compiler calling into a security manager to > ask if this access is allowed? I don't think that is what those folks asking about using the SM had in mind. Rather, the idea would be - IIUC - to

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

Hi Stephen, I just want to point out that this isn't a proposal per se. I don't advocate any particular syntax, nor recommendation for patterns that users should use. This is merely a set of requirements that we (Red Hat) have identified as necessary in order to enable the widest range of

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 27/09/16 12:34, Alan Bateman wrote: > On the specific topic of using the security manager to do JLS and JVMS > specified access checks then it doesn't make any sense to me. If I'm > compiling a class A that has a reference to a member in type B then do > you really want the compiler calling

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 26/09/2016 17:37, Andrew Dinn wrote: : That's very good to hear, because your previous phrasing certainly brought that commitment into question. As I am afraid does your continued unwillingness to provide motivation for why the current Jigsaw implementation operates in the way it does. n.b.

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 27.09.2016 13:01, dalibor topic wrote: On 27.09.2016 12:03, Andrew Dinn wrote: Yes we could use braces instead of a belt, but why do we /need/ braces when we can already wear a belt? I don't think that it's an either one or another proposition, Although the developing fashion sense in

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 27.09.2016 12:03, Andrew Dinn wrote: Yes we could use braces instead of a belt, but why do we /need/ braces when we can already wear a belt? I don't think that it's an either one or another proposition, Although the developing fashion sense in some countries dictated going with either

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

- Mail original - > De: "Andrew Dinn" <ad...@redhat.com> > À: "Alan Bateman" <alan.bate...@oracle.com> > Cc: jigsaw-dev@openjdk.java.net > Envoyé: Lundi 26 Septembre 2016 13:36:46 > Objet: Re: Alte

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 27/09/16 10:27, dalibor topic wrote: > On 26.09.2016 18:37, Andrew Dinn wrote: [snip] >> I think those involved in this discussion already know all that you have >> stated here regarding /what/ this project is doing. The present question >> is /why/ is something that it is doing needed. > >

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 26.09.2016 18:37, Andrew Dinn wrote: On 26/09/16 14:19, Alan Bateman wrote: On 26/09/2016 12:36, Andrew Dinn wrote: : I addressed that in the text you snipped. The one point of relevance is that which the original poster asked about: -- Why do we need Jigsaw to constrain access control

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 9/25/16 8:50 PM, GREGG WONDERLY wrote: I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count. I'm with you there. I'm fascinated that this thread has triggered references to the "legacy" security

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 26/09/16 14:19, Alan Bateman wrote: > On 26/09/2016 12:36, Andrew Dinn wrote: > >> : >> I addressed that in the text you snipped. The one point of relevance is >> that which the original poster asked about: >> >>-- Why do we need Jigsaw to constrain access control when we can do so >>

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

+1 Rémi - Mail original - > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Lundi 26 Septembre 2016 12:11:58 > Objet: Re: Alternative mechanism for reflective access control

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 26/09/2016 12:36, Andrew Dinn wrote: : I addressed that in the text you snipped. The one point of relevance is that which the original poster asked about: -- Why do we need Jigsaw to constrain access control when we can do so using a security manager? Do you (or anyone else involved in

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 26/09/16 12:11, Alan Bateman wrote: > On 26/09/2016 10:28, Andrew Dinn wrote: > >> : >> I'm sorry, Alan ,but I think that is disingenuous. When we see "access >> control" on this list all of us really ought to bear in mind what have >> been the de facto access control mechanisms for many JDK

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 26/09/2016 10:28, Andrew Dinn wrote: : I'm sorry, Alan ,but I think that is disingenuous. When we see "access control" on this list all of us really ought to bear in mind what have been the de facto access control mechanisms for many JDK releases and many more years. There are two such

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

Having read this proposal a number of times, and considering how the talks explained things at JavaOne, I have come to the conclusion that this proposal is too complex. FWIW, I like the idea that a module should be able to declare that it needs reflective access from its users, however given that

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 26/09/2016 04:50, GREGG WONDERLY wrote: I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count. I understand that the JDK itself is not deployed with a security manager impl in most cases, and thus

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count. I understand that the JDK itself is not deployed with a security manager impl in most cases, and thus there would be no access context for the