On Feb 11, 2015, at 12:26 AM, John Rose <john.r.r...@oracle.com> wrote: > On Feb 10, 2015, at 3:15 PM, Martin Buchholz <marti...@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.
