[Feature] Response of Temurin JDK 11 EOF at Oct 2024

[wu-sheng]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

According to Temurin's official page, the JDK 11 should be End of Availability At least Oct 2024.

Ref to https://adoptium.net/support/

To avoid the outdated JDK version for various platforms compiling, we should begin to investigate and prepare the JDK upgrade.
Through #11464, I made OAP and UI Webapp running in the JDK21 image. Now, we should decide whether we choose JDK 17(next TLS) or skip it to JDK 21 directly.

❗ Updated on Nov. 8th, JDK 21 and/or JRE 21 as runtime are not available for now.

Groovy 3(we are using) doesn't support JRE 21, as well as the latest stable version Groovy 4.
JRE 21 support is in the Grooxy 5, but it is at alpha stage only.
So, the current status is, that we could change the base image to Zulu is Temurin is not updated next year.

FYI all @apache/skywalking-committers If you have any preference, please comment here and explain the reasons, thanks.

---

Updated on Nov. 8th

Oracle OpenJDK

According to Zipkin server(v3 is sharing SkyWalking kernel), JDK 17 is required.
And Oracle OpenJDK 11/17/21 has many years before EOF. Although we don't use Oracle OpenJDK, but this is a good reference before taking actions.

Azul Zulu OpenJDK

Zulu OpenJDK has a longer JDK11 support too.

Are you willing to submit a pull request to implement this on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[Superskyyy]

I personally favor JDK 21 for the full implementation of virtual threads that JDK 17 doesn't have. It could be a major throughput enhancer.

[wu-sheng]

I personally favor JDK 21 for the full implementation of virtual threads that JDK 17 doesn't have. It could be a major throughput enhancer.

I am thinking about JDK 21 too, although I am not sure whether the virtual thread feature is really helpful.

[tisonkun]

It seems that we have already been compatible with both JDK 17 and JDK 21 as we release oap on those JRE. So the tasks here are to increase the minimal JDK version and perhaps do some cleanups & improvements?

whether the virtual thread feature is really helpful

Yep. I suppose that virtual thread introduces a new pattern that we don't have to deal with complex callback-composition of futures. But the performance (upper bound) is the same as well-written async code in futures. Moreover, currently, all the virtual threads share a global scheduler (a ForkJoinPool just like the commonPool but a separate one), which may be a step backward considering SkyWalking has already built a concurrency model and separate concurrency groups.

Back to the topic and original question, if there is no strong reason to stay in JDK 17, I suggest moving to JDK 21. And as long as the common usage of OAP is pulling Docker image, this upgrade should be almost transparent.

[kezhenxu94]

We won't gain all the new (exciting) features/improvements in higher version by simply bumping up the JDK, that can't be a good reason to bump up the JDK version to a very recent version unless we plan to rewrite some of the codes, take the virtual thread as an example. Also, JDK 11's being EOL is not a big issue for us, the SkyWalking project can already run on Java 11, 17, and 21, users can decide which one is preferable in their own case to install on their environment, they have more choices, if we set the minimum required version to 21, they can only install/upgrade to Java >=21.

I personally always upgrade all softwares to the latest versions for my own use, but for an open source project, this will greatly impact our users.

[wu-sheng]

My intention is only about the required JDK version should be secured with CVE patches and maintaince by the official team.

That is the only reason I refer to Temurin's official page.

[mrproliu]

I'm making an important transition in Zipkin v3 where the underlying kernel will be replaced with SkyWalking. With this shift, it's crucial to highlight that the main Zipkin repository comprises two distinct services: zipkin-core and zipkin-server.

The zipkin-core is essentially the core library utilized for third-party service integrations and is compiled and released with OpenJDK11. The choice for OpenJDK11 is due to JDK12's inability to produce Java 1.6 bytecode, ensuring compatibility for our clients.

For zipkin-server, while the compilation and release are also performed with OpenJDK11. However, within Docker images, we run the container using OpenJDK 17.

I suggest we upgrade the Docker image for the zipkin-server to run on OpenJDK21, while continuing to use OpenJDK 11 for compilation and release processes on zipkin-core and zipkin-server.

[wu-sheng]

@mrproliu Could you confirm the OpenJDK thing? The OpenJDK should have no update, and fully changed to Temurin.

Which are your JDK/JRE actually being used?

[mrproliu]

Which are your JDK/JRE actually being used?

Upon reviewing the openzipkin/docker-java project, it appears that the Docker version of OpenJDK being used is the Oracle OpenJDK. Referring to Oracle's official Java SE Support Roadmap, I noticed that support for version 17 is extended until September 2026.

[wu-sheng]

Which are your JDK/JRE actually being used?

Upon reviewing the openzipkin/docker-java project, it appears that the Docker version of OpenJDK being used is the Oracle OpenJDK. Referring to Oracle's official Java SE Support Roadmap, I noticed that support for version 17 is extended until September 2026.

Thanks. I have updated the original issue description about Zipkin side reference.

[wu-sheng]

@kezhenxu94 If we want to keep on OpenJDK 11 distro by default, we may need to switch the base image for it. I have updated Oracle OpenJDK and Zulu OpenJDK above. What do you think?

cc @tisonkun as you asked about this. Generally, we are not urgent to adopt Virtual Thread, as the benefits are not clear.

[kezhenxu94]

@kezhenxu94 If we want to keep on OpenJDK 11 distro by default, we may need to switch the base image for it. I have updated Oracle OpenJDK and Zulu OpenJDK above. What do you think?

We can bump up the Java version in the base docker image to whatever (Temurin 17 or 21) because as a Docker container it's self-contained and it doesn't impact the users' environment, the only concern of mine was not to set the MINIMUM required Java version to too high, so the users have more choices if they are not using Docker images.

[wu-sheng]

@kezhenxu94 If we want to keep on OpenJDK 11 distro by default, we may need to switch the base image for it. I have updated Oracle OpenJDK and Zulu OpenJDK above. What do you think?

We can bump up the Java version in the base docker image to whatever (Temurin 17 or 21) because as a Docker container, it's self-contained and it doesn't impact the users' environment, the only concern of mine was not to set the MINIMUM required Java version to too high, so the users have more choices if they are not using Docker images.

Got it. Your proposal is, that we are keeping the compiler output in 11, only updating the runtime JRE. This means, we don't accept any new language level features higher than JDK 11. Am I getting you right?

[kezhenxu94]

Got it. Your proposal is, that we are keeping the compiler output in 11, only updating the runtime JRE. This means, we don't accept any new language level features higher than JDK 11. Am I getting you right?

Exactly. That's all my opinion.

[tisonkun]

that we are keeping the compiler output in 11, only updating the runtime JRE. This means, we don't accept any new language level features higher than JDK 11

This sounds good as long as there is no significant improvements from JDK 17 or JDK 21.

While, although I agree that keep JDK as b/w compatible as possible is good for client (library), it benefits little for server side application. The SkyWalking OAP, if I get it right, is the final application that using a new JDK doesn't affect users; especially they are using the Docker image mostly.

[wu-sheng]

While doing #11514, I tried once to compile OAP/UI with JDK21(Zulu), there is at least one test lib having a JDK21 support issue, system-stubs-core. Tracked at webcompere/system-stubs#73

[wu-sheng]

Groovy 3(we are using) doesn't support JRE 21, as well as the latest stable version Groovy 4.
JRE 21 support is in the Grooxy 5, but it is at alpha stage only.

So, the current status is, that we could change the base image to Zulu is Temurin is not updated next year.