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

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