Views on JSR 376 from the Eclipse JDT team

[Alex Buckley]

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