Java 11 as Che master runtime

[skabashnyuk]

Description

There is a couple of good things that are making reasonable to consider an upgrade Che-master runtime to Java 11.
Such as:

• Native continers support https://blog.docker.com/2018/04/improved-docker-container-integration-with-java-10/
• TLS 1.3 support Java 8 cannot handle some SSL certificates #12959 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8202625
• Java 11 is next LTS release. http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001823.html
• Different language and performance improvements
  https://metebalci.com/blog/what-is-new-in-java-11/
  https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html
  https://dzone.com/articles/90-new-features-and-apis-in-jdk-11
  https://www.journaldev.com/24601/java-11-features
  https://habr.com/ru/post/424683/

Things to consider.

• At this moment is possible to build on Java 11 but not run because of new modular system "Error occurred during initialization of boot layer java.lang.module.FindException: Module java.xml.bind not found", this issue is unavoidable, we can't reuse Java 9 approach like this https://github.com/eclipse/che-lib/blob/master/che-tomcat8-slf4j-logback/src/assembly/bin/setenv.sh#L39. to handle it we will need to do some upgrade of some libs https://stackoverflow.com/a/52502208/318536
• We have some java asm code which is not compatible with Java 11. https://github.com/eclipse/che/tree/master/core/che-core-dynamodule-maven-plugin.
  There is two option here. First - to upgrade asm lib and adapt the code to Java 11. Second - since it would be used only on che-master where startup time is no longer critical we may deprecate this code at all. Need to consider both options.
• Docker image size: There is no official alpine based OpenJDK image. That means that we can select ether Debian based or Centos or UBI or something like that anyway
  overall image size may be increased. At this moment I would prefer openjdk:11-slim.

openjdk                                                   11-slim                   5cc6ea6c24c4        13 days ago         468MB
openjdk                                                   11.0.3-jdk-slim-stretch   5cc6ea6c24c4        13 days ago         468MB
openjdk                                                   11-stretch                0aa10063a184        13 days ago         815MB
openjdk                                                   11.0.3-jdk-stretch        0aa10063a184        13 days ago         815MB
registry.access.redhat.com/openjdk/openjdk-11-rhel7       latest                    b4bc55e73486        2 weeks ago         494MB
openjdk                                                   8u191-jdk-alpine          e9ea51023687        5 weeks ago         105MB

• Error prone https://github.com/google/error-prone configuration and plugin are not compatible with Java 11 at this moment

I doubt that this issue we are able to deliver before Che 7 GA I can propose such a plan:

1. Wait when we clean up master from CHe6 related code Eclipse Che plan regarding Docker infrastructure and GWT IDE #12243
2. Decide what to do with che-core-dynamodule-maven-plugin. I vote for remove.
3. Decode what image to use. I vote for openjdk:11-slim
4. Identify dependencies that are needed to be upgraded.

[nickboldt]

Might be related #14545

[sparkoo]

+1 for openjdk:11-slim. It uses official signed upstream builds by Red Hat. Image itself is managed by docker guys, which should be fine. It's based on debian. I would rather have centos, but couldnt find any suitable. RHEL based images does not make sense for upstream.

[benoitf]

I would opt it for the smallest image of the runtime for upstream
including https://hub.docker.com/r/adoptopenjdk/openjdk11/tags?page=1&name=alpine-jdk

and have alternates with newer JDK like Java 13 (even if non LTS support) https://hub.docker.com/_/openjdk?tab=tags&page=1&name=alpine and/or ubi8 images

Also this time it seems smallest image that we can get is with ubi8-minimal + java11

FROM registry.access.redhat.com/ubi8/ubi-minimal
RUN microdnf install java-11

194M Sep 20 09:26 adoptopenjdk-openjdk11-x86_64-alpine-jdk-11.0.4_11.tar.gz
214M Sep 20 09:24 openjdk:11-slim.tar.gz
147M Sep 20 09:24 ubi8-java11.tar.gz

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[skabashnyuk]

/remove-lifecycle stale

[nickboldt]

Any chance this might happen in 7.13? It would be great to move Che builds up to use JDK 11, if we can. 8 is well past EOL.

[benoitf]

@nickboldt Where did you read that openjdk 8 is EOL ?

[skabashnyuk]

@nickboldt
Even if we have plenty of time

EOL
January 2019 for Oracle (commercial)
December 2020 for Oracle (personal use)
At least May 2026 for AdoptOpenJDK
At least June 2023[7] for Amazon Corretto
Source : https://en.wikipedia.org/wiki/Java_version_history

I agree with you. Sooner or later we have to do that. More time we postpone this - then harder it would be to implement. I have some changes that moving this forward. I will try to provide prs for that soon.

[sleshchenko]

@nickboldt it already has P2 and team assigned, could you elaborate more why you added need-triage label?

[sparkoo]

I guess this is the most important source of OpenJDK support for us https://access.redhat.com/articles/1299013 -> May 2026

I'm all for moving to newer Java as soon as possible and we should aim to be on latest LTS or even on latest.

8 has currently longer support than 11, but once we update to 11, moving upwards became much much easier. Keeping us on LTS means updating once in 3 years.