Describe the enhancement requested
Right now the library integrating with arrow-java needs to resort to hacks of setting environment variable or system property at runtime if it knows its usages of arrow-java can omit null and bounds checking. However, that is not true for all of the usages in the given process leading to invalid data reads or segfaults.
To avoid this pitfall I suggest we add getUnchecked apis that NEVER do any null and bound checking but put the responsibility on the caller to guard against their possibility. For example in apache iceberg https://github.com/apache/iceberg/blob/23b5ce8eeca2d894c7973e19caa5c5ec02b4e4b8/spark/v4.1/spark/src/main/java/org/apache/iceberg/spark/data/vectorized/VectorizedSparkParquetReaders.java#L44-L51
These apis would make it easy to mix libraries that use arrow as an implementation detail along with user code that operates directly on arrow arrays
Describe the enhancement requested
Right now the library integrating with arrow-java needs to resort to hacks of setting environment variable or system property at runtime if it knows its usages of arrow-java can omit null and bounds checking. However, that is not true for all of the usages in the given process leading to invalid data reads or segfaults.
To avoid this pitfall I suggest we add getUnchecked apis that NEVER do any null and bound checking but put the responsibility on the caller to guard against their possibility. For example in apache iceberg https://github.com/apache/iceberg/blob/23b5ce8eeca2d894c7973e19caa5c5ec02b4e4b8/spark/v4.1/spark/src/main/java/org/apache/iceberg/spark/data/vectorized/VectorizedSparkParquetReaders.java#L44-L51
These apis would make it easy to mix libraries that use arrow as an implementation detail along with user code that operates directly on arrow arrays