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

Reply via email to