Revisiting primitives in generics: This can *NOT* be delayed for later.

[John Nilsson]

Maybe you are right. Intuitively, though, I'm thinking since a simple
re-compile of the source would make it work, what could possibly break
by doing the "re-compile" at runtime (or when loading the class).

BR,
John

On Sun, Jul 18, 2010 at 4:11 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> Changing method resolution is unlikely to be backwards compatible. It would
> also have rather severe performance impacts, I bet. At any rate, more
> research would be required; a lot more, for such a change.
>  --Reinier Zwitserloot
>
>
>
> On Sat, Jul 17, 2010 at 7:00 PM, John Nilsson <john at milsson.nu> wrote:
>>
>> I'm note sure I understand why this is a problem. But if it is, why not
>> fix it?
>>
>> So I understand it correct that there is no runtime lookup for a
>> compatible method (supertype of DoubleComparator)? If so, why not add
>> this to the runtime?
>>
>> BR,
>> John
>>
>> On Sat, Jul 17, 2010 at 1:36 AM, Reinier Zwitserloot
>> <reinier at zwitserloot.com> wrote:
>> > No, that doesn't actually work, because method calls are stored as
>> > (class,
>> > name, descriptor) tuples. Thus a call to the 'old' Ops based version
>> > would
>> > be encoded as:
>> >
>> > java.util.concurrent.pa.DoubleParallelArray binarySearch
>> > (DLj/u/c/p/Ops$DoubleComparator;)V
>> >
>> > and by removing this method in favour of one based on e.g.
>> > j/u/Comparator,
>> > that method descriptor would find nothing, and thus produce a
>> > MethodNotFoundError at runtime.
>> >
>> > This is incidentally also the explanation for why j.u.Vector is still
>> > used
>> > by name in various swing classes. Can't remove the method.
>> >
>> >  --Reinier Zwitserloot
>> >
>> >
>> >
>> > On Fri, Jul 16, 2010 at 9:29 PM, Lawrence Kesteloot <lk at teamten.com>
>> > wrote:
>> >
>> >> Ops.DoubleComparator could be retrofitted to be an empty sub-interface
>> >> of Comparator<double> and the version of binarySearch that takes a
>> >> DoubleComparator could be removed. The version that takes a Comparator
>> >> would work with old binary classes, old source classes, and new source
>> >> classes.
>> >>
>> >> Lawrence
>> >>
>> >>
>> >> On Fri, Jul 16, 2010 at 12:10 PM, Reinier Zwitserloot
>> >> <reinier at zwitserloot.com> wrote:
>> >> > I realized this rather troublesome problem of going with SotL and not
>> >> > considering primitives in generics:
>> >> >
>> >> > There's no way back from that.
>> >> >
>> >> > If ParallelArrays is released with the full contingent of 132 SAMs in
>> >> Ops,
>> >> > then we'll not only be stuck with them forever in the traditional
>> >> > sense
>> >> of
>> >> > not eliminating classes to preserve backwards compatibility, but
>> >> > there's
>> >> > also no practical way forward, either.
>> >> >
>> >> > Currently, PA's DoubleParallelArray has a binarySearch method with
>> >> > the
>> >> > following signature:
>> >> >
>> >> > binarySearch(double target, Ops.DoubleComparator c).
>> >> >
>> >> > DoubleComparator itself is a SAM type, with signature #int(double,
>> >> double).
>> >> >
>> >> > Therefore, a call to binarySearch with lambda would look like:
>> >> >
>> >> > binarySearch(12345678.9, {double a, double b ->
>> >> Math.abs(a)-Math.abs(b)});
>> >> >
>> >> >
>> >> > But if in a later JDK there's a way to deprecate Ops.DoubleComparator
>> >> > in
>> >> > favour of either a function type #int(double, double), -OR- my
>> >> > preferred
>> >> > option of allowing java.util.Comparator<double>, then there would be
>> >> > a
>> >> > second binarySearch method with signature:
>> >> >
>> >> > binarySearch(double target, Comparator<double> c).
>> >> >
>> >> > Calling this one would look like:
>> >> >
>> >> > binarySearch(12345678.9, {double a, double b ->
>> >> Math.abs(a)-Math.abs(b)});
>> >> >
>> >> > which is indistinguishable from the Ops.DoubleComparator case. The
>> >> compiler
>> >> > can therefore not compile it, complaining about ambiguity. Users
>> >> > would
>> >> have
>> >> > to explicitly specify either Ops.DoubleComparator or
>> >> > Comparator<double>,
>> >> > breaking backwards compatibility and in general uglying up the API.
>> >> >
>> >> > I don't see a nice solution for this dilemma; one could use
>> >> 'binarySearch2'
>> >> > but that feels like a copout. One could attempt a scheme whereby
>> >> overridden
>> >> > methods can use some extra keyword to dictate to the compiler which
>> >> > of a
>> >> set
>> >> > is to be preferred in case there's ambiguity, but that's adding extra
>> >> > complexity, which may not be palatable at that point.
>> >> >
>> >> >  --Reinier Zwitserloot
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>
>