New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

[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 <blackdrag at gmx.org> 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 implementation. 
>> Something deep in java.base.  Like Unsafe.
> 
> I don't see why this can't be a "regular" API though, rather than a
> super-user sledgehammer every single time.  If user code can be
> statically granted access, and that user code can deliberately acquire a
> narrowly-scoped object which can access those Lookups/*Handles, then
> isn't that better than using Unsafe, which not only represents
> unrestricted system-wide access, but can undermine even the JVM's
> integrity if leaked?

If making this a 'regular' API means allowing any code to use it then
that clearly undermines /all/ the access restrictions provided by
modules. The point is not to unlock all doors in the castle but to open
doors for trusted code when needed (and only then).

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.reflect.MethodHandles to a nominated module provided by your
framework then arrange for that module to hand out Lookups (or better
MethodHandles) to framework code as and when they are needed via a
private channel. You can do arrange that with a single addExports option
on the command line and a very small amount of setup code to establish
the private channel

regards,


Andrew Dinn
-----------