-encoding and -source in module-info.java

Jesse Glick jesse.glick at oracle.com
Tue Jan 24 14:07:08 PST 2012


On 01/24/2012 04:35 PM, Neal Gafter wrote:
> I agree it would be nice to place these options together in a file for the compiler to consume.  I just don't think it should be a "Java programming language
> source" file.

Well in the current Jigsaw prototype there is only one source of metadata, and that is module-info.java. Whether such a file extension/name/style is appropriate for 
module metadata is a long-running argument on the list which I did not want to get into.

> as long as it is a source file in the language, it must be subject to those
> options as well.  Which means that specifying them inside the file itself is pretty pointless.

I do not think so. It is admittedly a bit tricky with respect to encoding, but the XML spec has managed this.

>  As to the source level, what can the language specification say other than
> that "8" is the only allowed value?

It could say that it must follow a decimal-type format (which may be more restrictive than module versions), and that 1.8 is the smallest legal value; but it could 
probably just say that 1.8 is the only allowed value. (I am punting for now on whether the abbreviation "8" is legal in this context.)

>  what can the next version of the language specification say other than that "9" is the only allowed value?

I am not sure precisely how the language spec would be worded but it would say that for this revision of the spec, 1.9 is the only legal value. As to the actual compiler 
in JDK 9, it would accept either 1.8 or 1.9, and control its behavior accordingly, just as if you had passed -source on the CLI.

It is only necessary to ensure that the module-info.java token structure is not changed so radically between releases that a single file could be interpreted in multiple 
ways, which does not seem like a likely problem given that the much richer "regular" Java language token structure has not changed much since 1.0. A defense against this 
kind of change is to force the encoding and/or source level to be specified in a special simplistic header (like a pragma) at the very top of the file outside the regular 
token stream, though this would look inconsistent with the rest of the file.

Bear in mind that

<?xml version="1.0" encoding="UTF-8"?>
<čau/>

works fine; an XML parser supporting the 1.1 spec of course also reads version="1.0" files, adjusting its permitted syntax slightly according to the declared version, and 
reads the rest of the file according to the declared encoding. Similarly, HTML files can specify both their encoding and specification level in band.



More information about the jigsaw-dev mailing list