Reference implementation

[Howard Lovatt]

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.