PRE-PROPOSAL: Source and Encoding keyword

Jeremy Manson jeremy.manson at gmail.com
Sun Mar 15 13:46:33 PDT 2009


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



More information about the coin-dev mailing list