Paul,
On 22/09/15 17:30, Paul Sandoz 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
This looks very good.
I know that there has been some discussion already about the behavior
when passed null, but it seems a little unfortunate that the range
accepting 'equals' methods don't behave in a similar manner to that of
the non-range 'equals' methods. But I do accept that it makes little
sense, where would the from/to indices come from. So I think NPE makes
sense for these.
It was not immediately obvious to me that the common prefix can be 0.
Should this be called out specifically?
Minor typo(s):
"...the length of the smaller array and it follows THAT the
index is only valid ..."
"If one array is a proper prefix of the other, over the specified
ranges, then the returned relative index is the length of the
smaller range and it follows THAT the relative index is only valid
for the array with the larger range."
The motivation behind this is the use of Unsafe in popular libraries and
frameworks to speed up the lexicographical comparison of byte arrays.
This issue focuses on the API and functional implementations. A follow up issue
[1] tracks updating the implementations to use a common method that leverages
Unsafe to improve performance. A further issue [2] tracks the intrinsification of
that common method to support operating on > 64 bits in width and further
improve performance. A further issue, yet to be created, will follow up on
updating existing JDK code to use the public and/or internal methods where
appropriate. Example candidates include String (compareTo, perhaps add a mismatch
method and possibly reviewing existing intrinsics, including those for compact
Strings), and managed and direct Buffers.
So far i have only documented the new methods operating on byte[], as that will
act as the template for the other methods.
Some points:
- Methods operating on Object[] will compare Object elements using
Object.equals or associated comparators (as is the case for the existing equals
method operating on Object[]).
- Methods operating on float[] or double[] will check such array elements for
equality using the IEEE bit layout (as is the case for the existing equals
method operating on float[] or double[]).
- Primitive array element comparison will be performed as if by the boxed
primitive type’s compare or compareUnsigned method.
- Range-accepting methods do not support null array values.
- Non-range and range-accepting mismatch methods do not support null array
values. (What value should be returned when a mismatch is performed on a null
array and an empty array)?
- Speculation: it may be possible that Project Valhalla will enable us to
“compress” down methods of certain groups to one “template” method. Even if
that is not possible i am not overly concerned about the number of methods
added, which represents the maximum set. We could reduce them without a
fundamental loss of functionality, but that might have a “semantic” loss
requiring developers to roll their own wrappers.
-Chris.
Thanks,
Paul.
[1] https://bugs.openjdk.java.net/browse/JDK-8136924
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8044082
