Release new Percentiles Over Time chart

[tilln]

Release of #761.
Depends on cmn v0.9 and graphs-dist v2.1 published to Central.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.05%. Comparing base (09d23ae) to head (ce6874f).
⚠️ Report is 24 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #764      +/-   ##
============================================
+ Coverage     68.90%   69.05%   +0.15%     
- Complexity     2629     2652      +23     
============================================
  Files           230      233       +3     
  Lines         15965    16061      +96     
  Branches       1638     1650      +12     
============================================
+ Hits          11000    11091      +91     
+ Misses         4146     4139       -7     
- Partials        819      831      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[3dgiordano]

@undera @tilln

This Maven release has classes compiled with Java 11 targeting instead of Java 8, which breaks backward compatibility with Java 8, even though the LTS version is supported until 2030.

Also the manifest of the jar mentioned:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.8.7
Built-By: undera
Build-Jdk: 21.0.10 ---> the version 2.0 use 1.8.0_77, Something changed here.

I just discovered this error while updating the plugin in an environment where it's used with Java 8.

I want to warn you so you can see what happened during the compilation and release process to Maven, so you can take the necessary steps to remediate it and avoid propagating the issue in all future releases of this or others plugins.

On jmeter.log you can see some errors like:

2026-03-03 10:56:48,315 WARN o.j.r.Plugin: Unable to load class: kg.apc.jmeter.vizualizers.ResponseTimesOverTimeGui
java.lang.UnsupportedClassVersionError: kg/apc/jmeter/graphs/AbstractOverTimeVisualizer has been compiled by a more recent version of the Java Runtime (class file version 55.0). This version of the Java Runtime only recognizes class file versions up to 52.0.

at java.lang.ClassLoader.defineClass1(Native Method) ~[?:1.8.0_471]
at java.lang.ClassLoader.defineClass(Unknown Source) ~[?:1.8.0_471]
at java.security.SecureClassLoader.defineClass(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader.defineClass(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader.access$100(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader$1.run(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader$1.run(Unknown Source) ~[?:1.8.0_471]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_471]
at java.net.URLClassLoader.findClass(Unknown Source) ~[?:1.8.0_471]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_471]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_471]
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:1.8.0_471]
at java.lang.ClassLoader.defineClass(Unknown Source) ~[?:1.8.0_471]
at java.security.SecureClassLoader.defineClass(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader.defineClass(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader.access$100(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader$1.run(Unknown Source) ~[?:1.8.0_471]
at java.net.URLClassLoader$1.run(Unknown Source) ~[?:1.8.0_471]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_471]
at java.net.URLClassLoader.findClass(Unknown Source) ~[?:1.8.0_471]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_471]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_471]
at org.jmeterplugins.repository.Plugin.getJARPath(Plugin.java:202) [jmeter-plugins-manager-1.11.jar:?]
at org.jmeterplugins.repository.Plugin.detectInstalledPlugin(Plugin.java:108) [jmeter-plugins-manager-1.11.jar:?]
at org.jmeterplugins.repository.Plugin.detectInstalled(Plugin.java:97) [jmeter-plugins-manager-1.11.jar:?]
at org.jmeterplugins.repository.PluginManager.load(PluginManager.java:86) [jmeter-plugins-manager-1.11.jar:?]
at org.jmeterplugins.repository.PluginManagerMenuItem$1.run(PluginManagerMenuItem.java:38) [jmeter-plugins-manager-1.11.jar:?]
2026-03-03 10:56:48,331 WARN o.j.r.Plugin: Unable to load class: kg.apc.jmeter.vizualizers.LatenciesOverTimeGui

[undera]

Unfortunately, certain library dependencies had only way to be resolved by upgrading target version to 11. The workaround is to use older version build. I love to keep things as much compatible as possible, but in this case I had to bump it up :(

[3dgiordano]

Thanks @undera

The old request to incorporate metadata for each release regarding version and JVM architecture compatibility has resurfaced in my mind.

The problem is that the plugin manager performs the update because there's nothing indicating that the version couldn't be updated.

But at launch, the classes fail, and there's no log clearly indicating which plugin failed and that the problem lies in JVM compatibility (It is also possible that there is some other loading problem such as a class or method not found, and the launch would also fail.).
Users have to somehow work around which plugin didn't load and Google the class versions to understand the problem.

Now that there are plugins in Java 8, others in 11, some in 17, and surely some in 21 to coming, this issue will become more common.

In the BlazeMeter HTTP/2 plugin, we compiled the Installer class to Java 8 and implemented JVM version control, displaying a message to the user indicating that the plugin is compatible with Java 11 and later and requires updating their JVM to use it. This was the alternative mechanism you recommended at the time.

Perhaps it's possible to create an installer for these plugins that informs users about this, or explore the possibility of detecting errors during the plugin's loading stage and providing a more user-friendly message.

I'll continue to consider at least the possibility of capturing and providing a better log. If I come up with something and can implement it, I'll share it in a pull request for evaluation.

Regards
David