PRE-PROPOSAL: Source and Encoding keyword

[Reinier Zwitserloot]

Neal:

As I've mentioned at least twice on coin-dev already, the JLS only  
needs to specify how the 'source' keyword sets the 'source' property  
of the CompilationUnit that contains the source keyword. As far as the  
JLS is concerned, this is a string value that has no further meaning.  
It's a bit like a comment in this sense. To be crystal clear: ** The  
JLS will NOT specify what is supposed to happen when you write "source  
1.1;" in a JLSv3 view of the source file! **

The effect of a source property in a CompilationUnit will however be  
specified in the documentation for java compilers.

Jeremy:

1) No, -source does not show up in the class file at all, so obviously  
it wouldn't for a source keyword, either. Therefore the API /  
Classfile compatibility issue is 0.

2) No, backticks aren't neccessary for the source keyword to work.  
java7 is not going to be source incompatible with java6 and does not  
add new keywords (well, module, but it'll be context sensitive).  
Compatibility issue: 0. It would certainly help make it easier to make  
breaking changes in java 7, if at that time a proposal comes along  
that makes sense but would be better with a few breaking changes.

3) There is no need for much *JLS* documentation at all.  
CompilationUnits get a 'source' property, which is a string value.  
That's where it ends as far as the JLS is concerned. It has no meaning  
within the JLS. Just a string, that's all. The documentation for javac  
has quite a bit to say about this, but that's nothing new: The -source  
parameter has the exact same function and is already documented. This  
documentation needs a very minor update.

4)  "source 1.7;" is really neccessary at the top of the file. It is  
crucial meta-data without which you cannot make any sense of a java  
CompilationUnit. Is 'assert' a keyword or an identifier? What about  
strictfp? Are inner classes legal? Is @Override on an interface- 
inherited method legal, or an error? Should lack of generics result in  
a warning, or should any generics actually be indicated as a compile- 
time error? You don't, of course, -have- to put it there, but its  
suggested, and I expect IDEs and style checkers will start warning  
when its missing. This is somewhat akin to package statements. Those  
are -really- neccessary as well. a CompilationUnit's target package  
isn't a command line parameter for the same (good) reason. This  
metadata is not dependent on a compile run, it is solely dependent on  
the source file itself, and should therefore be inside it.

  --Reinier Zwitserloot



On Mar 16, 2009, at 00:58, Jeremy Manson wrote:

> Reinier,
>
> I wrote out a long response to each of your points, but I realized
> that perhaps what it boiled down to was something I said in my
> previous message: "I'm not objecting to versioning in principle, but I
> think there are enough unanswered questions that this proposal is
> probably beyond the scope of "small changes"."
>
> You are saying that if I have a problem with something, it is the
> -source flag.  You are absolutely right: I have problems with the
> -source flag.  Those problems should be sorted out before we include
> it in the language.  Each solution to each of these problems makes
> this change larger:
>
> 1) API / Classfile compatibility
>
> 2) Backticks for identifiers
>
> 3) A need for thorough documentation for each potential version we
> support.  (You seem to be suggesting that this would be
> implementation-dependent, but that's unlike everything else in the
> language.  Java is historically opposed to things that are
> implementation-dependent.  Part of the selling point of Java is that
> code written for / compiled on a version of Java 7 will work with /
> compile on all compliant Java 7 implementations.).
>
> 4) Is "source" really necessary at the top of the file (you seem to be
> agreeing that it is), and if so, is that what we actually want?
>
> I also think it would be worthwhile finding out how this proposal gels
> with the module system they are introducing.
>
> Fundamentally, it seems to me to be a large problem to solve, and I
> think the right answer is to start a proper JSR and make sure you get
> it right.
>
> It is, of course, by no means important to Project Coin that I (as one
> person) happen to think that this change is (or should be) too large.
> But I suspect that I'm not the only one.
>
> Jeremy