DEV Community: Deniss Larka

The JDK's forgotten JMX protocol

Deniss Larka — Sat, 11 Jul 2026 15:36:29 +0000

Every Java engineer who has connected JConsole — or JDK Mission Control — to a server in
another network segment knows the ritual. Open the JMX port. Discover that RMI quietly opened a second port — random by
default. Pin it with a system property nobody remembers without searching. File a firewall
ticket for both. Wait.

What fewer people know: the JMX specification shipped with a second remote transport that has
none of these problems. One socket, one port, TLS underneath if you want it. It's called JMXMP —
the JMX Messaging Protocol. It lost for the least mysterious reason in software — RMI shipped
by default, JMXMP was a separate download, and defaults win — and its reference implementation
has been effectively abandoned since around 2008. Yet it never quite died. Code that refuses
to die usually knows something.

I didn't set out to resurrect it. I fell into it.

The port dance, briefly

The default remote JMX stack rides on RMI. The connection URL tells you most of the story:

service:jmx:rmi:///jndi/rmi://host:1099/jmxrmi

I'll spare you the full anatomy behind that URL — there's a JNDI lookup in it, and that second,
dynamically assigned port from the ritual above; few people ever learn the details, which is
rather the point. Dynamic ports were a reasonable design for 1999's flat networks. Between
today's firewalls, NAT, and containers, they're friction — not because RMI is bad, but because
the network it was designed for no longer exists.

The JMXMP URL:

service:jmx:jmxmp://host:9875

One socket. TCP in, TCP out. That's the whole networking story.

How I ended up in this codebase

I maintain JConsoleBooster, a modernized JConsole. It shipped fine for
years on the 2008-era JMXMP jar — the one historically distributed as jmxremote_optional /
jmx-optional, out of Sun's OpenDMK project, republished over the years by several parties
because people kept needing single-socket JMX.

Then I moved the app to a jlink-built runtime. An automatic module from 2008 does not
cooperate with the module system: no module-info, split-package hazards, services declared
in ways jlink can't see. The choices were: abandon the transport, or take responsibility
for the code.

So I forked it and took the code apart — 87 files of 2007 Sun code. I won't pretend I read
every line myself; it's 2026, and AI did much of the first-pass reading. The rule that
mattered: nothing got deleted, changed, or believed without a proof — a test, a
zero-references check, an API diff.

What's inside a library frozen in 2008

Some of what I found is what you'd expect from code written for a platform that no longer
exists. Some of it surprised me:

Dead RMI plumbing — in the socket-protocol library. Proxy references, unmarshalling helpers, an RMI exporter. The generic connector framework was written to serve both transports, and the RMI half stayed behind like scaffolding nobody removed. I deleted it after proving zero references.
Plaintext defaults. Encryption and authentication existed — as options, off unless asked. Normal for 2007; indefensible for something you point at a JVM in production today.
An authorization check that fails open on current JDKs. It was written for the SecurityManager era: it asks the runtime for the caller's identity through an API that, on a modern JDK, always answers "nobody" — and it treats "nobody" as "security isn't enabled here, let it through." On the JVMs of its time, correct. On today's, an allow-all with extra steps.
And the part that made the effort worth it: the protocol itself is fine. Message-based, single connection, SASL negotiation for auth, TLS for transport — the design decisions Sun made hold up. The packaging aged. The idea didn't.

That last point matters. This isn't a rewrite-because-old-code-is-bad story. The original
authors solved the right problem well; the code just outlived the platform assumptions around
it.

The second life

druvu-lib-jmxmp 2.0.0, on Maven Central,
Java 21 baseline — the same protocol, newborn. Three changes carry the release; everything
else is detail.

1. It's a real Java module — and still a drop-in. The monolith is now three JPMS modules
(com.druvu.jmxmp.common / server / client), and jlink treats them as first-class
citizens. The public API — javax.management.remote.jmxmp and friends — is kept frozen,
verified by a snapshot test that diffs the exported surface against the original. If your code
compiled against jmxremote_optional, it compiles against this.

2. The server refuses to run open. Authentication is mandatory — the server env can't be
built without it — and the connection is encrypted either way: bring your own TLS context, or
the server generates an ephemeral self-signed certificate at startup. This costs adoption
convenience, and I decided that's the
right trade: nobody exposes a management port to the world on purpose, but unauthenticated
JMX endpoints keep showing up in the wild by accident, and they're a documented entry point for
cryptominers. This library's answer is that the accident can't happen.

