Java 11 as Che master runtime

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 https://github.com/eclipse/che/issues/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 https://github.com/eclipse/che/issues/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.

[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.

[sleshchenko]

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