-encoding and -source in module-info.java

[Jesse Glick]

On 01/25/2012 02:16 PM, Alex Buckley wrote:
> All those things are implementation details and so don't belong in a module declaration as defined by the JLS.

Then the encoding needs to be specified somehow in the source root outside of a module declaration (such as my proposed $root/encoding file). I do not really care whether 
the JLS ever mentions it or not, so long as javac interprets disk files with a predictable encoding - so that all Java language tools which operate on files (*) will be 
able to parse a given module source tree the same way. Currently they need out of band information to do so, and that is a significant problem.

>> Alternately, require modular Java sources to use a standard encoding,
>> presumably UTF-8, as modern languages are tending to do.
>
> there is no desire to change the JLS to support encodings of Unicode other than UTF-16.

The representation of surrogate code points using 16-bit code units is not what I am discussing. The "alternate" proposal was for disk files to be unconditionally 
interpreted by command-line javac as being in UTF-8 format, as if '-encoding UTF-8' were passed to an earlier version of the tool. Obviously this is meaningless for the 
hypothetical case discussed in the JLS of a program stored in a database, or the more practical case of a program using JSR 199 and providing a FileObject that supports 
only a Reader and not an InputStream.

> If there's no explicit java.base dependence, Jigsaw specifies an implicit dependence on the "current" platform's API (java.base).

This is bad since it makes the interpretation of the source module dependent on the context in which it is interpreted. Among other problems, if the language level is 
inferred from the version of the platform, using a different contextual platform than the original author intended could mean that the exact same source module not only 
_behaves_ differently when run (which is to be expected) but _parses_ differently as well.


(*) Or sources otherwise grouped in the conventional way and potentially accessible via java.nio.file.FileSystem, such as inside a ZIP.