Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)
forax at univ-mlv.fr
Thu Sep 29 09:29:48 UTC 2016
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 way to do that is to have javac to emit an invokedynamic instead of an invokeinterface/invokevirtual
after having verified that everything is typechecked.
As Paul said in the bug comment section, it will also allow to retrofit old API like the atomic reference field updaters to use VarHandles.
----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Andrew Dinn" <adinn at redhat.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mercredi 28 Septembre 2016 20:09:00
> Objet: Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes /
> 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. This has a good section to
> explain how access checking differs to core reflection.
> JDK-8162494  is one issue where John has a write-up with some straw
> man designs. I suspect it will require working through a few specific
> examples to get a feel for what is the right direction.
>  https://bugs.openjdk.java.net/browse/JDK-8162494
More information about the jigsaw-dev