org.eclipse.tycho.surefire.junit* libs should still be Java 1.8 compatible about tycho

[sewe]

FWIW, I am willing to create a pull request.

[laeubi]

Then go ahaed I don't see any reason not to merge it if all tests still pass :-)

The problem could really be the module-info.class as the manifest is generated using BND and this uses the highest classversion by default.

[mickaelistria]

Just to make sure: are you certain it's not profitable for your use-case to just fully use Java 11 ? Java 8 compatibility is now an extra cost, so fully getting rid of it could be beneficial for you.
If you want to build a PR for that, please make sure there is some test explicitly covering the Java 8 compatibility story, otherwise, versions may be moved again to Java 11 again later without notice.

[sewe]

Just to make sure: are you certain it's not profitable for your use-case to just fully use Java 11 ? Java 8 compatibility is now an extra cost, so fully getting rid of it could be beneficial for you.

We build a plug-in using Tycho that has to support older Eclipse versions as well (well, really old ones like Luna). In particular, we have to support Eclipse versions which do not even launch on Java 11. Hence, we would like to test against such older versions (easily done using an appropriate eclipse-target-definition) on old JREs (using toolchains).

Of course, as soon as JUnit drops Java 8 support, we will have to move on with our tests, at least for the toolchain part, but that hasn’t happened yet. 🤞

The problem could really be the module-info.class as the manifest is generated using BND and this uses the highest classversion by default.

I use the <enforceBytecodeVersion> enforcer rule in my pull request. It will notify you as soon as one of the upstream dependencies rebundled as part of the Surefire Booter or JUnit/TestNG Runner contains bytecode from a more recent Java version (module-info.class and multi-version JAR files’ META-INF/version/**.class excluded). You can then update the execution environment requirement accordingly.

If you want to build a PR for that, please make sure there is some test explicitly covering the Java 8 compatibility story, otherwise, versions may be moved again to Java 11 again later without notice.

Is this enough of a test case? I must admit the whole tycho-its project is a bit convoluted; in particular, I couldn’t find an integration test using a toolchain which I could use for inspiration.

[mickaelistria]

Is this enough of a test case?

It's more up to you to consider. I know most of us won't care if this is back to Java 11, so it's all about how much this check makes you feel safe ;)

[sewe]

It's more up to you to consider. I know most of us won't care if this is back to Java 11, so it's all about how much this check makes you feel safe ;)

Alright. I added a comment to the bnd.bnd files about this (bf97f0b). That should prevent someone from accidentally switching back to Java 11.

And if JUnit ever decides to switch to a newer bytecode version, the maven-enforcer-plugin will warn us that we will need to update the declared execution-environment requirement.

So from my point of view, pull request #71 is good to go.

[mickaelistria]

PR merged, thanks @sewe