Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)
Alan.Bateman at oracle.com
Mon Sep 26 11:11:18 UTC 2016
On 26/09/2016 10:28, Andrew Dinn wrote:
> I'm sorry, Alan ,but I think that is disingenuous. When we see "access
> control" on this list all of us really ought to bear in mind what have
> been the de facto access control mechanisms for many JDK releases and
> many more years. There are two such levels of control and one of them is
> the security manager. That's a historic fact. Your statement above reads
> very much like an attempt to hijack the discourse by hijacking
> terminology so it addresses the topic you want to talk about (there is
> no imputation of such a motive here -- I'm just reporting how it looks).
I was simply pointing out that when we are discussing access control
here then we're talking about the access control that is enforced by the
Java Language and VM. No new terminology.
It is unfortunate that the legacy security manager mechanism also uses
the term "access control" but it's completely different mechanism that
is not relevant to anything we are doing here.
> Has this really been the specification? If so then many years of
> differing practice as regards the implementation have made that
> 'putative' specification worth less than the paper it is (probably no
> longer :-) printed on.
The core reflection methods that do access checks (Method.invoke,
Constructor.newInstance, Field.set, ...) have always specified IAE.
Compliant implementations have always implemented these checks. So there
is nothing really here. Core reflection has been loosened slightly so
that it assumes readability but it is otherwise aligned with the Java
Language and bytecode.
More information about the jigsaw-dev