On 08/27/2014 10:57 AM, mark.reinh...@oracle.com wrote:
2014/8/27 7:36 -0700, david.ll...@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
