Reference implementation

Mon Nov 2 03:42:24 PST 2009

Hi Neal,

Having written a lot of embedded code, though not for WiFi, as well as more
conventionally deployed software, I would say that normally-deployed code
has it easy. This is maybe why you don't appreciate how useful the version
number is. All my experience with embedded code is that the code has a long
lifetime and is continually improved, just like more conventional code, and
just like the hardware it runs on. It is a continuous system of evolution
with continuous deployment, the catch is that you can't offer an upgrade
once deployed so you are much more concerned about bugs and much more
concerned with backward compatibility.

Take the WiFi example, a WiFi device typically supports multiple versions
and if a newer device talks to an older device then it uses the older
version of the spec. and can't necessarily use all the new facilities (I
will come back to this point). Re. spec.; the WiFi spec. is much more
complicated than the Java spec., so saying that the spec. is too hard seems
to me to be stretching a point a little. For example the differnt versions
of WiFi use completely different techniques for coping with multiple path
interference.

For Java we could choose to say that the first non-comment, non-whitespace
line in any Java 7 program has to be a source statement. If the first line
isn't a source statement then it isn't Java 7 and is described in JLS ed. 3.
Then make module a proper keyword and don't introduce the diamond operator
(I will come back to this point). The new version of the JLS could be called
JLS7 (note name of JLS matches version number, 1.7). Now that isn't a big
change to the JLS, therefore demonstrating that source can be introduced
without large changes to the JLS.

The compiler vendor would be free to produce a compiler that is Java 7 only,
but I suspect that most would produce a compiler that would compile 6 as
well (just like WiFi vendors support some of the old standards). (I suspect
that the above proposal of only a module statement is so minor that you
could mandate that a Java 7 compiler must support all past versions as
described in JLS ed. 3.) A tool could be produced that finds all the uses of
module as a name and these could be automatically changed to use the new
exotic identifiers (exotic identifiers are already scheduled for 7).

In the next version of Java, when more time and more resources are
available, the type system could be overhauled and something more ambitious
than the diamond operator added. The point is that the source keyword has
positioned you to make such changes. Unlike the changes I suggested above
for Java 7 these might not be backward compatible, but this would be on a
case by case basis.

To make this case-by-case point concrete, lets go back to the WiFi example.
Some aspects of the new standard are typically not compatible with the old,
the most obvious is speed (this would be a case were the new system drops
down to the old standard). Other aspects are, e.g. better RF systems and the
new system would still be able to use its better RF.

The above WiFi example is migration compatibility in action, proven for a
complicated system over many versions with many vendors and over a short
time scale. Currently in Java you have one choice, all new systems must be
compatible with the past, which is why change is so hard. Source breaks this
viscous cycle.

You effectively have the source version embedded in the class file already;
since the class file is already versioned, therefore you can have this
optional migration once you have source. IE just like WiFi, you might not be
able to use a new feature if you want to call old code and you might not (on
a case by case basis). Therefore the source statement positions you for
future migration on a case by case basis, instead of the current 'race
condition' (to use a computer science analogy) where all changes must be
compatible.

Think how much easier the 1.4 transition would have been if we had had
source and exotic identifiers, a tool could have migrated the code
automatically for files that you wanted to use the new features of enum and
assert in and other files wouldn't need touching! Now you can't tell me in
all seriousness that source wouldn't have been great for that transition and
I assert (pun intended) it will *help* for all future transitions.

Since Joe's answer appeared to be along the lines of "over my dead body",
re. the source statement, you are correct in saying the point is moot. :(

 -- Howard.

2009/10/30 Neal Gafter <neal at gafter.com>

> 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.
>>
>>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

-- 
 -- Howard.