> On Apr 4, 2017, at 8:02 AM, Alasdair Nottingham > <alasdair.notting...@gmail.com> wrote: > One of the problems Java has today is that it is very easy to end up > depending on internals > because the JVM has no modularity. It is one thing to end up using a Java API > that is > visible, but not intended to be used by an application, and another to > explicitly break > the modularity constraints in order to call API’s that are not intended to be > accessible. If > someone does write an agent, to break out of the modularity constraints, I do > not think anyone > can validly complain if a change breaks what they are doing. The creation of > the agent is > essentially an acceptance they have done something that could be broken at > any time. > Essentially I’m leaning back on I don’t think this is a likely vector for > someone attempting > to subvert the modularity system for the long term. Perhaps I’m just being > too optimistic, but > in my work on non-modular app servers, and modular app servers it is clear > that if you put in > place protection designed to stop accidental use (but not determined > malicious use), then it > causes people to think twice about breaking out of the constraints.
The business of “allowing” access and “knowing” the secret sauce being spread around by various dependent libraries is exactly why I keep bringing up the use of the SecurityManager. In environments where it is active, I would want to have to provide a permission for each and every agent or other access to details breaking modularity. That way, I’d be able to know that I care about what that library is doing. If those Permissions were classified on a web page somewhere as “breaking” modularity, then the whole developer world would suddenly be able to be informed about what they were committing to. What would be possible, is to use a security manager to “test” or “check” what modularity breaking code was doing so that you could either grant the permissions, or reject the library and move to another path of solution. Using command line arguments feels like a “Permission” grant. But making it more explicit in the code with separate Permissions, lets developers manage the dependency of one execution path while not granting access to others for example. Gregg
