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
