JEP 200: The Modular JDK

[mark.reinhold at oracle.com]

2014/8/27 1:13 -0700, david.lloyd at redhat.com:
> ...
> 
> 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).

As Alan noted, the experience of those of us working on the JDK itself
has been rather different.  We've warned against using internal APIs for
years, but it's had little effect.  In the meantime all this cruft upon
which people have come to depend has gradually grown into a significant
maintenance burden.  It's time to cut the cord.

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

We're trying to improve security, and we suspect we can do this in a
reasonably straightforward way.  Enforcing module boundaries in the VM
would be a big improvement over the existing means of protecting JDK
internals (e.g., SecurityManager::checkPackageAccess), which are are
brittle and error-prone.

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

The type of module-boundary access-control check we're thinking of would
be an extension of what the JVM currently does during class, interface,
field, and method resolution, per JVMS 5.4.4 [1].  It's the exact same
mechanism that keeps private members private, and it's very difficult to
subvert.  It has little (direct) relation to AccessController or any
kind of security-permission check.

- Mark


[1] http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.4