New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

[Andrew Dinn]

On 01/11/16 14:23, 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.

Or indeed you might only require enough privilege to call the public
MethodHandles.Lookup constructor -- n.b. although that constructor is
public its package is not exported to the default module. Of course, you
can always arrange for it to be exported to one of /your/ modules.

Note that whatever mechanism is used to obtain Lookup instances this has
several advantages.

1) Once a privileged module is able to create Lookups (with suitably
constrained access) arranging for it to safely hand them over to your
framework code (and to no other code) when needed and with no more
access than is actually merited is relatively simple. Better still
arrange to hand over the requisite MethodHandles and keep the Lookup
instances secured.

Whereas

If you want to use reflection safely then you have to be able to call
setAccessible from a module which is an export target for the package of
the class whose member you want to access. In general you don't want to
export all possible reflection targets to all your framework code
(especially when it is in the default module). So, you end up having to
set up some privileged module and arrange for it call setAccessible on
behalf of your framework code (and no other code). Configuring all
potential exports to a privileged module in advance on the command line
will be tricky/verbose at best to and may well not even be possible. If
you have an agent that is capable of editing exports lists then you can
rewrite module exports to your privileged module on the fly but that is
also a lot of work (I know because I have tried it).

2) A MethodHandle created by a Lookup is not opaque to the compiler. So
this creates opportunities for the compiler to optimize the code that
employs them. Accessible fields/methods/constructors are opaque to the
compiler which makes it much less likely that optimization will be possible.

regards,


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