DEV Community: Deniss Larka

Write your pages in PHP. Run them on the JVM.

Deniss Larka — Sat, 15 Aug 2026 10:39:16 +0000

druvu-lib-web 2.0.0 is out: a small Java web framework on Jetty 12 whose template language is PHP. Not "PHP-like" — the 2.0 engine runs real PHP 8 layouts: variables, every control structure, string interpolation, heredocs, includes, arrow functions, and 115 standard functions, with semantics settled by running whole templates against PHP 8 and matching its output byte for byte. There is no PHP runtime anywhere — the engine is Java, your handlers are Java, and request.setAttribute("customer", customer) becomes $customer in the page.

One thing is deliberately different from PHP: output is HTML-escaped by default, with raw() as the opt-out — forgetting is safe instead of being a hole. (That's also the main breaking change from 1.x.) Repo, docs and a runnable example: https://github.com/DenissLarka/druvu-lib-web. If you try it and a template renders differently than real PHP would — that's a bug by definition, and I want to hear about it.

What JConsole would look like if anyone had kept going

Deniss Larka — Mon, 03 Aug 2026 15:00:00 +0000

There's a kind of Java engineer for whom JMX is not a monitoring buzzword but a daily
instrument: you connect to a live JVM, read a queue depth, flip a feature toggle, invoke the
operation somebody exposed years ago for exactly this situation. I'm one of them — my day job
keeps me close to production JVMs where guessing is expensive. And the universal client for
this work is JConsole: it ships with every JDK, speaks to any JVM, and needs no server, no
agent, no vendor.

It also fights you, every single day, in the same three places.

Every operation argument is a raw text field. The MBean wants an ISO date, or one of exactly
three legal values, or a file path — JConsole hands you an empty string box and wishes you
luck. There are no saved connections: every morning, the same host:port typed from memory,
for every JVM in your care. And remote connections ride RMI, whose two-port firewall dance is
a story of its own.

None of it is hard to fix. It simply never was.

The rule I'm breaking

The 2026-approved answer is to stop using a desktop tool: ship the metrics to an APM, build a
Grafana dashboard, deploy an agent. All three are good answers. One still opening a window in 2026
is somebody who cannot let go of his childhood toys, and I have decided to accept the charge.

The toys have one advantage. None of the approved answers covers the moment that actually
defines JVM ops: you, one specific production JVM, right now — read this value, invoke this
operation, watch what happens. For that, I want a direct
connection, no platform in between, nothing to deploy before I can look.

JConsole has survived twenty years — and it's open source. Meanwhile the JDK quietly solved the historical pain of shipping desktop Java: jlink and
jpackage make a self-contained, installable app practical — own runtime bundled, no JDK
required on the target machine.

The pieces were on the table. I forked JConsole and started fixing my own daily frictions.
The result is JConsoleBooster — and three
changes carry it.

It did occur to me, somewhere around the third weekend, that Oracle ships a thing called VisualVM, and that a reasonable person would have opened it before hand-editing a twenty-year-old
Swing dialog. I gave the thought the consideration it deserved and went back to the dialog.

1. Operations become forms, not string fields

MBean operation parameters can declare lightweight markup — a combo of legal values, a date, a
file — and the Operations tab renders real widgets for them: a dropdown instead of a string
box, a date picker instead of an ISO-format guessing game, a file chooser instead of a
hand-typed path. Results that are JSON come back pretty-printed instead of as a one-line brick.
An operation that returns a file (a report, an Excel export) downloads like a file, not like a
byte[] toString.

Nothing about your MBeans has to change wholesale — the markup is opt-in, plain JConsole
renders the same operations as plain strings.

2. Your whole estate, one menu

Connections live in a bookmarks file: plain text, grouped, with *bold* and [red ALERT]
markup for the entries that deserve visual weight — production vs staging, the box that pages
you at night. The file is yours: version it, share it with the team, edit it in any editor.
JConsoleBooster renders it as a menu, and any JVM in your care is one click away instead of a
host:port recital.

3. Installs — and updates — like a real app

Signed and notarized .dmg for macOS (Apple Silicon), signed .msix for Windows, .AppImage
for Linux — each with the Java runtime bundled via jlink, so the target machine needs no JDK,
no JAVA_HOME, no ceremony.

And once it's installed, it keeps itself current. A running copy notices the next release,
downloads it and applies it — no download page, no reinstall; on Windows that took about two
and a half seconds for a 37 MB package. The three operating systems hold strong and entirely
incompatible views on how an application may replace itself while running, and I have given up
trying to change their minds: Windows swaps the package and restarts, macOS mounts the new build
and asks you to quit and drag it across, Linux replaces the file and asks for a restart.

The Linux AppImage is unsigned — Linux has no OS signing gate — use SHA-256, as Mr. Stallman would.

The transport, in one paragraph

For remote JVMs, JConsoleBooster's default transport is JMXMP — the JDK's forgotten
single-socket JMX protocol: type a bare host:port and you connect over one fixed port through
the firewall, no RMI two-port dance. I revived and hardened that library as a separate project;
the full story is in
The JDK's forgotten JMX protocol.

When the box has no screen

The JVMs that most need poking often sit on machines with no display at all. So the same tool
runs headless: a REPL that speaks JMXMP, or -e for a scripted one-liner, with the same
transport, certificate-trust and credential rules the window enforces — the GUI is a front end,
not the product. There's an optional single-jar build for when copying one file to a bastion
host is the entire deployment story.

Tested daily, where it matters

I run JConsoleBooster every working day against real production JVMs. Every feature above
exists because the default behaviour cost me time in a real workflow — and earned its place by
surviving daily use since. Whatever fights me next becomes the next release; that loop is the
development model.

Right now, that's the updater. It asks nobody's permission for anything — an excellent quality in
a background service and a poor one in a colleague, particularly one who closes your window
while you are still using it. So that's what's next.

And one idea I keep turning over without deciding: a tab that renders HTML an MBean hands back.
Your service exposes a single method that returns a form; the app draws it, posts your answer
back, draws whatever comes next. An operations console for your service, for the days you need
to control the thing and don't want to build a front end for it. Tell me if you'd use that — or
why it's a terrible idea.

Downloads: druvu.com/downloads/jconsole-booster
— pick your OS. Repo:
github.com/DenissLarka/jconsole-booster — issues welcome. If JMX is part of your day, I'd genuinely like to hear what still fights you.

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>${latest.version}</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.