Annotation-based syntax for module-info.java

[Markus Keller]

[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