On Fri, 14 Aug 2026 12:34:16 GMT, Liam Miller-Cushon <[email protected]> wrote:
>> 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. There is on going effort to make direct access more auditable, and naming is critical. The naming and warning in uncheckedGetBytesOrThrow was part of that effort. We have to be very careful. So I think the high level comment is to explore all other directions/options before proposing another back door into string internals. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32373#discussion_r3783856008
