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

[John Nilsson]

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