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

mark.reinhold at mark.reinhold at
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

  #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


More information about the jpms-spec-observers mailing list