Revisiting encapsulation requirement

[mark.reinhold at oracle.com]

2015/9/15 5:01 -0700, david.lloyd at redhat.com:
> 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.

I think it's premature, less than a week after the publication of the
initial design and first early-access builds, to propose that we drop
this central requirement.

I suggest that we instead focus on the design as proposed, and figure
out how to make it better.

> The implementation amounts to modifying the 
> AccessibleObject.setAccessible() implementation

This one method is just a small part of the overall encapsulation story,
which is described in detail in the SotMS document.

>                                                 for classes to perform a 
> check of the caller's class loader before determining whether to make 
> the object accessible.

No, that's not exactly right; please see my detailed reply to Rémi.

> 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.

A simple bug, easily fixed.

>                                                                     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.

Yes, security is hard.  That's not a reason to give up on it.

> 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.

Frameworks in their current form often work as-is on the class path,
because of the way that unnamed modules work, as discussed in my reply
to Rémi.  See, e.g., Peter Levart's report on the jigsaw-dev list [1].

If you convert a framework (or any other code) into a module then you can
use the Module::addReads method [2][3] to add read edges to the module
graph at run time.  This is, in effect, an API that allows a module to
`require` additional modules dynamically.

- Mark


[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004537.html
[2] http://openjdk.java.net/projects/jigsaw/spec/sotms/#increasing-readability
[3] http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Module.html#addReads-java.lang.reflect.Module-