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

Volkan Yazici vyazici at openjdk.org
Tue Aug 19 17:53:40 UTC 2025


On Tue, 19 Aug 2025 14:33:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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)

Right. Apparently I was completely lost while trying to follow that double-negation (i.e., `noShare = true`) logic. Thanks so much for the elaborate explanation.

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

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


More information about the core-libs-dev mailing list