JEP 200: The Modular JDK

[Alan Bateman]

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.

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

-Alan.