Similar to JDK-8320570, the attached program provokes a java.lang.NegativeArraySizeException.

JDK 23:
$ java -showversion Limit.java
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+16-1297)
OpenJDK 64-Bit Server VM (build 23-ea+16-1297, mixed mode, sharing)
Exception in thread "main" java.lang.NegativeArraySizeException: -1894967251
        at java.base/java.lang.String.encodeUTF8_UTF16(String.java:1338)
        at java.base/java.lang.String.encodeUTF8(String.java:1311)
        at java.base/java.lang.String.encode(String.java:879)
        at java.base/java.lang.String.getBytes(String.java:1845)
        at Limit.main(Limit.java:18)

JDK 22:
java -showversion Limit.java
openjdk version "22" 2024-03-19
OpenJDK Runtime Environment (build 22+36-2370)
OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)
Exception in thread "main" java.lang.NegativeArraySizeException: -1894967251
        at java.base/java.lang.String.encodeUTF8_UTF16(String.java:1338)
        at java.base/java.lang.String.encodeUTF8(String.java:1311)
        at java.base/java.lang.String.encode(String.java:879)
        at java.base/java.lang.String.getBytes(String.java:1845)
        at Limit.main(Limit.java:18)

It seems that java.lang.String.encodeUTF8_UTF16 allocates a worst-case 3x byte array.

Perhaps in situations where 3x exceeds the maximum Java array size, encodeUTF8_UTF16 could instead allocate a maximally sized byte array for the destination, proceed with the coding, and report an OutOfMemoryError if the coding doesn't fit.