On Thu, 29 Sep 2022 18:17:18 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> I agree skipping the test is not the best solution. Leaving a hint in the >> comments on how to fix the issue looks better alternative. > > Well, what concerns me with the current fix is that it is simply patching > only the case for the Japanese setup. We don't know if the same failure would > happen in other setups (I'm pretty sure the same failure would happen with > some Chinese Windows setups) which makes the test fragile. If that happens, > we are not sure if it is a real bug or a test case false positive at a > glance. For that reason, I think we should only run tests on the setup where > we are sure the false positive won't happen (by skipping other unknown host > encodings). And for the purpose of this test, that should suffice the need. > Another option would be to actually check if the test string can be encoded > with a CharsetEncoder, but that may be overkill. I don't think it will be many practical setups where this test fails. This test has been around for more than 2 years and this is the first accident. ------------- PR: https://git.openjdk.org/jdk/pull/10226
