JEP 200: The Modular JDK

[David M. Lloyd]

On 08/27/2014 10:57 AM, mark.reinhold at oracle.com wrote:
> 2014/8/27 7:36 -0700, david.lloyd at redhat.com:
>> On 08/26/2014 09:05 AM, Alan Bateman wrote:
>>> On 26/08/2014 14:22, David M. Lloyd wrote:
>>>> As a matter of principle I'm generally opposed to exporting specific
>>>> module packages only to specific other modules.  I think this
>>>> indicates that a module split is required.  I'm guessing that at the
>>>> root of this problem is an attempt to avoid circular dependencies
>>>> during compilation, but I would rather that issue not be punted to the
>>>> runtime.
>>>
>>> For legacy code bases such as a JDK then this is useful and important.
>>> There are some areas that are more tightly coupled that would be if
>>> starting afresh. The most obvious example of where you might export
>>> something to only specific modules is sun.misc. It's JDK-internal but
>>> used in many areas of the JDK.
>>
>> We actually had a similar capability for similar reasons but found that
>> it fails for a couple reasons:
>>
>> 1. It fails as a security mechanism, as the security is trivially defeated
>> 2. It has always been possible to solve these abstraction issues in a
>> simpler way
>> 3. If users want access to a module, they will get it, one way or
>> another (this bar is after all far lower than language-level access
>> controls)
>
> Perhaps it's not clear in the JEPs but our intent is, in fact, to
> enforce module boundaries via access-control checks in the VM rather
> than simple visibility checks in class loaders (which are, as you point
> out, trivially defeated).

Even if this can be made truly secure, I wonder why this is considered, 
in principle, to be a good idea.  Taking the "paranoid hermit" approach 
to encapsulation at this level has always been much less successful for 
us.  All of my experiences with modular distributions add up to thinking 
that an advisory approach is far superior (and also more flexible).

If you put the hermit into the system, then everyone who uses it will 
become a hermit, because that's just how people are.  It makes more 
sense to be more flexible: let users describe the stability prospects of 
their modules in a way that consumers can be aware of it but not 
necessarily constrained.  We use two different schemes now, but they 
both amount to: we have "public" modules and "private" or "unsupported" 
modules.  The former have longer-term API guarantees and the latter may 
be changed or removed at any time without notice.  We use run time 
warnings, but the JDK could also add compile-time warnings very easily, 
and it is easy to imagine that this could even be customizable without 
too much effort.  Security can be enforced using the existing access 
controller mechanism (modulo some improvements that have already been 
proposed in that area and/or additional improvements that may (or may 
not) become possible as a result of modular architecture) without adding 
any fundamental complexity to the overall system.

Given the complexity of langauge/JVM-level access checking as it is now 
- and bugs that are still being found even in this very late stage - and 
the complexity of access controller based access checking as it is now, 
adding another mechanism seems ill-advised from this point of view as well.

-- 
- DML