New issues: #CompilationWithConcealedPackages, #ResolutionAtCompileTime, & #RestrictedKeywords
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Wed May 17 18:33:56 UTC 2017
Over on the jigsaw-dev list the maintainers of the Eclipse "ecj" compiler
have recently raised several issues, which they've summarized [1]. I've
created the following JPMS issues in response:
#CompilationWithConcealedPackages [2] -- An exported class can rely on
the name of a concealed class, i.e., a class in a non-exported package,
in various ways. An exported class can, e.g., declare that it
`extends` a concealed class, or that one of its `public` methods has a
formal parameter whose type is concealed. When a compiler processes
the source code of a module M that refers to an exported class of
module N, to what degree must the compiler distinguish N's _concealed_
class (needed by N's exported class) from a class in M with the same
fully-qualified name? In other words, given that a compiler knows that
the "same" package exists in M as well as concealed in N, to what
degree must the compiler differentiate the packages? [Stephan Herrmann
[3]]
#ResolutionAtCompileTime [4] -- When a compiler processes the source
code of a module M, the JLS mandates that the compiler use the Java
Platform Module System to "resolve" M's dependences and ultimately
compute the modules that M "reads". However, the Java Platform Module
System is not specified within the JLS, but rather in the
`java.lang.module` API specification. Which parts of the API
specification have bearing on the resolution of dependences at compile
time, and where is the definition of "reads" in the API specification?
[Jayaprakash Artanareeswaran [5], Stephan Herrmann [6]]
#RestrictedKeywords [7] -- The grammar of module declarations includes
several tokens, such as `module` and `transitive`, that were
traditionally lexed as identifiers. In support of backward
compatibility, the JLS deems these tokens to be lexed as identifiers
unless they appear as "restricted keywords" in a module declaration, in
which case they are to be lexed as keywords. This rule can, however,
be difficult to implement because it is context-sensitive, and hence
beyond the capabilities of some parser generators. [Jayaprakash
Artanareeswaran [8], Stephan Herrmann [9]]
- Mark
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012524.html
[2] http://openjdk.java.net/projects/jigsaw/spec/issues/#CompilationWithConcealedPackages
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012404.html
[4] http://openjdk.java.net/projects/jigsaw/spec/issues/#ResolutionAtCompileTime
[5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012301.html
[6] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012425.html
[7] http://openjdk.java.net/projects/jigsaw/spec/issues/#RestrictedKeywords
[8] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012464.html]
[9] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012498.html]
More information about the jpms-spec-experts
mailing list