Module descriptions versus module descriptors

[mark.reinhold at oracle.com]

2015/12/10 7:02 -0800, david.lloyd at redhat.com:
> On 12/09/2015 07:26 PM, mark.reinhold at oracle.com wrote:
>> If module boundaries, however they're expressed, are to be enforced by
>> the compiler and the VM -- as you've agreed elsewhere -- then their
>> manner of expression is inevitably going to be a topic for the Java
>> language and VM specifications.  This is not avoidable.
> 
> Actually that does not logically follow.  I could, for example, 
> "express" module boundaries in the VM by creating a hard equivalence 
> between modules and class loaders, and in the compiler via command-line 
> arguments.  In this way, no langauge or VM specifications must change; 
> in fact only the specification of the compiler tool itself *must* 
> change.

If every module is represented at run time by a unique class loader, then
would the VM to do anything differently than today?  Would it have any
role at all to play in enforcing module boundaries, regardless of their
means of expression?

If we widen the default access mode to mean module-private in some
circumstances, as you suggest, then wouldn't that require revisions to
the VM and language specifications?

If module boundaries are communicated to the compiler via command-line
flags, then how do you propose to make all Java compilers work in the
same way?  Bear in mind that there is no specification for the compiler
as a tool -- there is only the Java Language Specification, which to date
has never mandated any particular command-line flags, nor even the
existence of a command line upon which to place such flags.

- Mark