New issues: #CompilationWithConcealedPackages, #ResolutionAtCompileTime, & #RestrictedKeywords

[mark.reinhold at oracle.com]

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]