Views on JSR 376 from the Eclipse JDT team

[Stephan Herrmann]

Alex,

I appreciate your answers to our questions, which give hope
that a future version - incorporating all this - will be sufficient
for defining what is Java 9 from a compiler's perspective.

The post sent by Markus explicitly refers to the specification
as it was submitted for public review, which is not sufficient
in several regards.

I see two reasons for insisting in this distinction:

It is necessary to call out that JSR 376 is again behind schedule,
putting third party implementors under extreme time pressure,
to the degree that a compliant implementation may not be possible
on the currently scheduled release date.

Only once we hold in our hands a specification that has all the
missing parts integrated and that has passed some level of QA,
it is possible to confirm whether all the pieces fit together
in a coherent, consistent and sufficient way.

(This is my personal view as an individual contributor to Eclipse JDT)

Stephan

On 05.05.2017 22:22, Alex Buckley wrote:
> On 5/4/2017 11:51 AM, Markus Keller wrote:
>> The other big thing is that the JLS draft specifies the syntax of the
>> module-info.java file, but it is quite vague about the semantics of
>> modules.
>>
>> JLS9 12 "Execution" explains how class loading is supposed to work in the
>> JVM, but it's unclear how modules and and their access restrictions should
>> come into the picture here. Layers are not even mentioned anywhere. Before
>> Java 9, classloading and discovery of .class files was only a run-time
>> concern. During compilation, the assumption was that  all dependencies are
>> available and accessible from a flat source-/classpath.
>> => Since a Java compiler is now also supposed to check access restrictions
>> imposed by module declarations, the JLS also needs to specify this in
>> depth, or it at least needs to point to JavaSE-9 APIs that contain the
>> necessary specifications. See e.g. Stephan Hermann's questions about the
>> meaning of a qualified name.
>
> Chapter 12 of the JLS contains a variety of material:
>
> - 12.1, 12.2, and 12.3 cover run time behavior, not compile time behavior, so I'm not sure why the Eclipse compiler relies on these
> sections. For example, layers are not part of the Java language so there is nothing to mandate about them for a compiler. Looking
> forward, there are enhancements to the corresponding JVMS9 sections (5.2 and 5.3) which may yet result in enhancements to these JLS
> sections, but that is "editorial"; it will not affect the behavior of a compiler.
>
> - 12.4, 12.5, and 12.6 are normative for a compiler but are unrelated to the module system.
>
> - 12.7 and 12.8 are normative but for a JVM implementation not a compiler.
>
>> Some examples:
>> - "The ordinary compilation units that are visible to M are the
>> observable ordinary compilation units associated with modules read by M.
>> The host
>> system must use the Java Platform Module System to determine which modules
>> are read by M (§7.7.1)."
>> => Neither "read" nor "Java Platform Module System" are specified
>> anywhere.
>
> This was raised in the jigsaw-dev thread "Java Platform Module System" [1] and discussed at length there. The Java Platform Module
> System is as much part of the Java SE Platform as the Java language, so the Java Language Specification is able to depend upon the
> specification of the Java Platform Module System (which happens to be presented in API form rather than as a narrative document).
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012301.html
>
>> - "An implementation of the Java SE Platform must keep track of types
>> within
>> packages by the combination of their enclosing module names and their
>> binary
>> names (§13.1). Multiple ways of naming a type must be expanded to binary
>> names
>> to make sure that such names are understood as referring to the same
>> type."
>> =>What should happen if there are multiple types with the same binary name
>> but different enclosing modules? Can they coexist or is this a compile
>> error? JLS9 7.6 "Top Level Type Declarations" doesn't mention modules when
>> it says: "It is a compile-time error if the name of a top level type
>> appears as the name of any other top level class or interface type
>> declared in the same package."
>
> This was discussed in the same thread, and I made concrete suggestions for how to clarify the matter [2].
>
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012488.html
>
>> Such things are relevant if you want to write a compliant compiler.
>>
>> E.g. JLS9 7.7 "Module Declarations" informally talks about "the
>> modulepath" and "automatic modules", but neither of these concepts are
>> explained any further. Automatic modules, unnamed modules, and their
>> semantics must be specified in the JLS. The outdated
>> http://openjdk.java.net/projects/jigsaw/spec/sotms/ has some more
>> explanations, but since this is not part of the spec, it's irrelevant for
>> a vote on JSR 376.
>>
>> => The JLS must either be self-contained or it must link to relevant other
>> documents that are declared as equally dependable parts of the spec.
>
> This was discussed in the same thread, and appeared to be clarified [3].
>
> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012425.html
>
>> The grammar for the module-info.java with its "restricted keywords" is
>> highly problematic, since the language it defines is not processable by
>> established compiler technology. Hacks are possible, but they are costly
>> and prevent established error recovery techniques from working.
>
> This was discussed in the same thread, and appeared to be non-blocking for JDT [4]. The JLS has not guaranteed for many years that
> the grammar of the Java language is aligned with the capabilities of pre-existing tools. I recall that parsing lambda expressions
> presented a similar kind of challenge to JDT, and that admirable solutions were found [5].
>
> [4] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012500.html
> [5] https://www.eclipsecon.org/na2014/session/jdt-embraces-lambda-expressions.html
>
> Alex