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
