Junit5: Test with JDK 9 Early Access builds

Created on 7 Jun 2016 · 21Comments · Source: junit-team/junit5

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
[x] 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

build task

Source

marcphilipp

Most helpful comment

UPDATE

Our first Travis CI build using JDK 9 EA and Gradle 3.0 nightly builds just passed!

https://travis-ci.org/junit-team/junit5/jobs/141875942

So, now that this is in place, I am closing this issue.

However, we will still need to manually upgrade the Gradle 3.0 nightly build URL unless somebody provides a solution for automatically detecting the _latest_ Gradle 3.0 nightly build.

sbrannen on 2 Jul 2016

👍2

All 21 comments

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.

sbrannen on 7 Jun 2016

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

marcphilipp on 14 Jun 2016

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.

sbrannen on 14 Jun 2016

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

See https://github.com/gradle/gradle/commit/d482d32627eba564d8f385d95dffe5c3dbbe27ec#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)

mkobit on 14 Jun 2016

@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 on 14 Jun 2016

Update: I just added a _Deliverable_ for this issue.

sbrannen on 14 Jun 2016

✅ 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 on 14 Jun 2016

FYI: I've introduced a new _Manual Test Results_ section to this issue's description and overhauled the _Overview_ and _Resources_ sections.

sbrannen on 14 Jun 2016

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?

marcphilipp on 15 Jun 2016

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 on 15 Jun 2016

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! 👍

sbrannen on 15 Jun 2016

Update

In e6fead4cd7bf7caa859eade7fb4ef7e89379f19a, I refactored ExecutionEventConditions so that JUnit 5 can be compiled with OpenJDK 9 early access builds.

Consequently, it is now possible to run the entire JUnit 5 build (including all tests) using JDK 9!

sbrannen on 15 Jun 2016

👍1

Nice, @sbrannen!

I still consider this a bug in JDK 9, though. Did you open a ticket over at OpenJDK?

marcphilipp on 15 Jun 2016

Yes.... I in fact literally just submitted a bug which is waiting for approval.

I will post back here if it gets approved.

I also found a related bug report that appears to also be based on the use of Condition and allOf() from AssertJ; however, I went ahead and submitted our specific use case to make sure the OpenJDK team introduces the proper regression tests for both use cases in their test suite.

sbrannen on 15 Jun 2016

For anyone interested, the following is the code I submitted for the aforementioned bug in JDK 9.

public class Test {

    public class Condition<T> {}

    @SafeVarargs
    public static <T> Condition<T> allOf(Condition<? super T>... conditions) {
        return null;
    }

    public static <T> Condition<T> allOf(Iterable<? extends Condition<? super T>> conditions) {
        return null;
    }

    @SafeVarargs
    public static Condition<Number> compose(Condition<? super Number>... conditions) {

        // Compiles on JDK 8 and JDK 9
        Test.<Number> allOf(conditions);

        // Compiles on JDK 8 but *fails* on JDK 9
        allOf(conditions);

        return null;
    }
}

sbrannen on 15 Jun 2016

Thanks, @sbrannen! 👍

marcphilipp on 15 Jun 2016

Update

My bug report has been accepted.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8159680

The reviewer commented that the current behavior may not be legitimate, but they are looking into it in any case.

sbrannen on 16 Jun 2016

Update: build passes with Gradle 3.0-20160627000036+0000 and JDK 9-ea+124

sbrannen on 27 Jun 2016

FYI: there is preliminary support for JDK 9 on Travis CI.

Details here: https://github.com/travis-ci/travis-ci/issues/5520

I've updated the description of this issue accordingly.

sbrannen on 2 Jul 2016

UPDATE

Our first Travis CI build using JDK 9 EA and Gradle 3.0 nightly builds just passed!

https://travis-ci.org/junit-team/junit5/jobs/141875942

So, now that this is in place, I am closing this issue.

However, we will still need to manually upgrade the Gradle 3.0 nightly build URL unless somebody provides a solution for automatically detecting the _latest_ Gradle 3.0 nightly build.

sbrannen on 2 Jul 2016

👍2

Very interesting and useful work! I appreciate this and will reuse your .travis.yml for my projects (and move from JUnit 4 to 5).

hastebrot on 21 Oct 2016

Was this page helpful?

0 / 5 - 0 ratings

Related issues

ParameterResolutionException with TestInfo and Parameterized Tests

littleclay · 3Comments

`junit-testkit` usability feedback

mkobit · 5Comments

Vintage engine does not report multiple errors collected by ErrorCollector

smoyer64 · 6Comments

Allow non-static methods to be annotated by @BeforeAll and @AfterAll

ondrejlerch · 4Comments

Fix Gradle consumption of junit-jupiter-engine

marcphilipp · 3Comments

Junit5: Test with JDK 9 Early Access builds

Overview

Resources

Deliverables

Manual Test Results

July 2, 2016

June 27, 2016

June 15, 2016

Most helpful comment

All 21 comments

Related issues