Module descriptions versus module descriptors

[David M. Lloyd]

On 12/14/2015 01:43 PM, mark.reinhold at oracle.com wrote:
> 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?

No, other than if the access mode change I described separately was made.

> 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?

Yes, it will.  To clarify my position though, I don't see this feature 
as a necessary consequence of classloader-based modularity though, or 
vice-versa; I see them as independent (but mutually beneficial) ideas, 
which could already be applied to the existing module systems of today.

> 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.

I don't think it becomes any more necessary to do so than it already is 
today.  The compiler is already expected (for example) to have a 
mechanism by which it can be told where to find classes to link against. 
  I do not think that establishing the grouping of these classes is a 
large leap from that, nor even establishing "friend" relationships, for 
that matter, if that kind of thing is ultimately in the cards.

This information could even have the capability to be externalized into 
a structured configuration file - but that configuration would be 
consumed by the tooling, not the language, and more than likely it would 
be produced ephemerally at build time by a higher-level build tool like 
Maven or Gradle in the vast majority of cases (not unlike how these 
tools handle classpaths today), as they are almost always in the best 
position to establish this kind of boundary.  From discussions I've seen 
on and off various lists, I think that in this case many projects using 
such tools would quickly adopt a hybrid approach where some of this 
metadata comes from build-time/source-retention annotations, some from 
existing language structures and access directives, some from the build 
environment, and some from the expected deployment environment.

Placing this responsibility on the build tooling is also important to 
the other issues I've previously mentioned relating to mutability and 
multiplicity of the installation environment.

-- 
- DML