On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <d...@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