Drop support for Java 8

[nicktelford]

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.

[dhoard]

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.

[nicktelford]

@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?

[dhoard]

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

[nicktelford]

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.

[dhoard]

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.

[nicktelford]

In the meantime, I'll build it myself. This should enable me to quantify any performance improvement.

[dhoard]

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

[dhoard]

Closing

[nicktelford]

@dhoard Sorry, I didn't see your message back in April.

I can't quantify it exactly, but I did compile jmx_exporter myself (targeting Java 17), and noticed a considerable performance improvement.

The flamegraph in my comment in #919 shows poor performance of StringBuilder appends. It turns out that in Java 8, String concatenation is "optimized" by swapping it out for StringBuilder appends at runtime. This is why I say that it's String concatenation, specifically in jmx_exporter, that is the cause of this performance hit.

In Java 9, this optimization was changed to use invokedynamic instead, which performs much better. See: JEP 280

client_java may also benefit from this optimization, but I have not tested that. I believe the big boost comes from jmx_exporter because it has to concatenate a very large number of Strings together to produce the scrape output text.

[dhoard]

@nicktelford I have been working on/testing a potential Java build/integration testing change that will build targeted releases.

Here are zips of the latest JMX Exporter jars targeting specific Java versions.

java8.zip
java11.zip
java17.zip
java21.zip

• built using Amazon Corretto 21
• still uses client_java targeting Java 8

Any testing is much appreciated!

[nicktelford]

@dhoard what testing are you looking for in particular?

[dhoard]

@nicktelford the latest code uses the latest client_java with some performance improvements. I'm looking to see if it truly improves #919

i.e. Is the change worth the complexity?