Yes, we advocate that all of our users use the bundled JDK. We think this is the simplest for our users, and they have full confidence that Elasticsearch has been tested against the exact version deployed. It takes away the pain of deploying and upgrading the JVM.
When we say that we support JDK N for Elasticsearch X.Y, we mean that we support it for the life of Elasticsearch X.Y, independent of the lifecycle of JDK N. So even though JDK 12 is end of life now, we still support running Elasticsearch 7.3 on it. This alleviates the pressure to upgrade the JVM when it becomes end of life.
We feel this is the best approach for users because we put out minor versions frequently, and we aim to keep upgrading between minor versions simple and straightforward. This means that for users that can deploy new versions of Elasticsearch frequently, they are almost always on a latest JDK that is not end of life.
The only time deviation from this might be necessary is if there is a security issue in the JDK that manifests as a security issue in a maintained version of Elasticsearch. To date, this has never happened, we tend to not use the components in the JDK that are prone to these sorts of issues, and we take a defense in depth approach with the use of the security manager and the use of system call filtering (e.g., seccomp). If there were such a security issue in the JDK that manifested as a security issue in Elasticsearch, we would treat it like any other security issue in Elasticsearch and put out a release that mitigated the security issue.
Rather than talk about what we do in our Cloud service, I will talk about what we are working towards. Sometime in the future (I can’t give a timeline for this), our Cloud service will switch to using the bundled JDK as well. That’s a project that is in-flight.