What is a language construct?

[Jesse Glick]

On 12/23/2011 11:59 AM, Alex Buckley wrote:
> to align the language with the module system, the scope
> of observability will grow to encompass module dependences
> and the scope of accessibility will grow to encompass module exports.

I fail to see how the tradition of the JLS forces such a system to represent modules directly in Java source files. Following the style of chapter 7, the JLS could simply 
say something to the effect of:

- A host system may group compilation units [or types?] into sets called "modules". The host system must then determine which other modules are observable from a given 
module, and may specify that some types [or packages? or individual elements?] within those modules are to be considered inaccessible despite the other provisions in the 
section "Access Control".

JSR 199's JavaFileManager would need to provide a way to specify module identity, observability, and accessibility. At runtime, java.lang.module would define opaque 
module identifiers with no details such as version, just informational toString() and a boolean hook for the VM to conduct its access checks; and permit 
ClassLoader.defineClass to pass a module identifier.

Then it would be up to the javac command line and the module-aware Java launcher to interpret a physical format of modules - which could, for example, be based on JARs 
with special manifest attributes defining Jigsaw semantics. Alternate 199-based build tools and java.lang.module-based runtime containers could just as easily interpret 
OSGi or various other existing formats, or some hybrid system capable of hosting and cross-wiring multiple containers; unlike with older JDKs, they could benefit from 
compiler- and runtime-enforced module accessibility checks.

For that matter, a Maven plugin could easily produce a Jigsaw-compatible binary using a natural POM to determine observability (from <dependencies>), as well as other 
module metadata (from <artifactId>, <version>, etc.), with either plugin <configuration> or source annotations to determine other information such as exports. Making a 
Jigsaw plugin would be awkward under the current proposal, as it would need to either create target/generated-sources/jigsaw/module-info.java in the generate-sources 
phase; or (like Tycho?) inject dependencies dynamically by parsing src/main/java/module-info.java, breaking many popular workflows and complicating IDE support.

Of course you could argue that module-info.java as currently proposed is simply more readable than manifests and is what Java developers want, especially those who use no 
IDE or build framework or module system currently. That does not preclude the above approach - it just means that the syntax of module-info.java would be specified by 
Jigsaw, not the JLS, and could just as easily be module.yaml.