Compiling with automatic modules

[Stephan Herrmann]

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.

OK, to conform to JLS, a tool doesn't need to know about automatic modules,
but a "host system" must support this notion, right?
Or will vendors develop their own concepts of automatic modules?

The comparison to jar files doesn't help. Not specifying how to interpret
a jar file doesn't help standardization, but this is tolerable since the
task is trivial: the tool only needs to extract .class files from the zip.
For automatic modules the task is not trivial, since a missing module
descriptor must be generated. IMHO, a not-optimal situation in the past
cannot justify a worse situation (in terms of standardization) going forward.

An IDE cannot be expected to run on JRE 9 right now. Hence, the new API
may not be available for use in the implementation of the IDE. Thus it is
crucial to know, which parts of the API are expected to be implemented by
the IDE as part of the "host system" that drives the compiler.
The same obviously holds for any other (build) system that drives a compiler.

I still hold that the term JPMS is not well-defined. The document at
http://cr.openjdk.java.net/~mr/jigsaw/spec/ - which claims to define JPMS -
contains a link titled "Java SE Platform API Specification", but I can't
find a definition listing which parts of that API define JPMS.
What exactly is the extent of JPMS?

Stephan