[I know this is coming way too late, and my recent accident that incapacitated me for several week didn't help either. Nevertheless, I think the current module-info.java syntax was a snap decision that should not end up in the Java 9 spec.]
The discussions about restricted keywords http://openjdk.java.net/projects/jigsaw/spec/issues/#RestrictedKeywords and the difficulties with defining a proper grammar for module-info.java indicate that something could be fundamentally wrong with the chosen approach that tries to come up with a new way of specifying a language. What module-info.java tries to achieve is to: - declare a module name - declare properties of the module, thereby referencing other modules, packages, and types For such simple declarative configuration descriptions, Java already has a sub-language: Annotations. The annotation syntax can be used to express all the properties of a module, and "@package" could be used as keyword to introduce a ModuleDeclaration like this: ModuleDeclaration: {Annotation} @package Identifier {. Identifier} ; This approach has huge advantages over the proposed new language: - completely solves all the problems related to restricted keywords and hardly parseable grammars - can be adopted by existing tooling very easily, and in most cases already works out of the box (syntax coloring, code completion, refactorings, search) - syntax is already understood by every Java developer: no new language to learn - doesn't require all the new class file attributes - has a proven built-in story for evolution of the module-info syntax The slightly more verbose syntax is not an issue in practice. The number of module-info.java files is negligible compared to other compilation units, and the fact that nobody has to learn a new language is more than enough to justify the few more characters. The "value=" in NormalAnnotation nodes looks a bit cumbersome, but this can easily be fixed in Java 10, e.g. by enhancing the general annotation language to make "value=" for the first annotation element optional, or by declaring the order of AnnotationTypeElementDeclaration declarations as relevant, and then allowing users to use unnamed ElementValues (positional arguments, like in method invocations). In this proposal, "@package" is to be pronounced as "module". That's not specially nice, but its precedent "@interface" that stands for "annotation" was not a problem either. Here's an example that compiles with the current annotation syntax (XXX comments indicate proposed improvements): //======================================= /** * Defines the Java API for JAX-WS. * * @since 9 */ @Deprecated(since="9", forRemoval=true) // XXX: value should be a qualified module name (without quotes): @Requires(value="java.activation", as=RequiresAttribute.TRANSITIVE) @Requires(value="java.xml", as=RequiresAttribute.STATIC) @Requires("java.xml.bind") @Uses(javax.xml.ws.spi.Provider.class) @Uses(javax.xml.soap.MessageFactory.class) // XXX: value should be a qualified package name (without quotes), or a // "package literal", that would look similar to a class literal, // but would end with ".package" instead of ".class" @Exports("javax.jws") // XXX: @Exports(javax.jws) or @Exports(javax.jws.package) @Exports("javax.jws.soap") @Opens(value="javax.xml.ws.wsaddressing", to="java.xml.bind") @Exports(value="com.oracle.webservices.internal.api.databinding", to="jdk.xml.ws") @Exports(value="com.sun.xml.internal.ws.addressing", to= {"jdk.xml.ws", "java.xml.bind"}) @Provides(value=java.nio.file.spi.FileSystemProvider.class, with=jdk.internal.jrtfs.JrtFileSystemProvider.class) //XXX: actually: @package java.xml.ws; package java.xml.ws; import java.lang.module.Exports; import java.lang.module.Opens; import java.lang.module.Provides; import java.lang.module.Requires; import java.lang.module.RequiresAttribute; import java.lang.module.Uses; //======================================= Regards, Markus
