Switch images to use jdk11

[fiidim]

I've always built and deployed SCDF apps using openjdk 11.0.8. Prior to 2.7 the image my apps deployed ok. After moving to 2.7 I now get:

java.lang.UnsupportedClassVersionError: <class> has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
    at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_282]
    at java.lang.ClassLoader.defineClass(ClassLoader.java:756) ~[na:1.8.0_282]
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) ~[na:1.8.0_282]
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) ~[na:1.8.0_282]
    at java.net.URLClassLoader.access$100(URLClassLoader.java:74) ~[na:1.8.0_282]
    at java.net.URLClassLoader$1.run(URLClassLoader.java:369) ~[na:1.8.0_282]
    at java.net.URLClassLoader$1.run(URLClassLoader.java:363) ~[na:1.8.0_282]

Not sure why the project went backwards a version, and I haven't found release notes on how to introduce newer runtimes. Did I miss something?

Was:

[root@rhel76pr repository]# docker exec -it skipper /bin/bash
root@a1dca0b40e15:/# find . -name 'java'
./usr/lib/jvm/jre-11.0.8/bin/java
root@a1dca0b40e15:/# /usr/lib/jvm/jre-11.0.8/bin/java -version
openjdk version "11.0.8" 2020-07-14 LTS
OpenJDK Runtime Environment (build 11.0.8+10-LTS)
OpenJDK 64-Bit Server VM (build 11.0.8+10-LTS, mixed mode)

[jvalkeal]

Ah this was a mistake we/I made when moving image generation from maven plugin to paketo. scdf/skipper 2.6.x/2.5.x were on jdk8, scdf/skipper 2.7.x/2.6.x were on jdk11. I think we were supposed to be jdk8 even on 2.7.x as we were afraid to pump up but looks like we silently went on with jdk11.

Having said that, we can go back to jdk11 in next maintenance release.

Sorry for this, and thanks for reporting.

[jvalkeal]

In a meanwhile, I did manually push new images to dockerhub with different tag names which now have jdk11(if you want to try those)

pack build \
 --path spring-cloud-skipper-server-2.7.0.jar \
 --builder gcr.io/paketo-buildpacks/builder:0.1.99-base \
 --env BP_JVM_VERSION=11 springcloud/spring-cloud-skipper-server:2.7.0-jdk11

pack build \
 --path spring-cloud-dataflow-server-2.8.0.jar \
 --builder gcr.io/paketo-buildpacks/builder:0.1.99-base \
 --env BP_JVM_VERSION=11 springcloud/spring-cloud-dataflow-server:2.8.0-jdk11

pack build \
 --path spring-cloud-dataflow-composed-task-runner-2.8.0.jar \
 --builder gcr.io/paketo-buildpacks/builder:0.1.99-base \
 --env BP_JVM_VERSION=11 springcloud/spring-cloud-dataflow-composed-task-runner:2.8.0-jdk11

[fiidim]

Thanks for looking at this. It's an interesting dilemma though. If skipper itself needs a 1.8 runtime, but the apps that run in the skipper image need a higher minimum runtime, it almost seems that the jre or build image needs to have an option runtime version for the apps.

It looks like other people are/were doing the same thing. This issue talks about needing 14, and this issue reports a warning with 11.

In the meantime, I will try out your new images and let you know. When I did the upgrade I also hit an issue with docker-compose.yml and local maven repositories. I'm not sure whether the latest docker-compose.yml file introduced something ahead of the build or not. Definitely related to having /home/cnb vs /root for mounting the local repository.

[fiidim]

Change looks good (using -jdk11 suffixed images). The only noteworthy difference is an additional innocuous stderr message:

stderr:
Picked up JAVA_TOOL_OPTIONS: -Djava.security.properties=/layers/paketo-buildpacks_bellsoft-liberica/java-security-properties/java-security.properties -agentpath:/layers/paketo-buildpacks_bellsoft-liberica/jvmkill/jvmkill-1.16.0-RELEASE.so=printHeapHistogram=1 -XX:ActiveProcessorCount=8 -XX:MaxDirectMemorySize=10M -Xmx16237962K -XX:MaxMetaspaceSize=186629K -XX:ReservedCodeCacheSize=240M -Xss1M -Dorg.springframework.cloud.bindings.boot.enable=true