I'm wondering what will be expected from a compiler for Java 9.
I hope this is a suitable place to ask this kind of questions.
The first thing we know: a compiler has to be able to translate
module-info.java (or whatever that file's name may be - btw: in absence of a
definite rule, is a compiler expected to find module declarations in files of
any possible name?).
My first question concerns the grammar of module declarations:
I don't think the definition of "restricted keywords" and javac speak the same
language. The only thing I can definitely infer from lang-vm.html is:
restricted keywords are keywords only inside a module declaration (btw: how
does the parser know, it's inside a module declaration?). By contrast javac
implements a much more permissive strategy, almost s.t. like: "they are only
keywords when they are keywords, otherwise they are identifiers". To wit,
javac's parser happily accepts this declaration:
module module { // second word is an identifier
requires requires; // second word is an identifier
exports to to exports; // words #2 and #4 are identifiers
uses module; // second word is an identifier
provides uses with to; // words #2 and #4 are identifiers
}
This is not only very weird, there are lots of terminals in a module
declaration where a restricted keyword is accepted as an identifier. It also
breaks with standard compiler technology: it doesn't seem to be possible to use
a traditional pipeline of scanner & parser, if the scanner cannot decide the
kind of a token without consulting the parser (or keeping part of the parser
state in the scanner itself).
This is to say: the strategy implemented by javac will affect all tool
providers, not only compilers, but also editors etc. In absence of a stateless
scanner, even syntax highlighting may not be possible without a full parser.
Parsing in the presence of syntax errors (to offer IDE functionality on
work-in-progress files) becomes close to impossible.
Have these consequences been carefully weighed?
The next area where compilers will have to change is the new semantics of
"accessible". Clearly, rules like JLS 6.6.1. (Determining Accessibility) and
JLS 8.4.8.1. (Overriding (by Instance Methods)) need to be changed.
Has any of this work started yet? Can we have a look at any drafts?
Next, I wonder, how much additional static validation compilers should perform.
For one, SOTMS speaks of "reliable configurations". Are compilers expected to
check these rules? If so, have they been spelled out in checkable form
somewhere (e.g., what is the meaning of "interfere" in the sentence "modules
defining identically-named packages do not interfere with each other")?
Secondly, the concept of modules makes it possible to create new forms of "API
leaks": expose a type, whose public signatures mention inaccessible types -
maybe inaccessible only to some consumers. If you add overloading to the mix,
this can create ugly effects, which may defeat benefits of modularity.
Is it planned that tools will help users to avoid such bogus situations? Or at
least gracefully handle the case when it occurs?
Obviously, some validity constraints can be checked by tools other than the
compiler, like linker or VM, but defining a module system as part of the
language bears the unique opportunity to provide the most immediate feedback to
users. Will this opportunity be used?
Other concerns are more of an organizational kind:
What modules must be present to compile a given module? Is the set of (implied)
readable dependencies sufficient, or is the compiler required to look at the
full transitive closure?
Users coming from a plain-classpath world, may not expect much sophistication,
but introducing a module system bears the unique opportunity to avoid the
situation where building just one module triggers the download of huge amounts
of transitive dependencies ("downloading the internet").
Which is to say: Java 9 has the chance to significantly reduce the resource
requirements (bandwidth, storage, main memory, compile time) for compiling any
given module.
Any attempts in this direction seem to require a fresh look specifically at the
interaction of accessibility and overloading. Has anything been
planned/discussed in this direction?
In Java 8, any package-qualified type name is sufficient for identifying a type
during compilation. Will the same assumption also hold for compiling Java 9, or
is a compiler required to distinguish identically named types from different
modules? While this seems to be a question of compiler implementation only, it
also seems the answer depends on answering most of the above questions, like
additional static validation, the need to look at the transitive closure of
module dependencies etc.
Most importantly, for implementing a compiler for Java 9 this question implies
a very fundamental design decision, that should be made before any other
changes towards Java 9. Changing a compiler implementation from package.type
names to module.package.type names is a huge change that cannot be implemented
as a quick after thought.
Have any amendments to JLS chapter 6 been drafted to define the new
requirements for a compiler regarding qualified names?
regards,
Stephan
