jmx_exporter
jmx_exporter copied to clipboard
prometheus
Drop support for Java 8
Java 9 introduced some significant optimizations to String concatenation that should improve the performance of jmx_exporter considerably, since it does a lot of String concatenation.
However, to gain this benefit, jmx_exporter must be compiled to target at least JDK 9.
Java 8 is (as of March 2024 this year) now 10 years old, and has been officially EOL by Oracle since March 2022.
I propose we bump the compiler source and target versions to 9. While OpenJDK 9 is also EOL, I don't see any benefit from requiring users to use anything higher just yet.
While there may be some users still using JDK 8, it should be quite unlikely.
While I agree, that no one should be using Java 8 at this point, there are still users using it and vendors supporting it.
Azul has support for Java 8 until 2030
https://www.azul.com/products/azul-support-roadmap/
AWS has support for Corretto until May 2026
https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-corretto-8-11-support-extended/
Removing support would be problematic for the community.
@dhoard I had a feeling that would be the response, which is why I raised this as a discussion rather than a PR.
I'm curious, do you have evidence that there are users running JDK 8?
I wonder if it might be possible to produce multiple JARs. One for JDK 8, and one compiled for a newer JDK?
This type of evidence is hard to prove/disprove.
I can only infer there are Java 8 users, hence possibly Java 8 JMX Exporter users, since multiple companies have paid extended support. (Oracle sells extended support until December 2030.)
Fair point.
How about we create two Maven profiles, one for targeting JFK 8, and one to target JDK 9, then release multiple artifacts?
Shouldn't be too difficult to sort out, although looking through the CI, I couldn't determine how release artifacts are distributed to GitHub/Maven Central.
We were generating two artifacts when we supported Java 6 and Java 8 and it was a total mess. I'll have to put some thought into an approach that will work.
In the meantime, I'll build it myself. This should enable me to quantify any performance improvement.
@nicktelford have you been able to quantify any performance improvements?
I have tested targeting different Java versions (8, 11, 17, 21) via pom.xml changes along with relevant integration test containers and everything works as expected. CI/CD changes would be required, but are manageable. It would be a 4x increase in published artifacts.
The dependent libraries in client_java are all compiled with a Java 8 target, so it may be a moot point since most of the String handling occurs in that code.