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