Revisiting encapsulation requirement

mark.reinhold at oracle.com mark.reinhold at oracle.com
Mon Oct 5 18:46:23 UTC 2015


2015/9/17 8:09 -0700, david.lloyd at redhat.com:
> On 09/17/2015 09:57 AM, mark.reinhold at oracle.com wrote:
>> 2015/9/15 5:01 -0700, david.lloyd at redhat.com:
>> ...
>> 
>>> 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.

Please see my reply to your other message, with the subject "Security".

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

On the contrary, I think it's critical to have a smooth migration path,
as stated in the requirements.  "Smooth" does not, however, mean "without
any effort".  Depending on what the code in an existing artifact does,
and how it relates to other artifacts, it might be very simple to upgrade
it into a module, or it might require some effort.

I have a draft of a longer note about migration, which I'll try to finish
up and post soon.

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

Can you be more specific?  What aspects of the design or the prototype
are not compatible with "the class loading world as we know it"?

Our intent has been to interfere as little possible with all the myriad
ways in which class loaders are used today.

- Mark


More information about the jpms-spec-experts mailing list