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.
