sahvx655-wq commented on PR #430: URL: https://github.com/apache/commons-validator/pull/430#issuecomment-5143538500
Sorry about that, the suite was green here on 21 but I hadn't run it against the Java 8 job's locale data, which is where it broke. The CI trace shows the 'separator without symbol' assertion failing for de_DE, fr_FR and sv_SE plus the fr_FR percent case: the legacy pre-CLDR data separates the suffix symbol with a plain U+0020 space rather than a non-breaking one, and AbstractNumberValidator trims the input before parsing, so on Java 8 the bare separator degenerates to the valid no-symbol form and parses to 1234.56 instead of being rejected. The explicit-pattern sweep pins a non-breaking space, so it was unaffected. The locale-data test now asserts to the trim contract: a separator above U+0020 with no symbol must be rejected, while a plain-space one is trimmed away and must parse as the no-symbol form. I reproduced the Java 8 failure locally with -Djava.locale.providers=COMPAT before changing anything, and after the fix both providers are green; the full default goal with -Ddoclint=all also passes, 3290 tests, checkstyle, pmd and spotbugs all clean. -- 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]
