chore: add build support for newer JDKs

[toddbaert]

This PR adds the ability to build the contribs in the newest versions of Java, but still supports Java 8 which we want in CI for maximum compatibility.

To do this I had to:

• use auto-detection of the JDK version to run the maven-surefire plugin differentially
• add the bytebuddy workarounds as we have in the java-sdk

[liran2000]

So #915 should be able to pass with this change?
The PR is sort of blocked since it depends on Java 11.

[toddbaert]

So #915 should be able to pass with this change? The PR is sort of blocked since it depends on Java 11.

No, unfortunately. The problem there is that PR includes usage of the Java 11 HTTP client. That will work fine locally if you run the tests with Java 11+, but the CI still runs in Java 8, on purpose, to ensure compatibility.

We could consider some kind of means of doing multiple test runs, some on Java 8 and some on Java 11/X/Y/Z, and then simply say some providers require more recent Java versions - that would require more work though and we'd have to be very careful.

[toddbaert]

So #915 should be able to pass with this change? The PR is sort of blocked since it depends on Java 11.

No, unfortunately. The problem there is that PR includes usage of the Java 11 HTTP client. That will work fine locally if you run the tests with Java 11+, but the CI still runs in Java 8, on purpose, to ensure compatibility.

We could consider some kind of means of doing multiple test runs, some on Java 8 and some on Java 11/X/Y/Z, and then simply say some providers require more recent Java versions - that would require more work though and we'd have to be very careful.

We could open an issue for this though. it's certainly technically possible.

[liran2000]

So #915 should be able to pass with this change? The PR is sort of blocked since it depends on Java 11.

No, unfortunately. The problem there is that PR includes usage of the Java 11 HTTP client. That will work fine locally if you run the tests with Java 11+, but the CI still runs in Java 8, on purpose, to ensure compatibility.
We could consider some kind of means of doing multiple test runs, some on Java 8 and some on Java 11/X/Y/Z, and then simply say some providers require more recent Java versions - that would require more work though and we'd have to be very careful.

We could open an issue for this though. it's certainly technically possible.

Another option is to make another release version which will compile with newer Java from separate branches, and then both branches and release versions can co-exist.