Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)
Remi Forax
forax at univ-mlv.fr
Tue Sep 27 10:03:18 UTC 2016
----- Mail original -----
> De: "Andrew Dinn" <adinn at redhat.com>
> À: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: jigsaw-dev at openjdk.java.net
> Envoyé: Lundi 26 Septembre 2016 13:36:46
> Objet: Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes /
> #AwkwardStrongEncapsulation)
[...]
> 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 defining and implementing Jigsaw)
> have an answer to that question?
If a code becomes modular, what jigsaw changes is that by default you can not see non exported packages or use setAccessible.
In both cases, those features are enforced by security checks done by the VM.
A SecurityManager is something used to implement a peculiar security policy on top of the Java VM security, you can not disable any VM checks with a security manager.
So from my planet, it is weird to think that the security manager can be involved :)
regards,
Rémi
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the jigsaw-dev
mailing list