skip to content

Which JMeter property switches the Regular Expression Extractor off the Jakarta ORO engine?

level: seniorimportance: nice to knowfreq 16%

answer

  1. It is a property, not a GUI field
  2. Commented out in the shipped properties file
  3. The default names a retired Apache library
  4. Any other value flips it to the JDK

basics

~10 s

The property is jmeter.regex.engine. It defaults to oro, and setting it to any other value makes the Regular Expression Extractor compile its pattern with the JDK engine instead.

solid answer

~40 s

JMeter 6.0.0 still ships **Jakarta ORO** as the pattern engine behind the **Regular Expression Extractor**. The switch is the JMeter property `jmeter.regex.engine`, commented out in `bin/jmeter.properties` with a documented default of `oro`; **any** value other than `oro` disables ORO and selects the JDK's built-in engine. It was introduced in JMeter 5.5 and the default has not changed since. Two neighbouring properties size the pattern caches: `jmeter.regex.patterncache.size`, default `1000`, caches compiled patterns for the JDK engine and can be disabled with `0`, while `oro.patterncache.size`, also `1000`, covers ORO. The practical reason to know this is that the two engines are not identical — ORO does not support `\Q` and `\E`, for instance — so a pattern verified elsewhere can behave differently inside the extractor.

code

properties · 10 lines
properties
# bin/user.properties - Apache JMeter 6.0.0

# Any value other than 'oro' selects the JDK regex engine
jmeter.regex.engine=java

# Compiled-pattern cache for the JDK engine; 0 disables it
jmeter.regex.patterncache.size=1000

# Jakarta ORO's own pattern cache, used when the engine stays on 'oro'
oro.patterncache.size=1000

go deeper

for a junior

Not expected at this level. It is enough to know that the Regular Expression Extractor's pattern dialect is not identical to the one in your editor.

for a middle

Be able to say that JMeter bundles Jakarta ORO for this element and that the engine is selectable by a property rather than fixed into the build.

for a senior

Name jmeter.regex.engine, its default of oro, and reach for it when a verified pattern behaves differently inside the extractor instead of rewriting the pattern blind.

for a principal

Decide whether the suite pins the engine explicitly so behaviour does not depend on an unset default, and weigh that against diverging from stock JMeter configuration.

## The property and its default The **Regular Expression Extractor** does not use `java.util.regex` by default. Apache JMeter 6.0.0 still routes it through **Jakarta ORO**, a long-retired Apache library that JMeter bundles. The choice is controlled by one JMeter property, shipped commented out in `bin/jmeter.properties`: ```properties # Ability to switch out the old Oro Regex implementation with the JDK built-in implementation # Any value different to 'oro' will disable the Oro implementation and enable the JDK based. #jmeter.regex.engine=oro ``` The comparison is against the literal string `oro`. There is no enumerated list of engine names — `java`, `jdk` or anything else all mean the same thing, namely "not ORO". ## What the switch actually affects - The **Regular Expression Extractor**'s pattern compilation and matching. - Other JMeter components that share the same pattern-matching helpers. - It does **not** retro-fit ORO onto components that already use the JDK engine; the search box in the View Results Tree, for example, is documented as using the Java engine rather than ORO regardless. ## Why an engineer would ever set it The engines differ in what syntax they accept. JMeter's own regular-expression documentation notes that ORO does not support `\Q` and `\E`, and warns of a quirk affecting certain constructs at the very end of a pattern. A pattern that a colleague verified in a JVM-based tool can therefore behave differently once it is pasted into the extractor's **Regular Expression** field. Flipping the engine is the supported way to get consistent behaviour rather than rewriting the pattern into the ORO dialect. It is also worth knowing simply so that you do not misdiagnose. "My pattern works in my editor but not in JMeter" has a real, boring, documented cause, and it is not the extractor being broken. ## The two pattern caches | Property | Default | Applies to | |---|---|---| | `jmeter.regex.patterncache.size` | `1000` | compiled patterns for the JDK engine; `0` disables the cache | | `oro.patterncache.size` | `1000` | ORO's own pattern cache | Both are commented out by default. They exist because a pattern in an extractor is compiled once per distinct pattern string rather than once per sample, and a plan that builds its pattern from a variable produces a new string every time — which is what a cache of a fixed size is there to absorb. ## Where this sits in an interview Nobody is failed for not knowing `jmeter.regex.engine`. It is a differentiator: knowing that the extractor's engine is a documented, switchable choice — and that the default in 6.0.0 is still the old one — signals that you have read the properties file rather than only the GUI. Keep the answer to the property name, the default, and one concrete reason to change it.

  • Does setting jmeter.regex.engine to java change anything about the Regular Expression Extractor's GUI fields?
    No. The Regular Expression, Template, Match No., Default Value and Field to check fields are unchanged, and the property is not surfaced anywhere in the element's panel. Only how the pattern is compiled and matched changes.
  • What is jmeter.regex.patterncache.size for?
    It bounds the cache of compiled patterns used by the JDK engine, defaulting to 1000 entries and disabled by setting it to 0. Jakarta ORO has its own equivalent, oro.patterncache.size, with the same default.

saying these in an interview costs you the question

  • Assumes the extractor has always used java.util.regex
  • Names a GUI dropdown for choosing the engine
  • Thinks the property takes a fixed list of engine names
  • Confuses the engine property with the pattern cache size
  • Claims switching engines requires a custom build of JMeter