JEP 200: The Modular JDK

[Gregg Wonderly]

On 8/27/2014 10:57 AM, mark.reinhold at oracle.com wrote:
> 2014/8/27 7:36 -0700, david.lloyd at redhat.com:
>> 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).
As a long time Jini user, I am very familiar with using JVM SecurityManager 
implementations to add my own SecurityManager checks for permissions in APIs.   
If you are planning on using that mechanism, then I would say that would be 
great, if it can work with any SecurityManager.  The issue, of course, is that 
you need to use whatever SecurityManager a JVM has plugged in at the time, to 
make sure that you enforce the deployment required security needs, not something 
that you think will always be appropriate.

The implication is then that your have .class visible implementation which can 
be decompiled, edited and recompiled to remove whatever security access checks 
that might be deemed unwanted.

This is really the issue for many it would seem.  Modularity for me, means that 
I can take things in and out of my deployment to reduce the size of it.  And, in 
particular, I would really like to be able to take out of the deployment, every 
single .class file that I don't need.   In the Jini environment, we do this with 
a dependency analysis tool so that the downloaded .jar file, at the client, 
doesn't contain anything more than what is actually needed by the client.

What does Modular JDK, at the root of its definition here, really mean to you Mark?

Gregg Wonderly