Revisiting encapsulation requirement

[David M. Lloyd]

Experts, I think we should revisit the "Encapsulation" requirement with 
a view towards removal.

The requirement is:

> Encapsulation — The access-control mechanisms of the Java language and virtual machine must prevent code from accessing classes and interfaces in packages that are not exported by their containing modules, or in packages whose containing modules are not required by the module containing the code. These mechanisms must be operative even when a security manager is not present.

The implementation amounts to modifying the 
AccessibleObject.setAccessible() implementation for classes to perform a 
check of the caller's class loader before determining whether to make 
the object accessible.

As Rémi pointed out, this check is easily bypassed by using reflection, 
by reflecting on AccessibleObject.class itself - since all modules 
require "java.base", all modules implicitly can bypass this check.  But, 
even assuming this could somehow be patched over, I think we should 
consider dropping this requirement; I have two primary reasons for this 
(though there may be others as well).

The first reason is that without a security manager (or maybe even 
*with* a security manager - but that's another discussion), it is 
inevitable that any security measure used to protect this mechanism will 
ultimately be bypassed, rendering its security value useless; adding 
more complexity to the system to do so will only increase the overall 
vulnerability of the platform.

The second reason is that it is often useful to gain access to and 
inspect public classes that are not necessarily visible from your 
module.  Frameworks do this commonly for example - framework 
implementations will almost never import modules that they introspect.

I think in the end users will find it more convenient and intuitive (and 
no less secure in any real sense) if public classes remain accessible. 
In the absence of any dissent, I would move that we drop this requirement.

-- 
- DML