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

[Reinier Zwitserloot]

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