What is a language construct?

[Alex Buckley]

On 12/23/2011 10:52 AM, Jesse Glick wrote:
> 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".

Yes, this is pretty much what the JLS needs to say. The host system 
_must_ attempt to identify a module declaration among its observable 
compilation units, and then based on the module system's interpretation 
of that declaration, make other compilation units observable. (The JLS 
only knows about Java code in compilation units, so there may be some 
finessing here to cover code in class files.)

It doesn't even have to be in the JLS. The package-info javadoc for the 
java.lang.module package would do fine. Both are part of the overall 
Java SE Platform Specification. The accessibility rules embedded in the 
JLS can refer to module system constructs (e.g. exports) whether those 
constructs are in the JLS or in the SE API.

(This is how JSR 292 is specified. The JVM Spec's text for the 
invokedynamic instruction is deeply dependent on concepts and rules 
defined in the spec of the java.lang.invoke package, because the 
instruction is fundamentally a front-end to operations on intrinsic 
types like MethodHandle.)

Note we are not yet specifying the syntax of a module declaration, or a 
physical placement of a module declaration on a file system.

> 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.

Basically yes. (I don't want to get into versioning here.)

> 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. ...

> Of course you could argue that module-info.java

Stop right there. A file called module-info.java is an implementation 
detail, not something for the spec. You should say: "Of course you could 
argue that a module declaration having Java-like syntax" ... OK, let's 
proceed.

> 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.

Again, to be fully correct: "it just means that the syntax of a module 
declaration would be specified by Jigsaw, not the JLS".

Sure, the module system could define a YAML-based grammar for a module 
declaration, and the host system would still be mandated (by text 
_somewhere_ in the Platform Specification) to find and interpret a 
module declaration at compile-time. This is where we remember there's 
another requirement, currently open, that says the grammar should use 
Java-like syntax.

Alex