Map<String, ?> env = JmxmpServerSecurity.builder()
        .tls(sslContext)                  // optional — omit it, get an ephemeral self-signed cert
        .authenticator(myAuthenticator)   // SASL/PLAIN — required
        .build();                         // refuses to build without an authenticator

Mandatory authentication buys something besides keeping strangers out. Plenty of teams use
JMX operations as the low-ceremony alternative to building an admin UI: change a setting at
runtime, flip a feature toggle, trigger a business operation. It works — until something
changes in production and nobody can say who changed it, or when. With every connection
authenticated, the operation knows its caller:

@Override
public void switchFeature(String name, boolean on) {
    String operator = Subject.current().getPrincipals().iterator().next().getName();
    log.info("{} switched feature '{}' {}", operator, name, on ? "on" : "off");
    features.put(name, on);
}
// log: "john switched feature 'beta-checkout' on"

The connector runs each request inside the authenticated subject's context, so
Subject.current() in your MBean is the operator who issued the call — an audit trail with
no extra plumbing.

3. It fails closed. The SecurityManager-era identity lookup is gone; the server reads the
authenticated subject from Subject.current(), and a request with no subject is refused, not
waved through. Deserialization — the classic JMX attack surface — goes through a
deny-by-default filter (JmxmpSerialFilter): allow-listed classes deserialize, everything else
doesn't, before any application code sees the bytes. Authorization beyond authentication is
there if you need it: a small RBAC SPI with a programmatic policy builder, default-deny.

The precise diffs — what was removed, what each fix looks like — are in the repo history and
release notes. I'd rather link them than paraphrase them.

Did it survive contact with reality?

The test matrix runs the connector in every module arrangement — both sides modular, both on
the classpath, mixed. That matrix earned its keep: it caught the freshly-modularized library
silently behaving as a classpath citizen in one spot, where a Class.forName reached across a
module seam it had no right to cross. "It compiles with a module-info" and "it's modular" are
different claims; only a test can tell them apart.

And it runs in production of a sort: JConsoleBooster ships on it — every remote connection the
app makes goes through this library.

Where it stands on security claims

Deliberately narrow. I'm not going to call the library "secure" — that's an adjective, not a
fact. The facts: the fail-open path is fixed, transport encryption and authentication are
non-optional, deserialization is allow-listed, and the delta for each is inspectable commit by
commit.

It's maintained by one person, best-effort, latest-version-only — the support model is
spelled out in SECURITY.md. GitHub private vulnerability reporting is switched on. If you
can break it, I want to know.

When you should not use this

An SSH tunnel to the default RMI connector already works for you. Then it works. This is for when the tunnel is the friction.
You're below Java 21. The library assumes a modern JDK; the old republications exist and stay where they are.
You need anonymous local monitoring. JConsole attaching to a local PID doesn't involve remote JMX at all — nothing to change.
Your daily client is JDK Mission Control. JMC speaks the default RMI connector; teaching it JMXMP is a plugin dance this library doesn't attempt to solve. Stock JConsole could historically be coaxed into it with the connector on its classpath; JConsoleBooster speaks it out of the box.
Your security model lives in the old access-file / SecurityManager mechanics. That machinery is gone here, not emulated; migrating means adopting the SASL + RBAC model.

Coordinates

<dependency>
    <groupId>com.druvu</groupId>
    <artifactId>druvu-lib-jmxmp</artifactId>
    <version>2.0.0</version>
</dependency>

Repo: github.com/DenissLarka/druvu-lib-jmxmp
— issues and the pinned "what next" thread are the feedback channel. If you're running JMXMP
somewhere unusual, I'd genuinely like to hear what it's doing there.

ServiceLoader is great — until you want a constructor argument

Deniss Larka — Thu, 11 Jun 2026 11:59:59 +0000

I was building a small library that reads accounting files — GnuCash first, other formats maybe later. It's the textbook case for pluggable implementations: an AccBook interface in the API module, one implementation per format in its own module, and the application picks up whichever one is on the path.

Why not AccBook book = new GnucashAccBook(path) and move on? For one format in one app — do exactly that. But the moment your code says new GnucashAccBook, it depends on that implementation: the GnuCash module has to be on the compile path, its classes exported, its name written in every place that opens a book. Add a second format and each of those places grows an if. The interface stops protecting you once you name the class behind it.

Java already ships the tool for exactly this. No framework, no container, works on the module path: ServiceLoader. So I reached for it. Then I hit a wall I'd hit before and forgotten about.

The naive version

The interface is plain:

public interface AccBook {
    String id();
    List<Account> accounts();
}

