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