Migration to Java 8

[Boiarshinov]

XmlUnit core project now compiled to Java 7 sources. Java 7 was released ten years ago and now it's just a part of a history. Java versions usage statistics shows that's the most popular Java version in 2020 is a Java 8. Oracle doesn't support Java 7 anymore as first class citizen. So I think that it's time to migrate XmlUnit to Java 8.

Migration to Java 8 will allow to use new cool features like lambda expressions, streams, datetime api etc. Some of these features could be a part of XmlUnit API. Also migration to Java 8 will open a way for usage of new version of internal dependencies. Like JUnit Jupiter 5 instead of JUnit 4.

Another point: it's strange that part of this project (like xmlunit-core) is run on Java 7+ and another part runs only on Java 8+ (xmlunit-assertj3).

[bodewig]

Not requiring more than Java 7 in core is a conscious and deliberate choice, not a bug :-)

Back when I created XMLUnit 2.x I've been able to use functional patterns throughout the code without lambdas so Java 8 wouldn't help that much. XMLUnit 2.x's design has been strongly influenced by C#'s LINQ to object and even after more than ten years I still believe the Java Streams API is way less powerful than one that worked on Iterables could have been :-) . All that lambdas and streams could provide already is present at the cost of some anonymous classes in XMLUnit already.

You need to keep in mind that XMLUnit is a library that others depend on. If we increase the version of anything we require, our downstream users are forced to follow suite. For this reason I've deliberately been very conservative with updates. Downstreams are free to pick newer versions if they want to (we explicitly run tests to ensure the code still works for newer versions of AssertJ or Hamcrest for this reason). Not forcing downstreams to upgrade has been the key reason I added the assertj3 module - to give people the choice to not modify their code base just because they want to update XMLUnit.

Having said that, I'm currently pondering the idea of XMLUnit 3.x just because of #227 which likely cannot be fixed without breaking backwards compatibility in one way or another. This might be a good point in time to bump the core Java requirement. But I haven't made up my mind, yet.

[Boiarshinov]

You need to keep in mind that XMLUnit is a library that others depend on

A lot of others popular libraries already runs on Java 8. For example:

• JAXB reference implementation
• Jackson Databind - the most popular Java library for JSON (un)marshalling
• JsonPath - very popular Java library for working with JSON, often used in test assertions (like XmlUnit).
• a lot of others

Spring announced that Spring Framework 6 will be based on Java 17 in 2022.
(I mentioned Spring because I suppose that most of XmlUnit users get it from spring-boot-starter-test BOM)

So it's absolutly normal to update Java to 8 version in next major release.
Everyone who stay on Java 7 could be use XmlUnit 2.x.x

[phbenisc]

Parser Support:
In my experience the slowest moving libraries in XML-space are the XSLT and XML processors. The only parser I know which requires Java 8 is the Saxon XSLT Parser. The Xalan/Xerces still only requires JDK 1.4 ...

Java Support
The normal premium Support for Java 7 ended in 2019. The "Extended Support" for Java 7 ends in July 2022.

A major version would be the best time to do it. To support Java 7 beyond the extended support yields in my opinion little to no benefit.

On another note: I think we should test and document support for java 17 (latest LTS release). That would increase the supported range significantly...

[bodewig]

@phbenisc testing on OpenJDK 17 is a good idea but I'm having a hard time figuring out whether it is supported by Travis - I've just tried to add it, let's see. We might need to look into alternatives to Travis anyway.

@Boiarshinov XMLUnit not requiring anything more recent than Java 7 doesn't prevent any downstream project from upgrading. But if we do, then we force the downstream to upgrade. This is the difference. We will not do this without a new major release because breaking the current API at the same time just seems natural (why would we keep a Predicate interface of our own, for example?).

I could even imagine us going all in on Java 17 - some things in XMLUnit could very well be records. But that may be just too much for people who want to use JAXB in the Jakarta flavor. The JAXB RI seems to require Java 11 right now, so maybe this could be our next stop. Just thinking out loud here.

[bodewig]

@phbenisc https://app.travis-ci.com/github/xmlunit/xmlunit/jobs/540979245 it seems OpenJDK 17 works quite well except for the xmlunit-assertj package which uses bytebuddy which (at least using the version we use as dependency) doesn't seem to support the new bytecode version of Java 17. People using Java 17 should be using AssertJ 3.x together with the xmlunit-assertj3 module, so I think we are fine.