Closed CaryCatZ closed 1 month ago
Thank you for this contribution!
Can you please proof where the original code allowed to match case-insensitive?
Okay. In this line, it attempts to match using the passed specific name. It catches an IllegalArgumentException
exception in the following line. According to the document, this exception occurs when the passed specific name does not match any constant, in this case, it attempts to match again using toUpperCase
method (maybe because name of a constant is recommended to be all upper case). This indicates it may match case-insensitive.
This does not imply case-insensitivity. It still is case sensitive, but it comapares to either the original variant or the all-uppercase variant. According to SemVer, we cannot change behavior or minor releases. Hence I would propose to split the PR in two: One for the next minor release containing solely the actual bug fix, while all other changes / enhancements should go in a second PR for the next major release.
I think it is okay to split this PR. I will edit the code to restore the original behaviour and the issue changes case sensitivity will be raised later.
This PR fixes #550 and provides a test.
Additionally, I found that the previous version attempts twice to match the upper/lower case version, so I think it is okay to use
equalsIgnoreCase
.