RFR 8135248: Add utility methods to check indexes and ranges

[Remi Forax]

Re-reading my own message and find it confusing ...
what I'm saying is that instead of trying to retrofit all (100%) of the already existing checkIndex,
we should have a simple checkIndex with a sane semantics that cover most of the usage.

Rémi 

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> À: "Stephen Colebourne" <scolebourne at joda.org>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 21 Septembre 2015 16:45:32
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> 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
> > 
>