Objects.checkIndex/checkFromToIndex/checkFromIndexSize methods check if arguments passed are within bounds, and if not an exception is thrown. That exception can be produced by an additional BiFunction argument that accepts, in certain cases, some but not all bounds arguments. Thus unless capture of additional variables are performed information is lost when producing the exception and a corresponding error message. Further more, it's not possible to reuse a function instance across all methods since information on what bounds checking was performed is also lost. Unfortunately capturing has a cost that cannot currently be reliably elided with escape analysis, therefore it is considered desirable to avoid capture and ensure full fidelity of the bounds arguments and the kind of failed check.

The current state of affairs is as follows:

1) checkIndex ->reporting index, length
    [index, index +1) is not within [0, length)

2) checkFromToIndex ->reporting fromIndex, toIndex
    [fromIndex, toIndex) is not within [0, length)

3) checkFromIndexSize ->reporting fromIndex, size
    [fromIndex, fromIndex + size) is not within [0, length)

Rather than defining BiFunction<Integer, Integer, RuntimeException> a more "reflective" signature is required to ensure full fidelity of both the check and it's arguments, such as BiFunction<String, List<Integer>>, where the first argument of the function corresponds to the bounds check kind (e.g. the corresponding method name), and the second argument corresponds to the list of bounds values (corresponding to the method arguments, in order).

Given this approach the constructors recently added to IndexOutOfBoundsException, StringIndexOutOfBoundsException and ArrayIndexOutOfBoundsException should be revisited. While convenient in the current context when used in constructor references the constructor arguments are ambiguous.