RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4]

[Chen Liang]

On Tue, 27 Jun 2023 07:45:34 GMT, Glavo <duke at openjdk.org> wrote:

>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>> 
>> Reasons:
>> 
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
>> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - update javadoc
>  - clean newStringNoRepl1
>  - clean newStringNoRepl1
>  - Rename jla to JLA
>  - Create new method JavaLangAccess::newStringLatin1NoRepl

I've investigated the few xxNoRepl methods and think they are best coalesced together into newStringNoRepl and getBytesNoRepl taking byte arrays.

1. The exceptions to the NoRepl methods was added in [8205058](https://bugs.openjdk.org/browse/JDK-8205058) when the access method only catered to Files use cases; these are applicable nowhere else.
2. The UTF8 noRepl methods are sometimes implemented incorrectly, especially getBytesUTF8NoRepl, which always copies the array. They are added specifically for Zip handling as well.

Thus, I recommend the following changes:
1. Make the NoRepl methods throw IllegalArgument (like NoRepl1 do) by default; move the exception handling logic into Files implementation, the only place where it's actually needed.
2. Coalesce all charset-specific NoRepl methods in JLA into newStringNoRepl/getBytesNoRepl; the ones in String itself can stay, for they simplify code much.

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

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610464404