Have support for JDK 11

[gunnarmorling]

By dumping to a recording file and parsing that, JDK 11 might be a sufficient basis for an alternative mode of operation.

[geoand]

https://github.com/newrelic/newrelic-jfr-core does something similar in order to support JDK 11 (non-streaming use case)

[sebersole]

Hi Gunnar!

We just started producing JFR events in Hibernate and have been using JFRUnit for testing. But we still baseline on Java 11, so this limitation is not ideal for us.

I'd be willing to take a look at supporting Java 11. Any pointers on where to start in your code?

[gunnarmorling]

Hey @sebersole, long time, no see :)

We just started producing JFR events in Hibernate and have been using JFRUnit for testing.

Woot, how cool is that!

But we still baseline on Java 11, so this limitation is not ideal for us.

Gotcha. Have you considered requiring a newer LTS (17, 21) for your own build, while still emitting Java 11 compatible build artifacts? It's quite comfortably doable these days, so that would be my recommendation. Unless anything stops you from building on Java 17+.

I'd be willing to take a look at supporting Java 11. Any pointers on where to start in your code?

References to EventStream should be the main problem here. So you could try and build this code base with Java 11 (EventStream was added in 14) and see where compilation fails. The question then would be how to implement the same functionality without having access to the live JFR event stream which currently is used. One idea was to dump recordings to disk and then load the events from there. This should be a viable approach in general, but one challenge may be to make sure it doesn't make things significantly slower than with the current stream-based approach.

That said, all in all, my recommendation, as stated above, would be exploring whether you can move your build to Java 17 or newer. With Java 21 being released as another LTS just lust month, my appetite for supporting LTS-2 is starting to diminish somewhat.