# jmxterm: an interactive JMX client for the terminal

> jmxterm is a Java command line JMX client that gives you the same access to an MBean server that jconsole gives you, from a console you can script, and it can also be driven from Perl, Shell and Python. It suits operators and developers who need to inspect a running JVM over SSH, and it is not a monitoring system, since nothing in it records history or alerts you.

**jiaqi/jmxterm** — Interactive command line JMX client

- Repository: https://github.com/jiaqi/jmxterm
- Website: http://docs.cyclopsgroup.org/jmxterm
- Stars: 563 · Forks: 155
- Language: Java
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/jiaqi-jmxterm

## What jmxterm is for: MBean access without a display

jmxterm is an open source, command line based interactive JMX client written in Java. It lets users access a Java MBean server from a command line console without a graphical environment, and the project describes itself plainly as a command line alternative to `jconsole`.

That framing tells you the audience. A JVM is easy to inspect on a workstation with a desktop attached. It is awkward on a production host reached over SSH, where `jconsole` needs a display and a local UI, or inside a container with no X server. jmxterm exists for exactly that situation, and for the case where you want to run a series of JMX operations repeatedly without clicking through a GUI.

The other half of the project is embedding. JMXTerm can be embedded in non-Java programming languages such as Perl, Shell, and Python, allowing those languages to access a Java MBean server programmatically. That is a different use from the interactive console, and the repository keeps separate documentation for it under `doc/scripting.md`, alongside the source notes, the features list, the user manual and the FAQ.

One dependency detail is worth knowing before anything else: JMXTerm relies on the `jconsole` library at runtime. The project reuses that library rather than reimplementing the MBean introspection, and the uberjar bundles it so that a user does not have to think about it.

The project is Apache-2.0 licensed, the default branch is `main`, the last push to the tree was on 2026-10-15, and the documentation site is at docs.cyclopsgroup.org/jmxterm.

## Downloading the uberjar and getting a console in seconds

There is no package manager step, no configuration file, and no directory to create. The README is blunt about this: the downloaded uberjar runs out of the box with `java -jar`, there are no dependencies to install, and no configuration, file structure, permission, or log directory to set up.

The download itself is a manual step. The README says to find the latest release on the right side of the GitHub page, and the release list shows v1.0.4 from 2022-10-27 as the newest, with v1.0.3 from 2022-08-06 and v1.0.2 from 2020-09-04 before it.

```bash
java -jar jmxterm-1.0.4-uber.jar
```

Running it without any options opens the interactive console, and the commands inside are described as self-explained.

```bash
jiaqi@happycow:~$ java -jar jmxterm-1.0.4-uber.jar

Welcome to JMX terminal. Type "help" for available commands.

?$
```

The prompt is `?$`, which is worth noting because it is the marker that tells you the console is live and accepting commands. Everything after that point is a small command language, and the version placeholder in the download line is filled with whatever release you actually fetched, so the file name changes with the version.

The uberjar approach also means the tool is trivially portable. Copy one file to a host, and you have a working JMX client, which is a different operational model from installing a monitoring agent or configuring a remote connector on every target.

## The help command is the actual documentation

Inside the console, the `help` command lists everything available. Asking for help on a specific command, for example `help get`, or using the `-h` option, prints the usage for that command alone.

```bash
> help get
usage: get [-b <val>] [-d <val>] [-h] [-i] [-q] [-s]
Get value of MBean attribute(s)
-b,--bean <val>    MBean name where the attribute is. Optional if bean
                   has been set
-d,--domain <val>  Domain of bean, optional
-h,--help          Display usage
-i,--info          Show detail information of each attribute
-q,--quots         Quotation marks around value
-s,--simple        Print simple expression of value without full
                   expression
* stands for all attributes. e.g. get Attribute1 Attribute2 or get *
```

Reading that output tells you the shape of the whole tool. Attribute access takes a bean name and an optional domain, and the star is a wildcard for all attributes of a bean, so `get *` dumps everything about the current bean. The `-i` flag asks for detail information about each attribute rather than just the value, and `-s` asks for the simple expression of a value instead of the full expression, which is the difference between a readable number and a Java object graph.

The domain and bean flags are optional in the way you would expect from a MBean server, where names are hierarchical. If a bean has already been set in the session, `-b` can be omitted, which is what makes a sequence of commands against the same bean short. The `-q` flag wrapping values in quotation marks looks trivial but is the thing that makes the output pasteable into a shell command or a script without re-quoting by hand.

The repository links the user manual for anything beyond this, and points to the Maven generated reports and the Javadoc for reference detail.

## Embedding the client from Perl, Shell and Python

The embedding story is the part of jmxterm that goes beyond being a nicer jconsole. The project states that JMXTerm can be embedded in non-Java programming languages such as Perl, Shell, and Python, allowing these languages to access a Java MBean server programmatically.

The difference in approach is worth spelling out, because it decides which tool you want. The interactive console is for a human at a terminal, where you type commands and read the answers. The embedded form is for a script that needs a value from a JVM as one step in a larger job, and it is the scripting document that covers it, with its own page in the `doc/` directory.

The practical appeal is that a monitoring or deployment script written in Shell or Python does not have to shell out to a Java program, start a JVM, and parse console output to get one attribute. It can talk to the MBean server directly as a library, and it stays in the language the rest of the tooling is written in.

The trade-off is that this is the less documented half of the project. The README's own links point to a user manual for the console and a separate scripting document for the embedded form, and the repository's other documentation covers features, sources and the FAQ. There is no benchmark, no comparison of scripting approaches, and no statement about which languages have been exercised against which JVM versions, so if embedded use is your primary requirement, the scripting page is the document to read before committing.

