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" <fo...@univ-mlv.fr> > À: "Stephen Colebourne" <scolebou...@joda.org> > Cc: "core-libs-dev" <core-libs-dev@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" <scolebou...@joda.org> > > À: "core-libs-dev" <core-libs-dev@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.san...@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 > > >
