Compiling with automatic modules

[Jochen Theodorou]

ok, thanks for the answers

On 30.05.2017 23:43, Alex Buckley wrote:
> 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