-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8288589: Files.readString ignores encoding errors for UTF-16 #9193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back naoto! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@naotoj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 27 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Files.readString has been broken several times by the changes in to String in this area. Would it be possible to survey the tests that we have for this method, esp. the error cases, to see if we need more tests. |
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 BTW, I found a spec bug in |
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.
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. |
Added a test case in ReadWriteString.java, which is the unit test for
Thanks for filing the issue.
Since this PR already got a few approvals, I will backport the changeset to the jdk19 line after this PR gets integrated. |
private final static String MALFORMED_WINDOWS_1252 = "\u0080\u041e"; | ||
private final static Charset WINDOWS_1252 = Charset.forName("windows-1252"); | ||
|
||
@Test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks confusing that annotation goes before javadoc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
public void testMalformedReadBytes(byte[] data, Charset csRead, Class<CharacterCodingException> expected) | ||
throws IOException { | ||
Path path = Files.createTempFile("illegalInputBytes", null); | ||
path.toFile().deleteOnExit(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although this is consistent with the existing tests in this source file, I think it would be better if we change it to create the temporary files in the current directory and not delete it. Leaving the file behind is useful for diagnosing issues where there re test failures. We can do that in a separate issue if you'd like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Thanks, that will be helpful if the test fails.
Okay, although doing it this way means there will need to be a PR for openjdk/jdk19 too. |
Yes. It's much easier to backport it than to create a jdk19 PR from scratch, as |
/integrate |
Going to push as commit 2728770.
Your commit was automatically rebased without conflicts. |
This is a regression caused by the fix to 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 theString(byte[], int, int, Charset)
constructor, which specifically mentions theREPLACE
mode. However, the method is invoked withString.newStringNoRepl()
and it should NOT replace the malformed input (duh!). The fix is to throw anError
for the former case as before the regression, andCharacterCodingException
for the latter via anIllegalArgumentException
.In fact,
Files.readString()
stopped throwing aMalformedInputException
since JDK17 with the fix to JDK-8259842, which started throwing anError
.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9193/head:pull/9193
$ git checkout pull/9193
Update a local copy of the PR:
$ git checkout pull/9193
$ git pull https://git.openjdk.org/jdk pull/9193/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 9193
View PR using the GUI difftool:
$ git pr show -t 9193
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9193.diff