Views on JSR 376 from the Eclipse JDT team

[Markus Keller]

Views on JSR 376 from the Eclipse JDT team
======================================

Here's a high-level feedback on things the Eclipse JDT team is missing in 
the Java Platform Module System spec (JSR 376).
(This message is based on an internal note from Markus Keller but 
basically reflects the position of the whole team)

The first problem is that's it's unclear what should be the spec.

http://openjdk.java.net/projects/jigsaw/spec/ says "This is the primary 
web page for JSR 376", but the JLS9 & JVMS9 drafts linked there are dated 
2017-02-22. Lots of discussions have been going on since then, and we 
can't be expected to pick out informal answers buried in mailing list 
posts.
=> Without a complete and up-to-date spec, the only reasonable vote on JSR 
376 is "no".

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.

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.

- "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."

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.

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.

These are only the concerns from a compiler and IDE implementer's 
perspective (i.e. answers whether we can implement something given the 
specs, not whether it's the right thing to do). We don't have a clear 
position on concerns voiced by implementers of existing Java modularity 
frameworks, but we're worried that the JPMS may not be suitable as a basis 
for those frameworks.

Regards,
The Eclipse JDT team