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

[Reinier Zwitserloot]

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