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

[Reinier Zwitserloot]

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