Test with JDK 9 Early Access builds

[marcphilipp]

Overview

The OpenJDK team has asked the JUnit team to test with JDK 9 Early Access builds and report any showstopper issues to them.

The goal of this issue is therefore to perform such tests and provide feedback to them.

Resources

• JDK 9 early access builds
• Gradle 3.0 nightly builds
  • nightly release notes
• Gradle JDK 9 Support wiki page
• Travis CI JDK 9 Support

Deliverables

• Set up a build using JDK 9 early access builds and Gradle 3.0 nightly builds

Manual Test Results

The following are the results of manual JUnit 5 builds against Gradle 3.0 nightly builds with JDK 8 and JDK 9.

Note: gct is an alias for gradlew clean test.

July 2, 2016

• ✅ gct with Gradle 3.0-20160702000020+0000 and JDK 1.8.0_92-b14
• ✅ gct with 3.0-20160702000020+0000 and JDK 9-ea+124

June 27, 2016

• ✅ gct with Gradle 3.0-20160627000036+0000 and JDK 1.8.0_92-b14
• ✅ gct with Gradle 3.0-20160627000036+0000 and JDK 9-ea+124

June 15, 2016

• ✅ gct with Gradle 3.0-20160615000025+0000 and JDK 1.8.0_92-b14
• ✅ gct with Gradle 3.0-20160615000025+0000 and JDK 9-ea+122

[sbrannen]

To be honest, I've only been putting off testing on Java 9 because Gradle does not support Java 9 yet.

In other words, we have no way to compile JUnit 5 against Java 9 at the moment.

However, it would be possible to execute some manual smoke tests -- for example, using the ConsoleRunner. So I guess that's the best we can offer until Gradle supports Java 9.

[marcphilipp]

We could try using a nightly build of Gradle, as discussed in the Gradle forum, right?

[sbrannen]

Wow... you found that old thread of mine in the Gradle forum.

That was for Gradle 2.5 and old early access releases of Java 9.

Since then, many things have changed internally within Java 9, and consequently Gradle cannot even compile a HelloWorld Java class.

The Gradle and JDK9 Status Today provides further details.

Long story, short: AFAIK there is no nightly Gradle build that can compile Java code using JDK 9.

But... if you discover something to the contrary, please let me know! 😉

p.s. I'll add a link to that Gradle wiki page to this issue's description.

[mkobit]

@sbrannen It looks like after tonight, the nightly build will have initial Java 9 support.

See gradle/gradle@d482d32#diff-0a54cd20978cc67e059eefd51fb97176 for the release notes update.

I would imagine it will be reflected in tonight's nightly build (should be visible at the nightly-release-notes)

[sbrannen]

@mkobit,

Good to know that Gradle 3.0 nightly builds are starting to support Java 9.

We'll keep an eye on it.

Thanks for sharing! 👍

[sbrannen]

Update: I just added a Deliverable for this issue.

[sbrannen]

✅ Gradle 3.0 + JDK 8 --> works.

❌ Gradle 3.0 + JDK 9 --> fails as follows.

:junit-tests:compileTestJava
warning: [options] bootstrap class path not set in conjunction with -source 1.8
/Users/sbrannen/source/junit-lambda/junit-tests/src/test/java/org/junit/gen5/engine/ExecutionEventConditions.java:58: error: no suitable method found for allOf(Condition<? super ExecutionEvent>[])
                return allOf(conditions);
                       ^
    method Assertions.<T#1>allOf(Iterable<? extends Condition<? super T#1>>) is not applicable
      (cannot infer type-variable(s) T#1
        (argument mismatch; Condition<? super ExecutionEvent>[] cannot be converted to Iterable<? extends Condition<? super T#1>>))
    method Assertions.<T#2>allOf(Condition<? super T#2>...) is not applicable
      (cannot infer type-variable(s) T#2
        (varargs mismatch; Condition<? super ExecutionEvent>[] cannot be converted to Condition<? super T#2>))
  where T#1,T#2 are type-variables:
    T#1 extends Object declared in method <T#1>allOf(Iterable<? extends Condition<? super T#1>>)
    T#2 extends Object declared in method <T#2>allOf(Condition<? super T#2>...)
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
1 warning
:junit-tests:compileTestJava FAILED

[sbrannen]

FYI: I've introduced a new Manual Test Results section to this issue's description and overhauled the Overview and Resources sections.

[marcphilipp]

How would we setup a build for this? Is there a command-line parameter to override the distributionUrl? How would we retrieve the latest one?

[sbrannen]

How would we setup a build for this?

I assume we can do that here: https://adopt-openjdk.ci.cloudbees.com/

Is there a command-line parameter to override the distributionUrl?

Yes, the following works for me locally.

gradlew wrapper --gradle-distribution-url=https://services.gradle.org/distributions-snapshots/gradle-3.0-20160615000025+0000-bin.zip && gradlew -version && gradle clean test

How would we retrieve the latest one?

I don't know if it's possible to automatically get the latest Gradle 3.0 nightly build URL. We'll have to investigate that.

At the moment that is perhaps not so important since our test code doesn't compile against JDK 9. In other words, I think we need to find A working combination before we start trying every combination of two moving targets. 😉

Of course, as previously mentioned, we could set up a separate build on Gradle 3.0 and JDK 9 that only consumes the JUnit 5 artifacts and runs some smoke tests. In other words, we don't necessarily have to compile JUnit 5 with JDK 9; simply testing JDK 8 compiled JUnit 5 artifacts on JDK 9 would be a good start.

[sbrannen]

I have some great news!

If we don't run the junit-tests test suite (which currently doesn't compile; see previous comment in this issue), then the JUnit 5 build actually passes with the following configuration.

• ✅ Gradle 3.0-20160615000025+0000 -- JDK 9-ea+122 --> gradlew clean test -x :junit-tests:test

So the good news is that all JUnit 5 artifacts compile against JDK 9, and all tests for the User Guide (i.e., from the documentation module) pass as well when running on JDK 9! 👍