On Fri, 14 Aug 2026 12:18:15 GMT, Alan Bateman <[email protected]> wrote:
>> See >> >> * [panama-dev@ thread 'String processing and Vector >> APIs'](https://mail.openjdk.org/archives/list/[email protected]/thread/YSPX3TBXZTZEFZNXWDYOZCWLUQPC62P6/) >> * [JDK-8390049: Immutable zero-copy String views of a String's code >> units](https://bugs.openjdk.org/browse/JDK-8390049) >> >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 494: > >> 492: byte stringCoder(String str); >> 493: >> 494: byte[] stringValue(String str); > > Hmm, this allows access to the internal byte[] from outside of java.lang. > This is very dangerous and makes it hard to audit for any mis-uses in "far > away" code. A supporting method in java.lang that provides a read-only view > of the byte[] would be okay but that might be a different type of ByteVector. I think that is already true of `uncheckedGetBytesOrThrow` at least for latin1 strings, does this seem significantly worse? Once `Vector` is no longer incubating it'd be possible to have this just return `ByteVector`. In the shorter term I think this could use `MemorySegment`. There's discussion in the thread about why `MemorySegment` isn't the right choice for a public API (it leaks the mutable backing array to critical downcalls, and also through `heapBase`). But for an internal-only method in JLA maybe it's better than the values array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32373#discussion_r3783635172
