On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen 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 cleane
On Wed, 18 Oct 2023 16:39:47 GMT, Alan Bateman wrote:
> We have to be very careful with proposals like this as it means code outside
> of java.lang having access to the underlying bytes. I think other
> alternatives needs to be explored to avoid this and related concerns.
Yes, adding another m
On Wed, 18 Oct 2023 16:27:58 GMT, Roger Riggs wrote:
> 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,
On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen 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 cleane
On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen 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 cleane
> 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