One structural point connects back to the earlier section: because the same code is used by the console and by the embedded form, the `jconsole` library dependency is shared, which is why the uberjar approach works for the standalone case.

## Building from source with the shipped Dockerfile

For most users the uberjar is the whole story, but the repository ships a `Dockerfile` that shows how the artefact is put together, and it is a reasonable path for producing a pinned build yourself.

The image is based on `openjdk:8`, which is the single most important line in the file. The build copies the source to a temporary directory, downloads Apache Maven 3.6.3 from the Apache distribution server, runs `mvn install`, and then copies the produced uberjar to `/opt/jmxterm/jmxterm.jar` using a version string read out of the Maven archiver properties. The working directory is set to `/opt/jmxterm` and the container command is `java -jar jmxterm.jar`.

```dockerfile
FROM openjdk:8

COPY . /tmp/jmxterm
```

```dockerfile
WORKDIR /opt/jmxterm

CMD ["java", "-jar", "jmxterm.jar"]
```

That Java 8 base is worth pausing on. The released uberjar is 1.0.4 from 2022, and the container build pins an OpenJDK 8 image, so the project targets a Java version from before Java 9. A Java 8 client can still connect to a much newer JVM over JMX, since the protocol is not tied to the client's runtime in that way, but if your target JVM requires a modern JMX configuration or a newer security scheme, the client side is old regardless.

The repository also has a `Vagrantfile` and a `.travis.yml`, alongside `pom.xml` and the `src/` directory. A `Dockerfile` and a `Vagrantfile` in the same tree is the shape of a project that expects both a local VM and a container workflow for trying the tool without touching a host installation.

## What jmxterm does not do, and where a different tool belongs

The limitations follow from the design. jmxterm is a client, not a monitoring system. It holds no history of attribute values, it does not schedule collection, it does not alert, and it does not keep a registry of the targets it has talked to. Every session starts empty and ends when you leave it. If you want to know what a JVM's heap looked like last Tuesday, or to be paged when garbage collection goes bad, this is the wrong tool, and the README does not pretend otherwise.

The second limitation is the Java version. The latest release is v1.0.4 from 2022-10-27, and the container build pins an OpenJDK 8 base. The repository is not archived and the last push was on 2026-10-15, so work continues on `main`, but no new release has been cut since 2022, and the released artefact and the tree are not the same thing. Anyone building from `main` is building something the project has not tagged.

The third is the connection model. jmxterm is a client for a JVM that has JMX remote access turned on, and it does not remove that requirement. A JVM with remote JMX disabled, or one behind a firewall without the port open, is unreachable from this client. And the security settings that expose JMX remotely are, in most deployments, the most exposed part of the JVM, which is why a command line client that can be driven from a script deserves the same caution as a GUI one.

The alternative approach is a proper monitoring agent that pulls the same MBean attributes on a schedule, stores them, and gives you history and alerting, or a JMX exporter that turns the MBean values into metrics that an existing monitoring stack already understands. The difference is in the data flow: jmxterm is a point query answered interactively, a monitoring agent is a time series collected continuously. For an incident, where you want one value now, the point query is faster and simpler. For anything that needs a trend, only the collector works.

## Conclusion

Adopt jmxterm if you need to poke at a live JVM from a terminal or a script, over SSH, on a machine with no display, and you want the same MBean view jconsole gives you. Do not adopt it as a monitoring layer, because it holds no history, raises no alerts and is not meant to run unattended against many targets. Before you rely on it, download the uberjar from the releases page, run `java -jar jmxterm-1.0.4-uber.jar` to confirm the console opens on your JDK, and check that the target JVM's JMX remote settings match what you intend to use, since the client cannot connect to a JVM that has remote JMX disabled.

## FAQ

### How do I run jmxterm for the first time?

Download the latest release from the GitHub releases page and run the uberjar with `java -jar jmxterm-1.0.4-uber.jar`. There are no dependencies to install and no configuration, file structure, permission, or log directory to set up, and the console opens with a `?$` prompt.

### What is the difference between jmxterm and jconsole?

jmxterm is a command line alternative to `jconsole`, giving access to a Java MBean server from a console without a graphical environment. It relies on the `jconsole` library at runtime rather than reimplementing MBean introspection.

### Can I use jmxterm from a script instead of typing at the console?

Yes. The project states that JMXTerm can be embedded in non-Java programming languages such as Perl, Shell, and Python, allowing those languages to access a Java MBean server programmatically. The details are in the scripting document in the repository's `doc/` directory.

### How do I see all attributes of an MBean in jmxterm?

The `get` command accepts a star as a wildcard for all attributes, for example `get *`, and you can ask for help on it with `help get` or the `-h` option. The `-i` flag shows detail information for each attribute and `-s` prints the simple expression of a value.

### What Java version does jmxterm target?

The Dockerfile in the repository is based on `openjdk:8`, so the build targets Java 8. The latest release is v1.0.4 from 2022-10-27, and the last push to the `main` branch was on 2026-10-15.

## Sources

- [jiaqi/jmxterm on GitHub](https://github.com/jiaqi/jmxterm)
- [License: Apache-2.0](https://github.com/jiaqi/jmxterm/blob/main/LICENSE)
- [Project website](http://docs.cyclopsgroup.org/jmxterm)
- [README](https://github.com/jiaqi/jmxterm/blob/main/README.md)
- [Releases](https://github.com/jiaqi/jmxterm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jiaqi-jmxterm