Reference implementation
Reinier Zwitserloot
reinier at zwitserloot.com
Fri Oct 30 19:40:50 PDT 2009
You keep asserting that 'source' is a major feature update, and I keep
telling you that you're wrong. I'm forced to keep pointing out that
'source' doesn't have a big impact on the size of the JLS.
the notion of source version isn't part of the JLS spec, but that's
not a problem. The JLS chapter on the source keyword merely needs to
explain its format and how it's context sensitive (as it must appear
at the top of the CU, this is easy). It should probably include a
footnote on what the source property is generally used for, but it
doesn't have to.
There's precedent for this of course: Last time I checked, the javadoc
tool's documentation isn't part of the JLS, and yet javadoc are things
that appear in java source files.
It does not even need to define what a compatible java compiler should
do in the face of a source keyword. It merely needs to state that a
compiler MAY fully support them and compile each file accordingly, but
a compiler may also simply refuse to compile the file if its not a
version the compiler is aware of. The only added requirement is that a
java compiler may not compile a source file without at the very least
emitting a warning if the source property isn't something it can deal
with.
Turning to the pragmatic for a moment:
Either the concept of 'source' is obvious to java programmers (which I
assert), or, if it isn't, the -source property should be removed from
javac for being confusing. I've never heard any complaints, so real
world experience indicates Joe Q. Coder can deal with it.
Current javacs can already support older versions via the -source
parameter, so presumably mixing codebases isn't difficult. If for
whatever reason it actually is, the next version can start out by
locking down the version the first time it encounters a source
statement, and aborting with an error if a different one shows up in
the same compile run. Experience will dictate the future fate of mixed
compilation: If loads of folks complain about the cool things they
could do if only mixed compilation works, it's worth investing some
time in, and if not, then not. Real world experience beats guesswork
by language designers every time.
Complicating migration isn't really a fair argument. Three options:
1. v(X+1) is fully backwards compatible anyway. Consider the versions
aliases then, as far as the compiler is concerned. Or, include a tool
in the JDK's bin dir that simply updates the version number. By
definition, this can't cause problems.
2. v(X+1) is almost but not entirely fully backwards compatible. By
definition, then, a new feature has been included that would have been
a much bigger deal without the source statement, so if we ever get
here, the source statement has already proved its worth its weight in
gold. A migrator tool in the JDK bin dir can update a source tree,
highlighting (or automatically fixing, even) the rare cases where vX
code is no longer legal (or does something different in) v(X+1) code.
3. v(X+1) is not backwards compatible. Presumably v(X+1) is then a
major update, akin to v1.5 over v1.4, but making _actual_ breaking
changes has still become a much easier proposal, and a migrator is
still much easier in this scenario: if a certain code snippet is legal
in vX and also legal in vX+1 but has a different meaning, a source
migrator without source keywords can't tell if a source file is pre-
or post- change, and thus, if you run it twice on the same file, you'd
break stuff. That would be bad. The existence of the source keyword
has made this big change possible, whatever it is, so clearly it is
again worth it.
Thus, either (A) the impact is negligible, or (B) it makes possible an
update that wouldn't have been possible without it.
Examples of how a source keyword + a migrator would have been useful
for JDK7:
Making module a non-context-sensitive keyword would be trivial: The
updater finds any usage of 'module' as an identifier, and tosses back-
quotes around them. caveat: Java adds a rule that backquotes indicate
identifiers, but given that there are other languages on the JVM that
for example accept something like "+" as a valid identifier, this
seems like a smart plan anyhow. 'module' as an identifier is pretty
rare, so even without the backquotes, a migrator can simply tell you
about them.
Complaints about 'try' not being an appropriate keyword for ARM would
be easier: A new keyword could have been added for it instead.
Concerns about simple vs. complex vs. full-complex would be much less
urgent: It seems that the cases where they are incompatible are either
non-existent, or otherwise quite rare, so a migrator can easily
identify where it happens and manually add explicit generics into the
diamond operator to fix the problem, without turning someone's source
into an unrecognizable mess. You yourself quite rightly consider
future language flexibility an important thing to keep in mind. A
source keyword is quite a big deal when you take future flexibility
into consideration.
--Reinier Zwitserloot
On 2009/30/10, at 14:48, Neal Gafter wrote:
> Howard-
>
> Let me recap the conclusions as I recall them.
>
> Your parallel with WiFi breaks down; your proposal for a source
> declaration
> would be an enormous change to the specification; the change would
> be a tiny
> benefit (if any).
>
> The parallel with WiFi breaks down because software, by its very
> nature,
> evolves. While wireless devices are generally fixed once
> manufactured, any
> given program is likely to undergo extensive changes over its
> lifetime. One
> of the main purposes of changes to the Java language is to make such
> program
> evolution easier by providing further facilities for programmers to
> use.
> But if a prerequisite to using language features in version 8, for
> example,
> requires modifying your source code remove or refactor the use of
> features
> that are no longer supported (e.g. wildcards, presuming we come up
> with an
> alternative that is migration-compatible), it could become an enormous
> burden to use any new features in existing code. One might as well
> give
> version 8 a new name (e.g. Scala).
>
> It is an enormous change because, by moving the version
> specification into
> the realm of the language, the language specification must provide a
> precise
> meaning to any given value of the version string. That means it must
> incorporate a full specification for all of the supported versions.
> In
> addition, it must specify the meaning of programs composed of a
> mixture of
> source file versions. While that kind of specification would be
> useful
> today, it is not required as part of the language specification, and
> it is
> not provided in the JLS. I can easily imagine that would double the
> size of
> the JLS. Clearly, that is far outside the scope of project Coin.
>
> Finally, the proposal would only be of the smallest benefit. All of
> the
> issues we've been wranging with for each of the proposed language
> features
> still has to be addressed. We still have to consider backward
> compatibility
> if we want programmers to be able to use these features *in the
> context of
> an existing code base*. So adding that enormous work item to
> project coin
> would not reduce the amount of work for any of the individual
> features under
> consideration.
>
> In short, a version declaration is neither a silver bullet, nor a
> solution
> to any problem we've been struggling with.
>
> Cheers,
> Neal
>
> On Fri, Oct 30, 2009 at 2:06 AM, Howard Lovatt
> <howard.lovatt at iee.org>wrote:
>
>> Joe,
>>
>> As I recall the discussions on source, for that matter the diamond
>> operator
>> re. more extensive type inference, was that the technical
>> discussion had
>> not
>> reached a consensus, but the discussions ended because the outcome
>> was
>> decreed (presumable by some process within Sun). Your reply,
>> "discussed
>> extensively ...", implies that some form of consensus was reached,
>> which is
>> not my recollection.
>>
>> You, and many others, have more in-depth knowledge of the compiler
>> than I
>> have, undoubtedly. However an in-depth knowledge can be both a
>> blessing and
>> a curse. There are many examples were someone with a wider breadth,
>> but not
>> so in-depth, knowledge can come up with a solution by bringing
>> expertise
>> for
>> other areas. An example of where versioning is very successful is
>> WiFi,
>> over
>> a short time scale we have gone from 802.11a to n. The letters are
>> the
>> version numbers, the protocols are different, but the hardware can
>> run
>> multiple versions because much of the infrastructure is common (RF
>> amplifiers, aerials, etc.). Can you not see the parallels: different
>> versions a to n (Java source versions) and the same underlying
>> hardware
>> (the
>> JVM)? The committees that specify WiFi have the same issues: a formal
>> specification, mass deployment, multiple vendors, etc., and the
>> solution
>> that has proven to work well is versioning.
>>
>> Taking ideas from others and other domains is well established in
>> science
>> in
>> general, e.g. Isaac Newton, in 1676 said, "If I have seen a little
>> further
>> it is by standing on the shoulders of Giants." Perhaps you could
>> consider
>> standing on the shoulders of the WiFi giants.
>>
>> -- Howard.
>>
>> 2009/10/29 Joseph D. Darcy <Joe.Darcy at sun.com>
>>
>>> No Howard, your source statement was discussed extensively on this
>>> list
>>> (see the archives) and it is not a silver bullet and is not going
>>> to be
>> part
>>> of JDK 7, no matter how many times you bring it up or in how many
>>> venues.
>>>
>>> -Joe
>>>
>>>
>>> Howard Lovatt wrote:
>>>
>>>> Wouldn't it be simpler to introduce a source statement in Coin,
>>>> forget
>> the
>>>> diamond operator, and get 7 out. Having introduced source, 8 can be
>>>> incompatible with previous Java versions (except at the JVM level),
>>>> wildcards dropped, generics reified, and type inference for
>>>> methods and
>>>> declarations improved.
>>>>
>>>> -- Howard.
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Maurizio Cimadamore <Maurizio.Cimadamore at Sun.COM>
>>>> To: Reinier Zwitserloot <reinier at zwitserloot.com>
>>>> Date: Thu, 29 Oct 2009 15:13:21 +0000
>>>> Subject: Re: Reference implementation
>>>> Reinier Zwitserloot wrote:
>>>>
>>>>
>>>>
>>>>> Actually, those 3 examples don't seem too bad for future
>>>>> expansion.
>> Sure,
>>>>> reification is a hard nut to crack, but it always has been.
>>>>>
>>>>>
>>>>>
>>>> Just to clarify - I said that these 3 decisions have made
>>>> reification
>>>> *nearly* impossible - not impossible at all. I guess that the
>>>> length of
>>>> your
>>>> proposal for dealing with cast speak for itself (if we need to
>>>> kinda
>>>> workaround to the fact that now it's possible to write generic
>>>> cast even
>>>> without reification support that means that the decision does
>>>> jeopardize
>>>> further language evolution - e.g it prevents reified Java from
>>>> using
>>>> classic
>>>> syntax for casts - note that this problem does not occur with
>>>> instanceof).
>>>>
>>>> As far as my other two issues - I'm not concerned about typing and
>> safety
>>>> -
>>>> what I'm concerned about is performances - if you have instances of
>>>> Foo<#1>
>>>> or Foo<#1 extends Object & Comparable<? extends Object &
>>>> Comparable <
>> ...
>>>>>
>>>>
>>>>
>>>>> are you sure that the VM could still perform decently? The Java
>> subtyping
>>>>>
>>>>>
>>>> algorithm with generics and wildcards is complex enough that it
>>>> suffices
>> a
>>>> bit of twists and turns to make javac to run out of Stack (even
>>>> in cases
>>>> where subtyping can be proved). What does that mean to have such a
>>>> subtyping
>>>> test inside the JVM ? That's what I'm worried about.
>>>>
>>>> Maurizio
>>>>
>>>>
>>>>
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security
>>> System.
>>> For more information please visit
>> http://www.messagelabs.com/email______________________________________________________________________
>>>
>>
>>
>>
>> --
>> -- Howard.
>>
>>
>
More information about the coin-dev
mailing list