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
