On Tue, 17 Jan 2023 14:53:41 GMT, Roger Riggs <rri...@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
