Revisiting encapsulation requirement

[David M. Lloyd]

On 09/17/2015 09:57 AM, mark.reinhold at oracle.com wrote:
> 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.

Of course not.  But as far as I can tell, it has yet to be shown that 
this requirement and its corresponding implementation changes actually 
improve security in any real way.  I'm not talking in hand-wavy 
generalizations like "encapsulation leads to better security", I'm 
talking about brass-tacks examples.

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

Correct me if I'm wrong, but you seem to be making an assumption here 
that no existing artifacts can or should be "graduated" as-is into 
modules.  This is further underscored by this statement:

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

The compatibility story is getting increasingly foggy here.  On the one 
hand, for example, "JDK 9 retains this three-level hierarchy, in order 
to preserve compatibility" - a hierarchy that as far as I can tell, 
very, *very* few existing things actually care about - but on the other 
hand, nothing in the Jigsaw module system prototype is compatible in any 
way with the class loading world as we know it - which very *very* many 
existing things rely on.

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

-- 
- DML