Why does IndexOutOfBoundsException now have a constructor with a long index as a parameter in Java 16?

I was checking the implementation of IndexOutOfBoundsException in JDK 16, and I have noticed that a new constructor with a long index has been introduced:

/**
 * Constructs a new {@code IndexOutOfBoundsException} class with an
 * argument indicating the illegal index.
 *
 * <p>The index is included in this exception's detail message.  The
 * exact presentation format of the detail message is unspecified.
 *
 * @param index the illegal index.
 * @since 16
 */
public IndexOutOfBoundsException(long index) {
    super("Index out of range: " + index);
}

From what I know, array indices are usually int values, and this is confirmed in the Language Specification section §10.4:

Arrays must be indexed by int values; short, byte, or char values may also be used as index values because they are subjected to unary numeric promotion (§5.6) and become int values.

An attempt to access an array component with a long index value results in a compile-time error.

Any idea when (and why) this long index constructor would be used ?

Answer

Quoting from the comments for future reference:

This was precipitated by Project Panama, which brings better native heap access to Java. The Foreign Memory API (a replacement for direct byte buffers) allows long-indexed heap access to native memory segments, motivating this change to IOOBE. – Brian Goetz

TL;DR It is related with the following feature Enhancement (JDK-8255150) : Add utility methods to check long indexes and ranges

Description
This is related to JDK-8135248. The goal is to add a similar set of methods but rather than operate on int arguments, the new methods operate on long arguments.

The new methods in Objects are:

public static long checkIndex(long index, long length) public static long checkFromToIndex(long fromIndex, long toIndex, long length) public static long checkFromIndexSize(long fromIndex, long size, long length)

They mirror the int utility methods.

As is the case with the int checkIndex(), the long checkIndex() method will be JIT compiled as an intrinsic. That allows the JIT to compile checkIndex to an unsigned comparison and properly recognize it as range check that then becomes a candidate for the existing range check optimizations. This has proven to be important for panama’s MemorySegment and a prototype of this change (with some extra c2 improvements) showed that panama micro benchmark results improve significantly.

From another source about the subject : JDK 16: Checking Indexes and Ranges of Longs:

In my last post, I described the day period support added with JDK 16 Early Access Build 25. That same build also added methods for checking indexes and ranges of long values, which is the subject of this post. JDK-8255150 (“Add utility methods to check long indexes and ranges”) is the Enhancement used to add utility methods for checking long indexes and ranges similar to what JDK-8135248 (“Add utility methods to check indexes and ranges”) added for integers with JDK 9. JDK-8255150 states, “The goal is to add a similar set of methods [as JDK-8135248] but rather than operate on int arguments, the new methods operate on long arguments.”

The greatest beneficiary of these newly added long-supporting methods may be the authors, maintainers, and users of the foreign memory access API as described in this mailing list message: “We have to jump through quite a few hoops in the implementation of the foreign memory access API in order to leverage the intrinsification of int-based index checks, and even then we are not covering the cases where the numbers are larger than ints. Looking forward to being able to remove those hacks!”

Leave a Reply

Your email address will not be published. Required fields are marked *