> On 12 Oct 2015, at 19:50, Mike Duigou <open...@duigou.org> wrote:
>
>
>>> On 22 Sep 2015, at 18:30, Paul Sandoz <paul.san...@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.
