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

[Alan Bateman]

On 26/09/2016 04:50, GREGG WONDERLY wrote:

> I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count.  I understand that the JDK itself is not deployed with a security manager impl in most cases, and thus there would be no access context for the security manager to be used against.  What’s odd, is that you are still trying to block access to reflective access to the “open JDK”.  If it’s really open and it’s really something that the community contributes to, why do we need to block access, hide details and otherwise obfuscate access details?  Modularization should just be about separating pieces not needed should it not?  Why has this degenerated into such a huge bit of access restriction too?
When you see "access control" in mails on this list then think the 
access control specified by the Java Language Specification and Java 
Virtual Machine Specification. It's nothing to do with the legacy 
security manager mechanism.

As regards core reflection then keep in mind that it has always been 
specified to do the same access checks as the Java Language and VM. It 
should not be a surprise if you get IllegalAccessException when 
attempting to access something when the equivalent Java code does not 
compile or where the equivalent bytecode would fail with IllegalAccessError.

> :
>
> For a long time, I have had conversations with a lot of different Sun, and now Oracle employees.   I think that they all want to enable great things to happen with the Java platform.  But the attempts at perfection and control involved in many of the JSRs (NIO2’s failure to provide a working, dependable filesystem observer for all platforms for example)
I can't tell what you mean here but if you are looking to interpose on 
file system operations then that support has been there since Java SE 7. 
If you mean the Watcher API then there is a platform independent 
implementation in OpenJDK. In any case, the nio-dev list is the place 
for to being gripes in this area.

>   which have resulted in only partial improvements and in many cases reduced penetration (java.util.logging still doesn’t get improvements to align it’s apis better with varargs and more brief API designs)
It's not clear to me that it's worth doing a lot of the j.u.logging API 
but keep in mind that there were updates to modernize it a bit in Java 
SE 8 (Logger has methods that take a message Supplier for example). Also 
with JEP 264 then you have a way to plugin in your preferred logging 
framework to consume logging from the platform. The core-libs-dev list 
is the place to bring gripes or issues on logging.

-Alan