RFR: 8299807: newStringNoRepl should avoid copying arrays for ASCII compatible charsets

[Roger Riggs]

On Fri, 20 Jan 2023 16:47:27 GMT, Glavo <duke at openjdk.org> wrote:

> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
> 
> 
>     /**
>      * Constructs a new {@code String} by decoding the specified subarray of
>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>      *
>      * The caller of this method shall relinquish and transfer the ownership of
>      * the byte array to the callee since the later will not make a copy.
>      *
>      * @param bytes the byte array source
>      * @param cs the Charset
>      * @return the newly created string
>      * @throws CharacterCodingException for malformed or unmappable bytes
>      */
> 
> 
> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
> 
> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
> 
> This PR fixes this problem.

src/java.base/share/classes/java/lang/String.java line 701:

> 699:      * Throws iae, instead of replacing, if malformed or unmappable.
> 700:      */
> 701:     static String newStringUTF8NoRepl(byte[] bytes, int offset, int length, boolean noCopy) {

The parameter will be easier to understand if `true` means that the string created must not share the byte array supplied.
For example,

@param noShare {@code true} if the resulting string MUST NOT share the byte array, {@code false} if the byte array can be exclusively used to construct the string and is not modified or used for any other purpose.

This flips the boolean argument in the uses below.

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

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