Array equality, comparison and mismatch

[Paul Sandoz]

> On 12 Oct 2015, at 19:50, Mike Duigou <openjdk at duigou.org> wrote:
> 
> 
>>> On 22 Sep 2015, at 18:30, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>>> Hi,
>>> Please review the following which adds methods to Arrays for performing equality, comparison and mismatch:
>>> https://bugs.openjdk.java.net/browse/JDK-8033148
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html
>> Updated the above with JavaDoc for all methods.
>> Paul.
> 
> There is a Kilimanjaro of tedium in building changes like these that are implemented across all the basic types. Thank you for taking this on so thoroughly.

Tell me about it :-)


> 
> A few comments.
> 
> - Inconsistent @since declarations. Both "9" and "1.9" are used. I know Henry Jen was working on normalizing this for the -platform javac work, but am uncertain what was chosen. It is perhaps time to drop the "1.”
> 

I updated Byte/Short methods. At some point there is likely to be a global s/@since 1.9/@since 9/ but i have been trying to use 9 where possible.


> - Have you done side by side textual comparisons of the docs and implementations to make sure there are only expected differences of types and semantics (== vs equals vs compareUnsigned)? It's easy for an error to creep in as you go through many iterations by forgetting to make a fix in one implementation.
> 

Not specifically but kind of when i copied the template from the byte[] receiving methods. I have eyeballed them enough times in different contexts: code, javadoc, specdiff. Doing that caught some mistakes. There might be some mistakes still lurking...


> - I apologize if this was discussed earlier in the thread but why is the comparison of floats and doubles done by first == operator of the int bits and only then the compare method ?

I was being consistent with the test used for the existing equals methods of float[] and double[]. Note that the Float/Double.*to*Bits methods are intrinsic.


> It would seem that the compare method could use this same technique if it wanted. Why not do the same for unsigned comparisons since == would also work for those?
> 

I am not following, sorry. Are you suggesting say:

  for (int i = 0; i < length; i++) {
    int c = Double.compare(a[i], b[i])
    if (c != 0) return c;
  }

?

Note that this area will change when the unsafe vectored mismatch goes in.


> I am *REALLY* looking forward to using these!
> 

Thanks. You might like them even more when they get faster :-)

Paul.