On Fri, 22 Aug 2025 13:38:24 GMT, Volkan Yazici <vyaz...@openjdk.org> wrote:
>> Volkan Yazici has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - Renamed to `malformedASCII`
>> - Improve exception parametrization
>> - Document parametrization on the exception type
>> - Avoid using links in the Javadoc title line
>> - Rename `NoReplTest` and fix its copyright year
>
> src/java.base/share/classes/java/lang/String.java line 892:
>
>> 890: Charset cs, byte coder, byte[] val, Class<E> exceptionClass)
>> 891: // Parametrizing on exception type to enable callers (using
>> null) to avoid having to declare the exception
>> 892: throws E {
>
> @RogerRiggs, since there is nothing stopping the programmer from passing
> `TotallyUnrelatedException.class` to `encodeWithEncoder()` (or to 2 other
> sneakily throwing methods), I've tried adding the following as the first
> thing in this methods' body:
>
> assert exceptionClass == null ||
> CharacterCodingException.class.isAssignableFrom(exceptionClass);
>
> This beautifully caused a JVM crash due to early initialization issues
> surrounding `String`. @liach suggested the following:
>
> 1. Move assertions to `StringLatin1` and `StringUTF16` – This solves the
> issue, but the check is at a relatively later stage.
> 2. Replace `assert` with a runtime check, e.g., `if (...) { throw new
> AssertionError(...); }` – This solves the issue, but incurs a runtime penalty
>
> What would you advice?
"the programmer" is an OpenJDK developer and won't be making spurious changes.
The exception classes are only present to make the compiler satisfied, they are
ignored at the point the exceptions are thrown.
A mismatch in the exception class would show up at compile time, not matching
the signature of the calling method.
And they are buried in the implementation under the `decodeUTF8_UTF16` and
`decodeUTF8_UTF16NoReplacement` wrappers.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2293839186
