RFR 8135248: Add utility methods to check indexes and ranges

[Remi Forax]

I agree with Stephen.

Calling the function interface with the name ...Exception seems very wrong to me.

The convention of ArrayIOOBE or StringIOOBE is to just report the bad index with no further info,
currently with your code it's not possible to write
  checkIndex(index, ArrayIndexOutOuBoundException::new).

so the functional interface for checkIndex should be int -> Object or long -> Object if you change ArrayIOOBE and StringIOOBE to store a long.
This functional Interface already exists under the name java.util.function.LongFunction.

For the two other methods that checks several index, again the convention is to report the bad index / size, so a LongFunction is enough too,
yes, it means that you can not check several index at once with things like (a < 0) | (b < 0) but because the semantics you propose is different
from what is usually done, you will not be alble to use those methods inside the JDK without introducing incompatibilities.

cheers,
Rémi 

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 21 Septembre 2015 15:52:53
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> While I think I understand the need for the lambda/exception interface
> (backwards compatibility) it is definitely weird as a method
> signature.
> 
> It would seem very worthwhile to add overloaded versions of each of
> these methods that do not have the OutOfBoundsToException in the
> argument list. Instead, these overloads would throw a "standard"
> exception. Such methods would then be much more amenable to just being
> dropped into existing application code, where the precise exception
> that is thrown is less of a concern.
> 
> Stephen
> 
> 
> 
> On 21 September 2015 at 14:42, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> > Hi,
> >
> > Please review the following which adds methods to Arrays to check indexes
> > and ranges:
> >
> >   https://bugs.openjdk.java.net/browse/JDK-8135248
> >   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> >
> > The original motivation was an intrinsic method, Arrays.checkIndex, to
> > check if an index is within bounds. Such an intrinsic guides HotSpot
> > towards better optimisations for bounds checks using one unsigned
> > comparison instead of two signed comparisons, and better eliding of
> > integer to long conversions when an index is used to create an offset for
> > Unsafe access. The end result is more efficient array access especially so
> > from within unrolled loops. The VarHandles work will use Arrays.checkIndex
> > for array access.
> >
> > A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
> >
> > We thought it would be opportunistic to support two further common
> > use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> > checkFromIndexSize. There is no current plan to intrinsify these methods.
> >
> > Bounds checking is not difficult but it can be easy to make trivial
> > mistakes. Thus it is advantageous to consolidate such checks not just from
> > an optimization perspective but from a correctness and security/integrity
> > perspective.
> >
> > There are many areas in the JDK where such checks are performed. A follow
> > up issue [2] will track updates to use the new methods.
> >
> > The main challenge for these new methods is to design in such a way that
> >
> > 1) existing use-cases can still report the same set of exceptions with the
> > same messages;
> > 2) method byte code size is not unduly increased, thus perturbing inlining;
> > and
> > 3) there is a reasonable path for any future support of long indexes.
> >
> > Paul.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> > [2] https://bugs.openjdk.java.net/browse/JDK-8135250
>