On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <[email protected]> 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
