Hi,
this PR tackles #21604 as discussed. Fortunately, even the automatic JDK upgrade should already work.
Before merging this, #21605 needs to be merged. Apart from that I haven't seen any test failures when I run with the custom buildJavaHome property being set to my local JDK 15 installation.
Cheers, Christoph
Comment From: snicoll
Thanks for the PR @dreis2211
Apart from that I haven't seen any test failures when I run with the custom buildJavaHome property being set to my local JDK 15 installation.
This was required when Gradle does not support the target JDK which does not seem to be case with Java15 at this point. I don't see this PR using that feature either so I am a bit confused.
Switching my local JDK to Java 15ea and building master leads to some failures. Do you have time to look at those?
Comment From: dreis2211
@snicoll You're absolutely right. I was under the impression that I'm getting the same results with the custom home property being set. Let me try with your approach.
Comment From: dreis2211
@snicoll It would have also worked with the custom java home being set, but my tasks were cached and thus not all executed.
I see one additional failure in SampleAntApplicationIT.runJar + the already mentioned multi-release JAR test that is covered by #21605 .
Does that match your local build?
Comment From: snicoll
No, it does not. I have a compilation failure:
> Task :spring-boot-project:spring-boot-tools:spring-boot-loader:compileJava FAILED
/Users/snicoll/workspace/work/spring-boot/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/jar/StringSequence.java:75: error: isEmpty() in StringSequence cannot implement isEmpty() in CharSequence
boolean isEmpty() {
and one test failure before I gave up:
MappingsEndpointReactiveDocumentationTests > mappings() FAILED
org.springframework.restdocs.payload.FieldTypesDoNotMatchException at MappingsEndpointReactiveDocumentationTests.java:126
This in a branch of your first PR I am about to merge. Maybe something is cached and shouldn't be?
$ java -version
openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+26-1287)
OpenJDK 64-Bit Server VM (build 15-ea+26-1287, mixed mode, sharing)
Comment From: dreis2211
openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+17-717)
OpenJDK 64-Bit Server VM (build 15-ea+17-717, mixed mode, sharing)
I guess the first one can be explained by CharSequence.isEmpty being only available in later builds. I'll try the latest JDK 15 build then.
Comment From: dreis2211
I've pushed two additional commits that fix the syntax error and the failure in MappingsEndpointReactiveDocumentationTests
Comment From: dreis2211
I see some intermittent failures for tests that all seem to be related to timing. I wonder if https://bugs.openjdk.java.net/browse/JDK-8242504 is related as this got introduced recently as well. EDIT: After checking the code, I don't think it is related as it should not affect my Mac.
Comment From: dreis2211
I've also seen some flaky tests that are annotated with @WebEndpointTest that prematurely close the connection.
Comment From: dreis2211
I just tried with JDK 14 and see similar flaky failures there as well. Particularly, the "performance" tests ConfigurationPropertySourcesTests seem to fail on JDK 14 on my machine, too. So I wonder if we might already be in the position to consider JDK 15 as done and "simply" have to improve flaky tests across the board.
Comment From: dreis2211
DevToolsIntegrationTests > createAControllerAndThenAddARequestMapping seems to also fail on JDK 8 occasionally already.
Comment From: dreis2211
Trying with 15-ea-27 introduced a change for missing Javadocs: https://bugs.openjdk.java.net/browse/JDK-8242607
That produces quite a lot of warnings like the following:
/Users/christoph.dreis/projects/spring-boot/spring-boot-project/spring-boot-tools/spring-boot-buildpack-platform/src/main/java/org/springframework/boot/buildpack/platform/docker/transport/DockerEngineException.java:35: warning: no comment
private final String reasonPhrase;
It's not breaking the builds, so I guess it's fine for this PR, but probably needs to be tackled in another one.
Comment From: snicoll
Ah ah. I was building locally and I've already polished that checkstyle issue here Christoph.
Comment From: dreis2211
Sorry - I've noticed this one just now. :/