Discovery is genuinely easy:

AccBook book = ServiceLoader.load(AccBook.class).findFirst().orElseThrow();

But my GnucashAccBook can't do anything without the file path. And ServiceLoader only knows how to call a no-arg constructor (or a static provider() method). There is nowhere to hand it the Path.

So you reach for one of two workarounds, and both are worse than they look.

Workaround 1 — construct empty, configure after:

AccBook book = ServiceLoader.load(AccBook.class).findFirst().orElseThrow();
((Configurable) book).init(path);   // ...and hope nobody touched `book` before this line

Now the object exists in an invalid state between construction and init. You've swapped a constructor argument for a runtime contract the compiler can't see. (And findFirst() quietly picks one if two implementations are on the path — hold that thought.)

Workaround 2 — put a factory behind ServiceLoader:

public interface AccBookFactory {
    AccBook create(Path path);
}

AccBook book = ServiceLoader.load(AccBookFactory.class)
        .findFirst().orElseThrow()
        .create(path);

This one is actually the right shape. But now every project grows an XFactory interface, the findFirst().orElseThrow() dance, and — if you care that two implementations on the path is a mistake — your own "throw if more than one" check. I wrote that glue three times before I admitted it was a pattern.

Extracting the pattern

So I pulled it into a tiny library, druvu-lib-loader. It is the factory-behind-ServiceLoader pattern, made generic once, with the implementation's arguments passed through a type-keyed map.

The implementation side becomes a factory that receives its arguments:

public class GnucashBookFactory implements ComponentFactory<AccBook> {
    @Override
    public AccBook createComponent(Dependencies deps) {
        return new GnucashAccBook(deps.getDependency(Path.class));
    }
    @Override
    public Class<AccBook> type() {
        // Seasoned Spring developers will recognize the silhouette of an old friend.
        // This one retires right after construction, though — no container moves in.
        return AccBook.class;
    }
}

You register it exactly like any other service — META-INF/services, or in module-info.java:

provides com.druvu.lib.loader.ComponentFactory
    with com.myapp.gnucash.GnucashBookFactory;

And in the API module you give callers one obvious entry point — a static load right on the interface:

public interface AccBook {
    String id();
    List<Account> accounts();

    static AccBook load(Path path) {
        return ComponentLoader.load(AccBook.class, Dependencies.of(Path.class, path));
    }
}

So everything the caller ever sees is this:

AccBook book = AccBook.load(path);

The constructor argument is passed. A single implementation is guaranteed — ComponentLoader.load throws if two factories match the type, instead of silently choosing one. No container, no annotations, no classpath scanning.

And when multiple implementations are the point — a plugin system, an exporter per format — the same pattern flips around:

List<Exporter> exporters = MultiComponentLoader.loadAll(Exporter.class, deps);

Every registered factory gets the same Dependencies, you get all the instances. Same discovery, same argument-passing, opposite cardinality rule.

It's not magic

AccBook.load(path) isn't reflection sorcery and it isn't a new DI framework. Underneath it is still ServiceLoader, still the JPMS provides/uses you would have written anyway. The static load is a plain method you write once. The only thing the library adds is the part the JDK left out: a typed way to pass arguments to the implementation, plus a fail-fast "exactly one" rule.

One honest caveat. The compiler checks what you put into Dependencies — Dependencies.of(Path.class, path) won't accept a String where a Path belongs. But it can't check that you supplied everything the factory will ask for. Forget the Path and the code still compiles — it fails only when load() runs and getDependency(Path.class) comes up empty. This is a real difference from Spring: Spring checks all its wiring at startup, so a missing bean stops the app from booting. Here there is no startup check — the check happens when you call load(). Call it at startup and you catch the mistake at startup. Call it later, and you catch it later. The good news: the load(...) call and the factory that reads it sit right next to each other, so when it fails, there is one obvious place to look. But the compiler won't catch it for you.

When not to use it

If your implementations have no-arg constructors, you don't need any of this — plain ServiceLoader is the right answer, and the library falls back to it anyway. If you already run inside Spring or Guice, use the container you have; this isn't trying to replace it. It earns its place in one specific spot: libraries and modular components that need pluggable, argument-taking implementations without dragging in a container.

That's the whole idea

It's on Maven Central as com.druvu:druvu-lib-loader — source and docs on GitHub, Apache-2.0, Java 21+. If you've ever hand-written the factory-behind-ServiceLoader glue yourself, I'd genuinely like to know whether this matches how you did it — or where you'd have done it differently. Issues and disagreement welcome.