On Sat, 18 Jun 2022 00:31:06 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> This is a regression caused by the fix to >> [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed >> the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE >> mode based on the comment "should not happen". Possibly this refers to the >> `String(byte[], int, int, Charset)` constructor, which specifically mentions >> the `REPLACE` mode. However, the method is invoked with >> `String.newStringNoRepl()` and it should NOT replace the malformed input >> (duh!). The fix is to throw an `Error` for the former case as before the >> regression, and `CharacterCodingException` for the latter via an >> `IllegalArgumentException`. >> In fact, `Files.readString()` stopped throwing a `MalformedInputException` >> since JDK17 with the fix to JDK-8259842, which started throwing an `Error`. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Added c2b test > I looked for similar test cases but ended up finding nothing. Thus I created > a new test case here. Problem is that they are issued through > `SharedSecrets`, which are effectively _APIs_ but treated as private methods > which leads to insufficient testing. I now think that I would add not only > b2c test, but also c2b test (for getBytesNoRepl() method) is needed. I will > modify the test case to include it. My comment was mostly asking if we need to add more tests for Files.writeString. I would have expected a test for that method to fail with this bug. Maybe we need to create a new issue to expand the tests for this method. > BTW, I found a spec bug in `Files.writeString()` w/o `Charset` argument, > where the `@throws` clause reads: > "[IOException](https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/io/IOException.html__;!!ACWV5N9M2RV99hQ!PzgRBNWQwotDtM0GEFtu0XuT7pUqLpKjdwt6awkfFaeZEhXxhdEPL5FhuTeNGYrUHdaeM-_qWB2PccxVdZIFLQ$ > ) - if an I/O error occurs writing to or creating the file, or the text > cannot be encoded using the specified charset", but there is no specified > charset there. It looks like description for IOException was copied from the 4-arg writeString to the 3-arg writeString. I've created JDK-8288836 to track this. One other thing, this is a regression in 19 so I assume the PR should be against openjdk/jdk19 rather than the main line. ------------- PR: https://git.openjdk.org/jdk/pull/9193
