JEP draft: Efficient array comparison intrinsics
| Type | Feature |
| Scope | JDK |
| Status | Closed / Withdrawn |
| Component | core-libs |
| Effort | S |
| Duration | S |
| Created | 2014/05/27 23:53 |
| Updated | 2025/04/02 22:52 |
| Issue | 8044082 |
(rough draft; needs formatting; see http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html)
There are efficient operations (both safe and unsafe) for copying arrays, but none for comparing them. Let's fix this so users don't have to roll their own.
At a minimum, the following intrinsic would allow suitable higher-level comparison operations to be implemented:
/** Find the index of a mismatch between src and dest, or -1 if none. */
System.arrayMismatch((Object src, int srcPos,
Object dest, int destPos, int length, boolean fromEnd);
- Returns an index in src of an element which differs from the corresponding element in dest, if such an element exists.
- If no such element exists, returns
-1. - If fromEnd is true, returns the index of the last differing element, else returns the first.
- Correspondences between elements are as for System.arraycopy.
- The result will be either
-1or a value betweensrcPosandsrcPos+length-1, inclusive. - Exceptions are as for
System.arraycopy. - The arrays must have compatible element types, either both the same primitive type or both reference types.
- Comparisons are done as if by the Java
==operator. - In particular references to different objects differ, even if
Object.equalswould return true. - Also, floating point
NaNs always differ, even from themselves.
This mechanism is easy to code and easy to vectorize. Most higher-level array comparison operations can readily be built on top of it.
Basic comparison operations (at least lexicographic compareTo) using it should be added to java.util.Arrays.
String.compareTo can be re-implemented on top of this intrinsic.
Methods of the form String.mismatchTo should be added.
As a possible follow-up, System.arrayIndexOf could be added to perform a vectorized non-anchored search of one array inside another. This loop is less interesting, however, since it would be too narrow for some use cases involving NaNs, structural object comparisons, or case-insensitive searches.