Compiling with automatic modules

[Alex Buckley]

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