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

Reinier Zwitserloot reinier at zwitserloot.com
Sun Mar 15 14:31:22 PDT 2009

  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;'

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

More information about the coin-dev mailing list