Compiling with automatic modules

[Alex Buckley]

On 5/23/2017 1:47 PM, Stephan Herrmann wrote:
> On 23.05.2017 22:30, Alex Buckley wrote:
>> Automatic modules are not a source artifact, so their specification is
>> found in the API portion of the JPMS spec rather than in the JLS. The
>> JLS has traditionally not specified how a compiler interprets
>> non-source artifacts, e.g., the JLS says nothing about whether the
>> host system understands a "class path" or that such a thing might
>> identify non-source artifacts like JAR files. The analog in the Java
>> SE 9 era is that it's up to a compiler to choose to support a thing
>> called the "module path" and to identify non-source artifacts on it; I
>> do not see how the JLS can say anything for that. Once a compiler has
>> made the choice, then the JPMS specifies that certain non-source
>> artifacts must be interpreted as automatic modules, at which point
>> they're "just" named modules that a modular compilation unit's
>> 'requires' directive can refer to.
>
> There's a decisive difference: for .class files (in the file system
> or in a .jar) the compiler "knows" what it means, because .class
> files are well in the realm of compilers. There are no hidden
> semantics.

I agree that JLS 13.1 mandates a compiler to have detailed knowledge of 
.class files, but I do not agree that the JLS mandates a compiler to 
understand JAR files. It is merely convention that motivates a compiler 
to (i) understand a thing called "classpath" and (ii) open JAR files 
thereon in search of .class files. In Java SE 9, the analog of (i) 
remains -- it is convention that a compiler understands a thing called 
"modulepath" -- but we go beyond convention for (ii) -- JPMS resolution 
actually specifies that observable JAR files without module-info.class 
declare automatic modules. So, assuming that a compiler has a way to 
observe JAR files in the first place, JLS 7.3 specifies that 'requires 
M' in a modular compilation unit triggers JPMS resolution to read a 
module called M, and JPMS resolution will abstract away whether M is an 
explicit module (observed in M.jar with module-info.class) or an 
automatic module (observed in M.jar [or Foo.jar with 
Automatic-Module-Name: M] without module-info.class).

> A jar-as-automatic-module has semantics that are not known to the compiler,
> unless JLS specifies s.t. to this end.

The semantics of an observed JAR without module-info.class are specified 
as part of JPMS resolution, and JLS 7.3 explicitly defers to that, so I 
believe it is clear how a compiler must behave when a modular 
compilation unit 'requires' a module that turns out to be automatic. (Of 
course a big part of the migration story is that the requirer is unaware 
of whether the requiree is automatic or explicit.)

Alex