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

[Alan Bateman]

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. I'm not saying this because I personally want to see Jigsaw
> drastically changed (although I know others, such as my colleague David
> Lloyd, have good reasons for requesting significant changes). No, it's
> rather because I think it is important that the rationale for one choice
> over another conflicting choice is articulated openly so that the
> consequences of making or rejecting any such choice can be understood
> and their pros and cons correctly weighed in the balance by all OpenJDK
> project members and users who are willing to expend the effort needed to
> understand and review those consequences. Isn't that how this project is
> supposed to work?
>
To your last paragraph, this project has an associated JSR and so design 
issues and proposals are discussed on jpms-spec-experts. There are 
associated -observers and -comments lists for those that want to follow 
and comment. Implementation issues are discussed here. It's impossible 
to distinguish the discussions sometimes, especially on this list as 
there are lots of passionate people with wildly different perspectives 
and expectations.

As regards design proposals then there are an infinite number of 
choices, esp. when you get into the details. In all honestly, there just 
isn't time in the day to write up all the details of every possible path.

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 into a security manager to ask if 
this access is allowed? Security managers don't know anything about the 
access control at this level. The permission checks that a security 
manager does involve stack walks and computing the intersection of 
permissions to see if the effective permissions are granted or not. This 
is right when checking access to security sensitive resources (network 
end points or files for example) but not at the level of checking if A 
has access to a member of B. At run-time then would you really want the 
the VM calling out to a security manager when doing JVMS-specified 
access checks? If there is no security manager (the common case) then 
does it mean that code in class A can access a private field in class B. 
Going further then executing the security manager's checkPermission will 
likely involve access checks in the VM so how would you handle those? 
Hopefully you'll start to see that the access checks that we dealing 
with here are at a completely different level to the permission checks 
that a security manager implements.

-Alan.