Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[Alan Bateman]

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.

-Alan