skip to content

What does `implementation = JvmImplementation.J9` do in a toolchain spec, and how does it combine with the vendor constraint?

level: middleimportance: should knowfreq 30%

answer

  1. JvmImplementation.J9 vs VENDOR_SPECIFIC
  2. OpenJ9 engine, IBM Semeru
  3. ANDed with vendor + version
  4. default = VENDOR_SPECIFIC (HotSpot)
  5. no auto-inference between vendor/impl

basics

~10 s

implementation selects the JVM engine. The default is VENDOR_SPECIFIC (the vendor's normal HotSpot-based JDK); J9 restricts to OpenJ9-based builds (e.g. IBM Semeru). It's an extra filter on top of vendor and version.

solid answer

~40 s

`JvmImplementation` is the third toolchain constraint. Two values exist: - `VENDOR_SPECIFIC` (default) — whatever JVM the chosen vendor normally ships, in practice HotSpot for most distributions. - `J9` — only JDKs built on the **Eclipse OpenJ9** VM (a different JIT/GC implementation), e.g. IBM Semeru / AdoptOpenJDK-OpenJ9. ```kotlin java { toolchain { languageVersion = JavaLanguageVersion.of(17) vendor = JvmVendorSpec.IBM implementation = JvmImplementation.J9 } } ``` All three constraints are ANDed together: Gradle must find (or provision) a JDK that is version 17 **and** vendor IBM **and** OpenJ9-based. OpenJ9 has different memory/startup characteristics (often lower footprint), so teams pin it when those characteristics matter. If you set `J9` with a vendor that never ships OpenJ9, resolution simply finds nothing and fails — the constraints are independent and not auto-reconciled.

code

kotlin · 7 lines
kotlin
java {
  toolchain {
    languageVersion = JavaLanguageVersion.of(17)
    vendor = JvmVendorSpec.IBM
    implementation = JvmImplementation.J9
  }
}

go deeper

for a junior

Recognise that implementation exists and that J9 selects the OpenJ9-based JDK rather than the default.

for a middle

Explain VENDOR_SPECIFIC vs J9, that they AND with vendor/version, and that mismatches just fail to resolve.

for a senior

Reason about when OpenJ9 matters (footprint/startup) and why to keep the spec minimal otherwise.

for a principal

Weigh standardising the runtime engine across the org vs portability/provisioning cost, and encode it in a convention plugin.

## The third toolchain knob Beyond `languageVersion` and `vendor`, a `JavaToolchainSpec` exposes `implementation`, typed as `JvmImplementation`. It distinguishes between the **VM engine** a JDK is built on: - **`VENDOR_SPECIFIC`** — the default. Means "don't care about the engine; take the vendor's standard JDK." For nearly every distribution that is **HotSpot** (the OpenJDK reference VM). - **`J9`** — restrict to JDKs built on **Eclipse OpenJ9**, an alternative JVM (originated at IBM) with its own JIT and garbage collectors. It typically has a smaller memory footprint and fast startup, which is attractive for containers/serverless. It ships in distributions like **IBM Semeru Runtime** and the legacy AdoptOpenJDK-OpenJ9 builds. ## How it combines with vendor and version The three constraints form a logical **AND**. The toolchain resolver looks for a JDK matching ALL of: ``` languageVersion == 17 AND vendor == IBM AND implementation == J9 ``` Gradle does **not** infer a vendor from `implementation`, nor vice versa. So `implementation = JvmImplementation.J9` with a vendor that has no OpenJ9 build is unsatisfiable and the build fails at resolution. ```kotlin java { toolchain { languageVersion = JavaLanguageVersion.of(17) vendor = JvmVendorSpec.IBM // Semeru implementation = JvmImplementation.J9 // OpenJ9 engine } } ``` ## Where the value comes from during detection During **local detection**, Gradle inspects each candidate JDK's metadata; OpenJ9 JDKs identify themselves so Gradle can apply the `J9` filter. During **auto-provisioning**, the implementation is passed to the resolver (Foojay), which maps it to an OpenJ9-flavoured download. ## When to use it Pin `J9` only when the runtime engine genuinely matters (footprint/startup benchmarks, parity with a production runtime that uses OpenJ9). Otherwise leave it at the default `VENDOR_SPECIFIC` to keep the spec as loose as possible, which makes matching/provisioning easier and the build more portable.

  • What is the default value of `implementation`?
    `JvmImplementation.VENDOR_SPECIFIC`, which means the vendor's standard JDK (HotSpot in practice) — the engine is not constrained.
  • If you request J9 but the vendor only ships HotSpot, what happens?
    The constraints are ANDed and unsatisfiable, so toolchain resolution finds no match and the build fails; Gradle does not silently substitute HotSpot.

saying these in an interview costs you the question

  • Thinking J9 means 'Java 9' — it refers to the OpenJ9 VM, not a language version.
  • Assuming setting implementation also sets the vendor automatically — the constraints are independent.

context

resolving links…