PRE-PROPOSAL: Source and Encoding keyword

[Howard Lovatt]

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.