src-spring-framework

Spring Framework

History

Sam Brannen 84714fbae9 Allow JDK 20 builds to pass by using legacy locale data After setting up a JDK 20 CI build pipeline, numerous tests involving date/time parsing and formatting began to fail [0]. (The failing JPA tests are not specific to JDK 20.) For example, we encounter visually confusing assertion failures such as the following. org.opentest4j.AssertionFailedError: expected: "12:00 PM" but was: "12:00 PM" The expected string contains a normal space (which has always been the case prior to JDK 20); whereas, the actual string now contains a narrow non-breaking space. The cause of this is mentioned in the JDK 20 Release Notes [1] as "NBSP prefixed to a, instead of a normal space". Note, however, that the links for the first two bullet points in that section are mixed up. "NBSP prefixed to a, instead of a normal space" should point to [2]. Furthermore, the new whitespace character is not a non-breaking space (NBSP) but rather a narrow non-breaking space (NNBSP). In addition, the second bullet point should technically read "NNBSP prefixed to `a`, instead of a normal space" -- even though `a` provides limited value to most readers. The downside for the Java community is that this constitutes a breaking change for parsing and formatting date/time values that include "AM" and "PM" units (any may potentially apply to other date/time parsing/formatting scenarios). In Spring Framework's test suite we have witnessed this in conjunction with Spring's @DateTimeFormat and DateTimeFormatterFactory infrastructure as well as with Google's Gson-to-JSON support. A colleague who works at Oracle graciously informed me that one can use "legacy locale data" by supplying `-Djava.locale.providers=COMPAT` as a JVM argument, noting however that this option limits some newer functionalities (but without enumerating which new functionalities one might be missing when using this option). In any case, this commit adds that JVM argument to our Gradle toolchain builds so that our test suite passes on JDK 20, and we will continue to investigate further options for our builds and for our users. Note, however, that one must manually configure the `-Djava.locale.providers=COMPAT` JVM argument when running affected tests within an IDE. See gh-30185 [0] https://ge.spring.io/s/kmiq2bz2afafs/tests/overview?outcome=failed [1] https://jdk.java.net/20/release-notes#JDK-8284840 [2] https://unicode-org.atlassian.net/browse/CLDR-14032		2 years ago
..
wrapper	…
docs-dokka.gradle	…
ide.gradle	…
publications.gradle	…
spring-module.gradle	…
toolchains.gradle	Allow JDK 20 builds to pass by using legacy locale data	2 years ago