hg: jigsaw/jigsaw/jdk: Remove module annotation support

[Jonathan Gibbons]

On 01/27/2012 02:29 PM, Jesse Glick wrote:
> On 01/27/2012 05:02 PM, Alex Buckley wrote:
>> It doesn't mention it because it doesn't need to. The limit of the 
>> Java language is the CompilationUnit production. A compiler is free 
>> to parse text outside that
>> production and store it in a ModuleData attribute.
>
> This is bizarre. You cannot append random text to the end of regular 
> Java source files.
>
> X.java:1: error: class, interface, or enum expected
> class X {} hello world!
>            ^
> 1 error

The difference is in the grammar, and in the curlies around 
TypeDeclaration.  After one type declaration, you can have another, and 
another, so the syntax error you are seeing comes because javac is 
trying to parse your "hello world!" text as a TypeDeclaration.  In 
contrast, there is no need for javac to read beyond the end of a 
ModuleDeclaration.

CompilationUnit:
   [PackageDeclaration] {ImportDeclaration} {TypeDeclaration}
   [ModuleDeclaration]


>
>>> how would such things be checked for syntax or
>>> semantics? How would different tools avoid clobbering each other's
>>> metadata?
>>
>> They won't be checked for syntax or semantics because they're not 
>> part of the Java language or module system. See
>> http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#extensible-module-declarations. 
>>
>
> There needs to be some convention or guideline for other tools to be 
> able to cooperatively edit such metadata. Otherwise it is rather 
> useless - you could not even tell for sure what kind of tool is doing 
> the extending and add your own separate metadata! Annotations with an 
> extension of 269 would offer fully validatable extensibility 
> consistent with the rest of the Java language, but even something as 
> simple as /([^:]+: .*\n)*/ key-value pairs (like JAR manifests) would 
> be far better than this.

One might reasonably expect that those that are interested to do so 
could reasonably establish such a guideline.  I couldn't possibly 
comment.  You could even have a doctype sort of directive, and encoding 
info even, immediately after the close curly, to describe the coding 
convention for what follows. :-)

Note: javac currently trims any whitespace between the close-curly and 
the first non-whitespace character, when it writes the ModuleData 
attribute, and does not write a ModuleData attribute if there is only 
whitespace after the close curly.