RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5]

[Roger Riggs]

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array.  The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed.  


     /**
       * Return a String constructed using the byte array containing latin1 (ISO-8859-1) characters.
       * The byte array must not be modified or otherwise referenced or used after the String is created.
       * If COMPACT_STRINGS is true the coder will be LATIN1 and the byte array is the string value;
       * otherwise the contents are inflated to create a UTF16 string.
       */ 
    public String newStringLatin1NoRepl(byte[] src) {
         if (COMPACT_STRINGS)
             return new String(src, LATIN1);
         return new String(StringLatin1.inflate(src, 0, src.length), UTF16);
    }

Creating strings from other encodings that may or have encoding errors should continue to use the current function and handle CCE as required.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768911569