RFR: 8365703: Refactor ZipCoder to use common JLA.uncheckedNewStringNoRepl

[Roger Riggs]

On Tue, 19 Aug 2025 05:48:36 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 283:
> 
>> 281:                 // We use the JLA.newStringUTF8NoRepl variant to throw
>> 282:                 // exceptions eagerly when opening ZipFiles
>> 283:                 return hash(toString(a, off, len));
> 
> Earlier, `byte[]` was shared by the `String` instantiated, now it needs to be cloned. That is, I presume this to have a performance implication. Was this considered?

It always makes a copy, previously and as refactored.
The trampoline in System.java called into String with noShare = true.

public String newStringUTF8NoRepl(byte[] bytes, int off, int len) {
    return String.newStringUTF8NoRepl(bytes, off, len, true);
}

Now the copy is explicitly done by the caller and the contract is clear that the buffer is always not shared but transferred. (and one less argument and conditional)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26822#discussion_r2285476791