Reference implementation

Fri Oct 30 10:03:26 PDT 2009

Howard,

Let's say we already had your source statement and my source file has
"source 6" at the top. Java 7 is released and everything keeps on
working. But now I want to modify that file and add, say, strings in
switch. So I change the line to "source 7" and add my switch
statement. Is that it? What else do I have to change in that file? I
have to carefully look through the list of incompatible changes from 6
to 7 and see if any apply to this file. Programmers won't do this and
their code will break, sometimes in subtle ways. Then they'll blame
Java, because it's psychologically easier than blaming themselves.

My guess is that it would make things worse because it would give
language designers license to make all sorts of small incompatible
changes.

Lawrence

On Fri, Oct 30, 2009 at 7:48 AM, Neal Gafter <neal at gafter.com> 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.
>>
>>
>
>