In order to be able to use text blocks and other new Java language
features, we are upgrading to a recent version of Checkstyle.
The latest version of spring-javaformat-checkstyle (0.0.28) is built
against Checkstyle 8.32 which does not include support for language
features such as text blocks. Support for text blocks was added in
Checkstyle 8.36.
In addition, there is a binary compatibility issue between
spring-javaformat-checkstyle 0.0.28 and Checkstyle 8.42. Thus we cannot
use Checkstyle 8.42 or higher.
In this commit, we therefore upgrade to spring-javaformat-checkstyle
0.0.28 and downgrade to Checkstyle 8.41.
This change is being applied to `5.3.x` as well as `main` in order to
benefit from the enhanced checking provided in more recent versions of
Checkstyle.
Closes gh-27481
As explained in commit a247b83cd9, the
XppDriver from XStream relies on the XPP3 library which publishes
javax.xml.namespace.QName as part of its JAR. The QName type is also
published by the java.xml system module in modular JREs (i.e., Java 9
or higher).
This results in a split package between the unnamed module and the
java.xml system module, which the Java Language Specification defines
as illegal (see §6.5.5.2 and §7.4.3).
Most Java compilers do not currently enforce this rule; however, the
Eclipse compiler does. This makes it impossible to use spring-oxm out
of the box in the Eclipse IDE. In addition, if bug JDK-8215739 is fixed
in future versions of other JDK implementations, this rule will affect
any users using spring-oxm with those JDKs.
This commit therefore switches the default driver in XStreamMarshaller
from XppDriver to DomDriver. Users can naturally switch back to the
XppDriver if they wish, since the driver is configurable.
Closes gh-27464
In 5.3 it became possible to handle exceptions from any handler through
ExceptionHandler's in a ControllerAdvice class, but this is not
mentioned in the docs
See gh-22619, gh-27338
Prior to this commit, the Spring Framework projects could not be
imported into Eclipse IDE when using JDK 17 to build the projects.
The primary obstacle is the fact that Eclipse enforces a strict
"no split packages between the unnamed module and a system module" rule
when building with a "modular JDK" (such as JDK 17).
Resources:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928
- https://bugs.openjdk.java.net/browse/JDK-8215739
- http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-December/014077.html
- https://stackoverflow.com/questions/51094274/eclipse-cant-find-xml-related-classes-after-switching-build-path-to-jdk-10/53824670#53824670
Since the bug (JDK-8215739) has not been fixed in OpenJDK, the strict
"no split packages" rule does not apply to the Java compiler used in
Spring Framework's Gradle build or the compiler in IntelliJ IDEA. Hence,
this issue only arrises when building the framework in Eclipse IDE.
This commit addresses this issue in the following affected projects.
- spring-oxm: removal of the dependency on XPP3 which publishes
javax.xml.namespace.QName as part of the JAR. The QName type is
also published by the java.xml JDK 17 system module. To make the
tests pass, we have switched to using the DomDriver instead of the
XppDriver in our XStream tests.
- spring-test: HtmlUnit has a transitive dependency on xml-apis which
publishes several packages also published by java.xml JDK 17 system
module. Thus, we have explicitly excluded the transitive dependency
on xml-apis for our `optional` configuration.
See gh-27407
Since the team no longer needs the ability to treat Eclipse projects as
WTP modules, this commit removes the obsolete custom WTP configuration
for importing projects into Eclipse IDE.
See gh-27407
This commit partially reverts cf2429b0f0
in order to reinstate -Werror for Groovy compilation in spring-beans.
The `decorating` field in GroovyDynamicElementReader has been changed
from boolean to Boolean in order to avoid the JDK 17 deprecation warning
for use of `new Boolean(false)` which the Groovy compiler apparently
uses behind the scenes when compiling Groovy source code.
In order to allow developers to execute TestNG tests in Eclipse IDE
without installing the TestNG plugin for Eclipse, this commit introduces
a JUnit Platform @Suite class that can be executed within the IDE.
See gh-27407
Sam Brannen
Juergen Hoeller
Phillip Webb
Rossen Stoyanchev
Brian Clozel