-encoding and -source in module-info.java

[Alex Buckley]

On 1/25/2012 7:47 AM, Jesse Glick wrote:
> On 01/24/2012 08:08 PM, Alex Buckley wrote:
>> Compilation units in the Java programming language consist of UTF-16
>> code units.
>
> Of course. That is a character set, not an encoding.

Certainly UTF-16 is an encoding. Recall the difference between code 
points and code units.

> Perhaps not; theoretically a compiler could be loading sources out of a
> database that provides Unicode strings natively. But javac invoked from
> the command line always works on files, and these have a definite layout
> in the filesystem - including $root/module-info.java - and must have a
> specific encoding. This means that a directory tree representing sources
> for a Java module has an unambiguous meaning in the Java language only
> if something in that tree declares the encoding. That would suggest
> something like $root/encoding containing the (ASCII-encoded) name of the
> encoding.

All those things are implementation details and so don't belong in a 
module declaration as defined by the JLS. (This applies regardless of 
the syntax used for a module declaration.)

> Alternately, require modular Java sources to use a standard encoding,
> presumably UTF-8, as modern languages are tending to do.

Again, there is no desire to change the JLS to support encodings of 
Unicode other than UTF-16.

> (Or java.boot?) This is an interesting option newly available with
> Jigsaw - basically to tie the source level (and I suppose the target
> level) to that supported by the platform itself. This is a sensible
> enough default; the question is whether some modules may still need to

We are well aware of these interactions.

> You are still left with the problem of a module which declares no
> explicit platform dependency: some default value must be used for the
> source level, and changing this default according to which version of
> javac happens to be used to compile it is a very bad idea.

If there's no explicit java.base dependence, Jigsaw specifies an 
implicit dependence on the "current" platform's API (java.base). javac 
will continue to assume the "current" platform's language level, so 
there's a match.

Alex