On Mon, 16 Dec 2024 22:28:55 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>> `Asserts.assertNotEquals` shows "expected 12345 to not equal 12345" which >> sounds redundant, just say "expected not equals but was 12345". >> >> `Asserts.assertEqualsByteArray` uses the words "expected... to equal...". >> Modify it to follow the `assertEquals` style ""expected... but was...". > > test/lib/jdk/test/lib/Asserts.java line 272: > >> 270: msg = Objects.toString(msg, "assertEqualsByteArray") >> 271: + ": expected " + HexFormat.of().formatHex(lhs) >> 272: + " but was " + HexFormat.of().formatHex(rhs); > > The original message is about these two bytes being unequal, but with the new > message, it seems to imply that the first argument `lhs` is the expected > value and `rhs` is the actual value. I grokked a few calls of this method and > it seems that this may not always be the case? Are those calls from me? I know I haven't followed this pattern and I'm thinking about fixing them later. The reason I want to make this change is to make it consistent with the current `assertEquals` method that shows " expected: LEFT but was: RIGHT". There are quite a lot of calls like `assertEquals(variable, "literal")`, but I think that's the callers' problem instead of the method's. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21101#discussion_r1887754168
