PRE-PROPOSAL: Source and Encoding keyword

[Reinier Zwitserloot]

1) the 'source' keyword has absolutely nothing to do with running old  
*CLASS* files on newer VMs. Again, this is exactly like the -source  
parameter to javac. It does not have magical 'make old stuff work on  
newer VM' powers. That's not what its for. Ergo, that's not what the  
'source' keyword is for either.

2) One proposal that is in Joe's shortlist back when he announced  
project coin is a simple way to enforce 'this is an identifier', for  
example by including it in backticks. This doesn't -have- to go in at  
the same time as the source keyword (after all, even with the source  
keyword, which is trivially context sensitive, java7 will not  
introduce any new keywords. It's just opening the door to do so in the  
future. context: top of file only, otherwise its an identifier). Solve  
this problem.

3) Well, java7 source is source-compatible with java6, but if a future  
version adds a new keyword or makes another breaking change, then the  
'source' keyword is mandatory. Just like the -source 1.4 parameter was  
mandatory when you wanted to use asserts in javac 1.4. What's the  
problem with this?

4) There are tons of compelling language changes that are made far  
more compelling by breaking source compatibility. None of these  
compelling features are on the table for java7, but there's absolutely  
no reason for any language change to be an 'all-or-nothing' proposal.  
Introduce the source keyword now, so that java programmers are  
familiar with it and have already seeded their files with 'source 7;'  
- then use the freedom that comes from this in java8 and beyond.

5) The JLS would say nothing at all about it. A separate document  
lists javac versions and matching versions of the JLS. If this  
documentation doesn't exist, as Howard said: Then that's a bug in the  
documentation, because the -source parameter (which is 100% analogous  
to the source keyword) MUST be documented; it does not have an -X in  
front of it. The only thing the JLS needs to say about the source  
keyword is how it works, and what the string is supposed to represent  
(target javac version). No more needs to be said. A compatible javac  
is not forced to support compiling older sources. It will merely be  
forced to not compile any source version that it can't compile, with  
an appropriate error message. If a compiler wants to go above and  
beyond (like sun's own javac, and eclipse's ecj, and just about every  
other compiler out there) and compile it anyway, according to the JLS  
as it was for that javac version, that's great, but its not a  
requirement.




Here's the golden rule in regards to the source proposal:

It's already a part of java, via javac -source. Just about every  
problem mentioned so far is either not a problem, or if it is, should  
be filed as a bug, because it also applies to javac -source.


As I've already told Joe D'Arcy: If nobody else thinks this will  
improve java, especially for future expansion in java 8 and beyond,  
then I'm certainly not going to go through the trouble of writing out  
a full proposal. I find other proposals more worthy of cheerleading  
for. So far the overwhelming negative attitude on this forum means  
it's not going to happen. Unless someone else (Howard?) wants to run  
with it, of course. Consider this post a final effort to convince the  
coin-dev list :)

  --Reinier Zwitserloot



On Mar 15, 2009, at 21:46, Jeremy Manson wrote:

> I think there are a few problems with this:
>
> 1) If you are doing this so you can ensure that the old code will
> remain able to run on old versions of Java, this really is only half a
> solution, unless you include the APIs.  If a "source" keyword is
> introduced for this purpose, it has to be introduced at the same time
> as versioned APIs, otherwise it is useless.
>
> 2) If you are doing this so that you can evolve the language by
> introducing new keywords and maintain backwards compatibility with old
> code, then you have a problem, because these old APIs are going to be
> allowed to export the new keywords as public members.  If we add a new
> keyword "foo", and we use -source 5 so that we can have a public
> method "foo", you won't be able to use that API with -source 7 code.
>
> 3) None of the code you care about maintaining compatibility with is
> going to have the "source" annotation on it, which means that if you
> don't have the source keyword, you are going to have to assume that
> the source is Java 6.  Does this mean that Java 7 code now *requires*
> a source annotation to tell you it is Java 7?  Or do we have to go
> back and put "source 6" on all of the files that won't compile?  If we
> are doing that anyway, can't we just change the code so that it
> compiles?
>
> 4) Do we have *really* compelling language changes that actually
> require new keywords (that aren't context sensitive, like "module")?
>
> 5) Is it easy to specify what the differences are in each source
> revision?  When we add this to the JLS, what does it say, exactly,
> about what the number after the "source" keyword means?
>
> 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".
>
> Jeremy
>
> On Sun, Mar 15, 2009 at 4:30 AM, Howard Lovatt  
> <howard.lovatt at iee.org> wrote:
>> 3. When there is a reliable library dating scheme (maybe as part of
>> the modules), then the compiler could enforce this also (this would  
>> be
>> true for both -source and source in the file). Reliable library
>> management is something separate, but one in place source will be  
>> able
>> to use it.
>
> You can't really have one without the other.  The APIs are just as
> much a part of Java as the language.  If you release Java 7 and have
> people use -source 6, but allow them to use, say,
> java.util.concurrent.LinkedTransferQueue in the same code, then there
> is really no rea
>
> Jeremy
>