Are there any plans to expose internal arrays in java.lang.String?

When trying to performance-tune our Java XML parsing/validation/binding pipeline, I observed the following:

• Iterating a String's chars via String.charAt() is slow, cf. e.g. Woodstox (I was able to verify this statement with own benchmarks):

Intermediate buffer into which characters of a String can be copied, in cases where such a copy followed by array access is faster than calling String.charAt() (which perhaps surprisingly is often case, and especially significant for longer buffers).

• Copying to a buffer array with String.getChars() and then iterating the buffer is obviously more expensive than just iterating over an array.
• Heavily performance-optimized libraries like FastJSON use a mix of unsafe, deprecated and undocumented APIs (AFAIU) to directly access a String's backing array (I verified with own benchmarks that this approach has performance benefits)

Are you aware of any plans to "officially" offer an API to directly access a String's backing array?

The short answer to your question is: no. On the contrary, steps have been taken to make it harder to access internals. There's no way Oracle is going to make it easier. (Well, maaaaaybe after frozen arrays are implemented; just don't count on it.)

As said in the comments, String internals are guarded because otherwise it's possible to violate the immutability of String. Years ago I've already experimented with modifying Strings using reflection, and in Java 11 it's still possible:

String s = "hello world";

var valueHandle = MethodHandles.privateLookupIn(String.class, MethodHandles.lookup())
        .findVarHandle(String.class, "value", byte[].class);

byte[] value = (byte[]) valueHandle.get(s);
value[0] = 'H';

System.out.println(s); // prints Hello world, not hello world

To make it harder, JEP 396 in Java 16 and JEP 403 in Java 17 have been implemented to prevent the above unless you explicitly open packages using --add-opens. For instance, the above is still possible in Java 17 by using the --add-opens java.base/java.lang=ALL-UNNAMED JVM flag (for use in a named module, replace ALL-UNNAMED with your module name). But while it's possible, it's bad practice to do so. Any use of --add-opens indicates someone is trying to do something that the authors (of any opened module, not just Oracle) don't intend you to do.

I was hoping that StringCharacterIterator could perhaps be a bit more efficient, but it still uses charAt and length internally. Perhaps Oracle can be persuaded to update it to use String internals, but I wouldn't count on it.