sarankumarbaskar commented on PR #1725: URL: https://github.com/apache/commons-lang/pull/1725#issuecomment-4776118918
I can reproduce the failure on Java 8. `[INFO] T E S T S [INFO] ------------------------------------------------------- [INFO] Running org.apache.commons.lang3.CharSequenceUtilsTest [ERROR] Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.202 s <<< FAILURE! -- in org.apache.commons.lang3.CharSequenceUtilsTest [ERROR] org.apache.commons.lang3.CharSequenceUtilsTest.testRegionMatches -- Time elapsed: 0.009 s <<< FAILURE! org.opentest4j.AssertionFailedError: String Failed test 𐐀[0] caseblind 𐐨[0] 2 => true ==> expected: <true> but was: <false>` The new Deseret test cases are added to the existing regionMatches parity test data, which also checks the String.regionMatches(true, ...) path. On Java 8, String.regionMatches(true, 0, "𐐨", 0, 2) for "𐐀" returns false, so the String check fails before this can purely validate the CharSequenceUtils path. That seems to make the intended behavior a design question: @garydgregory Should CharSequenceUtils.regionMatches continue to match String.regionMatches behavior on the running JDK, including Java 8, or should it intentionally provide supplementary-code-point case folding even where Java 8 String.regionMatches does not? If the goal is JDK parity, the new cases may need to be version-gated or adjusted. If the goal is improved Unicode behavior beyond Java 8 String.regionMatches, then these cases may need to move out of the existing String parity test data and into a dedicated CharSequenceUtils/non-String test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
