On 5/30/2017 2:08 PM, Jochen Theodorou wrote:
On 30.05.2017 21:42, Alex Buckley wrote:
On 5/26/2017 4:12 AM, Jochen Theodorou wrote:
On 26.05.2017 01:04, Alex Buckley wrote: [...]
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.)
Isn't the consequence that I can write a compiler which does only
allow named modules?
You mean a compiler that understands named module and does not
understand unnamed modules?
actually I was wondering more about automatic modules and inexact in
my question.
No, per JLS 7.7.5: "An implementation of the Java SE Platform must
support at least one unnamed module." The mandates for unnamed
modules in 7.7.5 are essentially identical to the historical
mandates for unnamed packages in 7.4.2.
""" An implementation of the Java SE Platform must support at least
one unnamed module. An implementation may support more than one
unnamed module, but is not required to do so. Which ordinary
compilation units are associated with each unnamed module is
determined by the host system.
The host system may associate ordinary compilation units in a named
package with an unnamed module. """
OK, from this I understand there must be at least one unnamed module.
Nothing about automatic modules.
Correct. Automatic modules are named modules known to the JPMS, just
declared implicitly by the JPMS rather than explicitly in the Java
language. Where a named module IS declared explicitly in the Java
language, it may reference, in its 'requires' directives, any other
named module known to the JPMS, regardless of whether that other named
module is declared implicitly or explicitly.
What comes after that is a bit confusing to me. Could I for example
say that only compilation units, that declare to be part of a package
with the name "unnamed" will be part of the unnamed module?
Yes, the host system can choose to associate those compilation units
with an unnamed module if it wishes. See JLS9 7.2 and 7.3, paying
attention to the flexibility granted for ordinary compilation units (the
ones in your paragraph) versus no flexibility for modular compilation units:
-----
Each host system determines which compilation units are observable in a
particular compilation (ยง7.3). Each host system also determines which
observable compilation units are associated with a module.
...
The host system also determines which observable ordinary compilation
units are associated with a module, except <<java.* stuff>>.
The host system must determine that an observable modular compilation
unit is associated with the module declared by the modular compilation unit.
-----
I mean, I understand that the "which" refers to the way the files are
given to javac... But it feels like the JLS allows here many other
variants as well.
Correct. The JLS is a language spec, not a compiler spec. With the
exception of the rule for 'public' types in 7.6, the JLS has
historically imposed very few constraints on a compiler ("host system").
Alex
