Why does JMeter, not the JVM, handle a -D flag typed on the jmeter command line?

A `-D` typed on JMeter's command line looks exactly like a JVM launcher option, and that resemblance is the trap. The JVM never sees it. JMeter parses it, and JMeter applies it, some milliseconds into its own startup. ## Where your arguments actually go The last line of `bin/jmeter` builds the java command like this: ```sh "$JAVA_HOME/bin/java" $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@" ``` Everything you typed arrives in `"$@"`, which sits **after** `-jar`. A java launcher stops consuming options at the point it identifies the main artefact; from there on, every word is an application argument handed to `main(String[])`. So `jmeter -n -t plan.jmx -Dfoo=bar` gives the JVM no `-D` at all — it gives JMeter a four-element argument array. ## What JMeter does with it `JMeter.start` builds a `CLArgsParser` over that array. `-D` matches the descriptor registered as `systemproperty`, and `JMeter.initializeProperties` executes: ```java case SYSTEM_PROPERTY -> { if (!value.isEmpty()) { log.info("Setting System property: {}={}", name, value); System.getProperties().setProperty(name, value); } else { log.warn("Removing System property: {}", name); System.getProperties().remove(name); } } ``` So the property is genuinely set — through the ordinary `System.setProperty` API, from inside the running application. ## What follows from the timing Two consequences matter in practice: - **A real launcher option cannot be supplied this way.** Heap sizing, a garbage collector choice, a `-javaagent`, a module flag: those are consumed only before `-jar`, so typing them on the jmeter command line either produces an unknown-option error from JMeter's own parser or is silently taken as something else. - **Anything that reads the property earlier will miss it.** `initializeProperties` runs early — it is the first thing `JMeter.start` does inside its try block — but "early in JMeter" is still after the JVM has booted, after the launcher jar's classes have initialised and after log4j2 has been configured. A static initialiser that samples a system property before that point sees the old value. For most settings this is irrelevant, because the code that consumes the property reads it when it needs it. `RmiUtils`, for example, calls `System.getProperties().getProperty("java.rmi.server.hostname")` at the moment it resolves a host, long after the property phase has run. The timing only bites where a value is sampled once, in a class initialiser that ran earlier. ## How to tell which happened `jmeter.log` settles it. If JMeter applied the flag, there is a line for it: ``` INFO o.a.j.JMeter: Setting System property: javax.net.ssl.trustStore=/etc/pki/prod.jks ``` If the line is absent, JMeter never processed that flag — check that it was actually accepted and not swallowed as an argument to a preceding option. And if you needed the value before JMeter started at all, it does not belong on the jmeter command line; it belongs on the java command that the launcher script assembles, ahead of `-jar`. ## The staging-to-production angle This is why a plan that serves staging and production keeps the two kinds of difference apart. The endpoint, the user count and any plan-visible switch travel as `-J`, applied by JMeter and readable from the plan. A per-environment trust store travels as `-D`, applied by JMeter but read by JSSE. Anything that has to shape the JVM itself is not a per-run flag at all — it is part of how the injector is launched. Behaviour described is Apache JMeter 6.0.0.