Mutable modules

[David M. Lloyd]

I had one last follow-up thought, see below:

On 05/20/2016 10:20 AM, David M. Lloyd wrote:
> You can't, on one hand, define a universal namespace and syntax for
> modules and their versions in the JDK or establish hard constraints on
> layer and module graph structure, and on the other hand expect other
> module systems with differing existing constraints to unify on the JDK
> module system.  You're basically cutting these systems off at the knees
> and forcing them to reinvent everything, unless you completely
> coincidentally have a system that already conforms to this structure (if
> so, you are either very fortunate or maybe starting off in a rather
> privileged position).

To be clear, what I'm advocating for is to separate these constraints 
from *at least* the diagnostic benefits and (f we can resurrect the 
access control discussion) the security benefits of JDK modules at run time.

This might take the form of much greater autonomy for Layers as I've 
proposed in the issues.  But, it might also take the form of allowing 
non-Jigsaw-style code to (separately, independently) arbitrarily create 
and manage Modules at run time, completely separate from descriptors, 
linking behavior, etc.  In other words, if I can establish a Class or 
Package in my class loader, while at the same time defining its module 
diagnostic information (name, version string, location string, etc.) and 
security information (what packages can access the nonpublic members of 
this package, preferably a (possibly wholly or partly weak) set that can 
be added to at run time), then suddenly Jigsaw-style module artifacts 
can coexist with other module systems without any drawbacks that I can 
see, and other existing module systems will then gain access to the 
fancy stack traces I like so much and any new access checking 
capabilities that are established.  The changes I or other maintainers 
need to make become minimal because the constraints that Jigsaw imposes 
are no longer stumbling blocks.  Whether or not this means I have to 
define a real Module becomes immaterial from an implementation standpoint.

I hope these ideas are making some kind of sense.
-- 
- DML