Add ability to specifcy JMH command line options via gradle's --args option

[Flowdalic]

Gradle's application plugin allows command line arguments to be passed via --args. For example

$ gradle run --args="foo --bar"

It would be great if the jmh tasks would accept those as well and pass them to jmh

$ gradle jmh --args="-p fibNum=42"

[manticore-projects]

One example here is the Blackhole Mode:

# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)

I have no idea, how to set -Djmh.blackhole.autoDetect=false right now.

[jonnybot0]

I've attempted to add command line options support using the @Option annotation, but to no avail. See the gradle docs on the subject.

You can see my branch at https://github.com/jonnybot0/jmh-gradle-plugin/tree/add-cli-arguments-for-gradle-task. I'll cross-post my comment from the Gradle community Slack:

So, I'm struggling to add command line options to a plugin's custom task. For specifics, I'm playing with the JMH plugin for Gradle. I'd like to be able to run the task with different JVM parameters without modifying the build.gradle file.

The JMHTask defines most of its inputs in an interface. Try as I might, I can't find a good way to add command line options to that task without dramatically rewriting the plugin (and not just the task).

From what I can see of the examples (and what I've gleaned from trying different things with the code), you can't add the @Option annotation to an abstract method (like those defined on an interface) unless it takes a boolean. See, for example, the UrlProcess example under the "Documenting available values..." heading. While there's an Option annotation on the abstract getHttp method, the URL string has a concrete setter & getter method.

If I try just adding the @Option annotation to new setter methods on the interface, the plugin fails to apply. See (00536a1ade7dd)

If I try adding default implementations to the setters, even in a separate interface, just for the setters (see 074302bc9ce0), I get errors like: Could not generate a decorated class for type JMHTask. > Cannot have abstract method JmhParameters.getIncludes().. In other words, adding concrete setters of any kind breaks the abstract getters. Yet the getters being abstract is relied on for other parts of the plugin!)

If I just add concrete setter methods to the task class (which is abstract), and throw the @Option annotations on those, and make the getter methods concrete, the plugin itself fails because it's built to rely on generating properties from the abstract class (see b7b1a38312).

Anyone got any tips on adding command line options to Gradle tasks in a way that still lets you have abstract getters? Documentation says there's no programmatic way to do it, so I figure I'm stuck with making the annotation work.

I'm stumped for now. Only way I can see to pass arguments is via Gradle build file configuration, which isn't great.

[jonnybot0]

Though, @manticore-projects, it's worth noting that you can specify all the CLI arguments you would pass to JMH as extension properties in the jmh configuration block. See https://github.com/melix/jmh-gradle-plugin?tab=readme-ov-file#configuration-options

The workaround I've been using is to just create the JMH jar (./gradlew jmhJar) and then run the jar with the JMH command line flags I want like this:

java -jar build/libs/myProject-1.0.0-SNAPSHOT-jmh.jar com.mycompany.SpecificBenchmark -wi 1 #specify warmup iterations and only run one benchmark class
java -jar build/libs/myProject-1.0.0-SNAPSHOT-jmh.jar -r 3s #specify iteration time

That at least lets you use any documented CLI flags from JMH itself.

That still sucks a bit, since the JMH gradle plugin more easily does things like concurrently run a profiler.