Repository navigation
fix failing afn:sprintf tests that fails on nb-NO - #4373
OyvindLGjesdal wants to merge 1 commit into
Conversation
| @Test public void exprSprintf_14() { test("afn:sprintf('%020d', 1)",NodeValue.makeString("00000000000000000001")); } | ||
| @Test public void exprSprintf_15() { test("afn:sprintf('%200d', 1)",NodeValue.makeString(StringUtils.repeat(' ', 199) + "1")); } | ||
| // check that sprintf does not depend on the JVM default locale | ||
| @Test public void exprSprintf_16() { |
There was a problem hiding this comment.
This isn't thread safe.
Locale.setDefault sets the JVM wide Locale for all threads so it (briefly) modifies everywhere in the JVM. Tests can run in parallel.
I can't think of a way to check afn:sprintf that doesn't fall back to the same situation the other tests have. They format and test for the . decimal form.
Of course, if someone is running n?-NO moderately regularly, the check happens!
What if "nb-NO" isn't available? I think the Java runtime library creates a Locale with defaults.
(Could check Locale.availableLocales())
There was a problem hiding this comment.
I guess removing test-16 and reporting if something breaks works. Claude suggests it would silently pass without checking on missing locale:
On a runtime without Norwegian locale data, the formatter would fall back to root formatting and print ., so the test would pass without checking anything.
013e295 to
63653c0
Compare
GitHub issue resolved #4372
Pull request Description:
By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.
See the Apache Jena "Contributing" guide.