JEP 200: The Modular JDK

[David M. Lloyd]

On 08/27/2014 01:31 PM, Alan Bateman wrote:
> On 27/08/2014 17:14, David M. Lloyd wrote:
>>
>> 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.
> The JDK has had warnings in the documentation since JDK 1.0 or 1.1.
> There has been compiler warnings since JDK 6 but they doesn't seem to be
> much of a deterrent either. So I think our experiences with "advisory"
> might to different.

I think this is the fundamental difference.  You think "deterrent".  I 
think "expectation management".  People who *want* the functionality 
will get it; it is a far more efficient expenditure of energy to let 
them do it and just clearly manage expectations than to try to modify 
behavior (which will just result in frustration for users).  Adding 
artificial barriers is counter-productive, and may even introduce 
security risks as yet more JVM security mechanisms are added on top of 
the existing stuff (a lesson that the constant CVE avalanche indicates 
has not been fully learned yet, especially in the context of Java).

>> 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.
>
> The security manager case is somewhat niche but ideally things should
> work the same way when running both with or without a security manager.
> There are few compatibility and subtle issues to do with the way things
> have historically worked in this area so they will need consideration.

I don't know about that.  We're talking, as always, about the concepts 
of visibility as opposed to accessibility.  Until now, all discussion 
has been in the context of visibility, which as I said (and MR agreed) 
is easily subverted - but then MR said he intends to "enforce module 
boundaries via access-control checks in the VM" which blurs the line 
considerably.  So if we're now moving into accessibility territory 
across class loaders, we're definitely and squarely overlapping with 
AccessController and its related facilities - i.e. "does module X have 
permission to import module Y?".  This is clearly a permission check, 
exactly like those done against the protection domain(s) of the module's 
class loader - why introduce a new mechanism when an existing matching 
solution exists?

-- 
- DML