In JMeter's Java Request sampler, which interface must your class implement and when is each method called?

The Java Request sampler is Apache JMeter's built-in escape hatch to compiled code: the way to make JMeter drive a client library, a proprietary protocol or an internal SDK without writing a full plugin with GUI classes, and without leaving the plan's timing, assertions and listeners behind. ## The contract Your class implements `org.apache.jmeter.protocol.java.sampler.JavaSamplerClient`, which declares exactly four methods: - **`Arguments getDefaultParameters()`** - the parameter names and default values the sampler's argument table is pre-filled with when someone picks your class in the GUI. It is documentation as much as configuration. - **`void setupTest(JavaSamplerContext context)`** - one-time preparation: build the client, open the connection pool, read a keystore. - **`SampleResult runTest(JavaSamplerContext context)`** - one sample. Everything a listener will show comes out of the `SampleResult` you return. - **`void teardownTest(JavaSamplerContext context)`** - one-time cleanup. Almost nobody implements the interface directly. `AbstractJavaSamplerClient` supplies no-op implementations plus a logger, so a real client overrides only what it needs. ## When each method actually runs This is the part candidates get wrong. `setupTest` is **not** called when the test starts; the sampler creates its client lazily and calls `setupTest` immediately before the first `runTest` on that instance. JMeter clones the test tree per thread, so each thread gets its own client object and its own `setupTest` call. `teardownTest` has a subtlety worth knowing: if a subclass of `AbstractJavaSamplerClient` does not override `teardownTest`, JMeter does not register the sampler for teardown at all and the inherited method is never called. The manual states this explicitly and gives the reason - it reduces JMeter's memory requirements. If you need cleanup, you must override the method; inheriting it is not enough. ## Writing runTest 1. Read what you need from the `JavaSamplerContext` - `getParameter(name)` and friends. Every argument arrives as a `String`, so parse and validate there. 2. Call `sampleStart()` on the `SampleResult`, do the work, call `sampleEnd()`. Anything outside that window is not measured. 3. Set `setSuccessful(true|false)`, a response code and a response message, and a sample label if you want something other than the element's name. 4. Never let an exception escape unrecorded - catch it, mark the result failed, and put the message in the response data so a listener can show it. A `runTest` that returns a result it never timed produces samples of zero elapsed time, which is a silent way to make a load test meaningless. ## How JMeter finds your class The Classname drop-down is populated by JMeter's combined lookup: implementations registered as Java services are loaded first, and then the jars on JMeter's component search path - `lib/ext` plus anything `search_paths` adds - are scanned for classes implementing `JavaSamplerClient`. Two examples ship with JMeter and always appear: `JavaTest`, useful because it lets you set values in almost every field of the result so assertions and extractors can be exercised, and `SleepTest`. If your class is missing from the list, the jar is in the wrong directory or the class is not public with a no-argument constructor; if it is in the list but errors, JMeter's log points at the `search_paths` and `plugin_dependency_paths` properties, which is usually a missing dependency rather than a missing plugin. ## Where it fits against the alternatives A Java Request is the right hook when the code is genuinely compiled and reusable: a protocol client, a signing routine that needs a real library, a workload driver you already own in Java. It costs a build and a deployment step for every change, which is its main disadvantage against JMeter's scripting elements. The JUnit Request sampler is the neighbouring hook and works differently: it scans for classes extending JUnit's `TestCase` rather than for a JMeter interface, takes no name/value parameters, and looks in `lib/junit`. Choose Java Request when you want parameters and a `SampleResult` you control; choose JUnit Request when you already have JUnit classes and want to drive them as-is.