Reference implementation

[Neal Gafter]

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