PRE-PROPOSAL: Source and Encoding keyword (original) (raw)

Howard Lovatt howard.lovatt at iee.org
Wed Mar 18 03:10:17 PDT 2009

Hi,

2009/3/16 Jeremy Manson <jeremy.manson at gmail.com>:

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.

I don't see this, it is a separate issue tracking API versions. If the new API is compatible with the old then the old code still works with the new API and using the new compiler. The old code doesn't have a source statement and is therefore recognised as old code and therefore compiles exactly like it did with the old compiler. For the new code, which has a source statement, the compiler enables the action associated with the new constructs.

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.

Already part of coin is exotic identifiers that allows J7 to access any valid name in the JVM. This is to support other languages that might have a different set of valid names. However the same mechanism would allow you to call an API that uses the new keyword, just like it can call an API that uses an existing keyword as a name.

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?

If you want a new J7 feature that isn't in 6 then you have to put source Java7 (or whatever is decided) at the start of that file

4) Do we have really compelling language changes that actually require new keywords (that aren't context sensitive, like "module")?

Depends what is decided for coin. The main argument is however that you are positioning for the future. For example, if we did add source then perhaps we could change switch to be block structured at some point in the future.

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?

Java has already evolved and there are multiple releases of the JLS. So one possible way to specify the changes is to say for files without a source statement see the JLS ed. 3 (I think 3 is the latest). Then you describe the new language in J7LS ed. 1 - note 7 in the title.

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".

I think one of the reasons that Java is tending to stagnate a little, not badly, just a little, is that it is getting hard to introduces changes. I think source will provide a relief valve - get out of jail free.

Cheers,

Howard.

More information about the coin-dev mailing list