I had this same thought a week or so ago and I wouldn’t be surprised to see someone create a framework that generates a module-info.java from annotations. But that doesn’t solve the issues I have hit, which all stem from module-info.class conflicting with pre-java 9 tools. Frankly, I don’t know why module-info.java and package-info.java are “real” java files since they really contain meta-data. Things would work much better if these were json files or something else. package-info.java seems especially silly since the Java compiler seems to ignore these files unless you tell it not to (and the compiler doc mentions that it will let you create the class files just to make Ant happy that there is a matching class file for every source file).
Ralph > On Jun 12, 2017, at 6:26 AM, Markus Keller <markus_kel...@ch.ibm.com> wrote: > > [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 > > >
