Lexicographic array comparators

[Paul Sandoz]

On Feb 11, 2015, at 12:26 AM, John Rose <john.r.rose at oracle.com> wrote:
> On Feb 10, 2015, at 3:15 PM, Martin Buchholz <martinrb at google.com> wrote:
>> 
>> I was surprised that System.arraycopy hasn't been specialized for every
>> array type.
>> I guess the JIT is good at specializing all callers.
> 
> Yes.  Usually the arguments have specific static types the JIT can see.
> The Object formal type doesn't obscure this.
> 
>> I don't know whether we will someday regret the explosion of array
>> comparison methods.
> 
> It's technical debt.  When we go to value types there will be an infinite number of array types.
> That's why in Project Valhalla we are thinking hard, before that, about parametric polymorphism.
> We need to be able to have true polymorphism over APIs in T[], where T can be ref, prim, or value.
> At that point, hopefully, what we have won't be impossible to retrofit.
> 

Yes, i am hoping that many of the overloaded methods on Arrays with the same code shape can be "anyfied" and reduced in a source and binary compatible way. In that respect i feel a less guilty about proposing so many methods :-)

In this case we have the interesting interaction with Comparable: 

  public static <any T extends Comparable<? super T>> int compare(T[] left, T[] right)

We certainly don't want to box for T == int when making comparisons between two ints. I presume, in this case, the intrinsic array match method will deal with that aspect.

--

An alternative solution is to leave Arrays alone and just to go with the lower level System.arrayMismatch method proposed in JDK-8044082 and then wait for value types. However, it requires significantly more work to write an intrinsic, which may put it at risk for the 9 time frame.

Paul.