PRE-PROPOSAL: Source and Encoding keyword
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
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;'
- then use the freedom that comes from this in java8 and beyond.
5) 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
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 :)
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
> 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".
> 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
>> true for both -source and source in the file). Reliable library
>> management is something separate, but one in place source will be
>> 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
More information about the coin-dev