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.
Top comments (0)