RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl always copy arrays

Glavo duke at openjdk.org
Tue Jan 17 15:47:39 UTC 2023


On Tue, 17 Jan 2023 14:53:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> `newStringUTF*NoRepl` is not described or expected to optimizing the array allocation. Nor does it mandate that callers must guarantee that the array is not re-used or modified. The access to this method through JavaLangAccess is solely for the convenience of the algorithm. I don't see the performance improvement as sufficient to offset the risk of mis-use and its possible loss of integrity.

@RogerRiggs 

I reread the javadoc document and found that I really misread the document. The method marked as not replicating is `newStringNoRepl`/`getBytesNoRepl`.

However, `newStringNoRepl` called `newStringUTF8NoRepl` for UTF-8, which caused the behavior of `newStringNoRepl` to be inconsistent with its javadoc. I think `Files.readString` is relying on this behavior because it will also copy the array defensively before calling `newStringNoRepl`.

Although the inconsistency between the behavior of `newStringUTF8NoRepl`/`getBytesUTF8NoRepl` and `newStringNoRepl`/`getBytesNoRepl` is confusing, I don't want to dwell on this issue. But I think I should reopen a PR for `newStringNoRepl`. Do you agree with me?

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

PR: https://git.openjdk.org/jdk/pull/11897


More information about the core-libs-dev mailing list