Lexicographic array comparators

[Martin Buchholz]

People will continue to want to access byte arrays (and direct byte
buffers) with C-like performance, and are currently using Unsafe to do so.
Hard to fix for real.  Endianness and unaligned access are both
non-portable aspects.  People don't want to pay for bounds checking and
especially not for alignment checking of indexes known to be aligned.
Lexicographic comparison is only one use case (that happened to be
important performance wise for guava).

I have long thought that arrays should acquire more listesque methods (e.g.
contains, indexOf), even though arrays are unpopular.

On Tue, Feb 10, 2015 at 6:36 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> One common use of Unsafe is boost the performance of comparing unsigned
> byte[] by viewing as long[] (for example as performed by Guava or
> Cassandra). To reduce the dependency on Unsafe we need a public and safe
> equivalent that works on all platforms while meeting the performance
> expectations.
>
> In the past we have discussed exposing something on ByteBuffer but i think
> the right thing to explore are comparators for all basic types on
> java.util.Arrays:
>
>  https://bugs.openjdk.java.net/browse/JDK-8033148
>
> This should be explored with the following issue in mind to expose an
> intrinsic that could be leveraged when implemented:
>
>  https://bugs.openjdk.java.net/browse/JDK-8044082
>
> Some preliminary work can be found here:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>
> The "explosion" in methods is annoying. Out of the 8 primitives 4 can be
> signed or unsigned. Objects can be comparable or an explicit comparator can
> be used. There are implicit and explicit ranges. That makes a maximum of 28
> methods, but could be reduced to a minimum of 10, for all basic types.
>
> Comparator instances, for implicit ranges, can easily be created from
> method refs or lambdas.
>
> Thoughts?
>
> Paul.
>