JediTerm: the terminal widget JetBrains put inside its IDEs

A terminal widget, not a terminal emulator for users

The main purpose of the project is stated plainly: to provide a pure Java terminal widget that can be easily embedded into an IDE. It supports terminal sessions both for SSH connections and for a local PTY on macOS, Linux and Windows. The distinction between a terminal emulator and a terminal widget is the whole design constraint. An emulator for humans has to handle window resizing, fonts, selection, clipboard and the thousand small behaviours a person expects. A widget has to live inside someone else's window, take their styling, and behave under their layout. The library is used by JetBrains IDEs including PyCharm, IDEA, PhpStorm, WebStorm, AppCode, CLion and Rider, which means the constraints of that environment are the constraints the code is written against.

Four sub-projects, and the one that is not listed

The README says the project consists of four sub-projects and then lists three of them. The terminal sub-project is the core library, providing the VT100 compatible terminal emulator and the Swing based terminal panel UI. The pty sub-project is the jediterm-pty.jar library, which uses the Pty4J library to enable a terminal for local PTY sessions. The JediTerm sub-project is the standalone version distributed as a dmg for macOS. The counting is off by one in the documentation, and the repository layout makes the missing piece visible: alongside those directories there are core, ui, gradle and the gradle properties file. So the real shape is a core library, a UI module, the PTY bridge and the standalone application, which is four things, with the README having collapsed two of them.

The feature list is short and it is the point

Seven features are listed. There is a local terminal for Unix, Mac and Windows using Pty4J. There is xterm emulation, which the README says passes most of the tests from vttest. There is xterm 256 colours. There is scrolling, copy and paste, and mouse support. There is terminal resizing from the client or the server side, which matters because a terminal's dimensions are negotiated and the two ends have to agree. And there are terminal tabs. What is missing from that list is as informative as what is in it: there is no mention of shell integration, hyperlinks, configuration formats, search, or a theming system, because those are the concerns the embedding application owns. The widget draws characters and reports events.

The standalone application is a separate deliverable

Since version 2.5 there has been a standalone version of the JediTerm terminal, provided as a macOS distribution, and the standalone sub-project is the one distributed as a dmg. To run it from sources you execute jediterm.sh or jediterm.bat, or you take the binary distribution from the releases page. Both scripts sit at the repository root next to the gradlew wrapper scripts, which tells you the standalone build is part of the same Gradle project rather than a separate repository. The README also notes that the standalone distribution relies heavily on customised Swing UI widgets taken from the IntelliJ Community platform repository by JetBrains, which is a real constraint for anyone who wants to reuse the application outside that ecosystem, since the UI layer is coupled to IntelliJ components even though the emulator core is not.

It is built with Gradle, in Kotlin DSL

Gradle is used to build the project, and the build files are in the Kotlin DSL rather than the Groovy one, with a build.gradle.kts at the root and a settings.gradle.kts beside it. There is a gradlew and gradlew.bat wrapper, so a build does not need a system Gradle, plus a gradle.properties and a gradle directory for the wrapper configuration. There is also a travis-settings.gradle file and a .travis.yml, which dates the continuous integration setup to Travis rather than GitHub Actions, and a ChangeLog file rather than release tags, since the repository has no GitHub releases. The VERSION file at the root records the version separately from the build script, which is what a library consumed as a source dependency by several IDEs tends to need.

Where the terminal behaviour actually comes from

The README is candid about the ancestry. The initial version of JediTerm was a reworked terminal emulator called Gritty, which was in turn a reworked JCTerm implementation, and there is now nothing in the source left from Gritty or JCTerm because everything was rewritten from scratch, with a lot of new features added. The character set designation and mapping implementation is based on respective classes from jVT220 by J.W. Janssen, under the Apache 2.0 licence. So the protocol semantics were reimplemented rather than copied, with one clear exception acknowledged. The links section points at the sources those decisions rest on: the xterm control sequence protocol description, the terminal character set terminology and mechanics from the Kermit documentation, the VT420 programmer reference manual, the Pty4J library, the JSch library, a UTF-8 demonstration file, a control sequence visualizer, and the vttest suite that the emulation claims to pass.

The licence is a choice you make

JediTerm is dual-licensed under both the LGPLv3, in the LICENSE-LGPLv3.txt file at the root, and the Apache 2.0 licence, in LICENSE-APACHE-2.0.txt, and you may select one of them at your option. That is worth pausing on, because the two licences ask different things of you. The LGPL is the copyleft option, and embedding an LGPL library into a proprietary application raises the question of how the library is relinked and whether the modifications have to be published. Apache 2.0 is the permissive option, with an explicit patent grant and no requirement to open your own source. The repository's licence field records LGPL-3.0, which is only half the picture, so the decision has to be made from the two files rather than from the metadata. The licence of the borrowed character set classes is Apache 2.0, and the standalone distribution carries the IntelliJ Community platform Swing widgets, which have their own terms.

Where JediTerm is the wrong choice

Four limits apply. It is a Swing widget, so it fits desktop Java and nothing else, and the standalone application is coupled to IntelliJ UI components, which narrows what you can do with it outside a JetBrains environment. The SSH transport is JSch, a library that has been unmaintained for a long time, so if SSH security is the point of your product, this is the dependency to examine rather than the emulator. The emulation is good enough to pass most of vttest rather than all of it, and the failing remainder is exactly the set of edge cases a user notices when something renders wrongly. And it is a UI component with no notion of a session manager, so connection profiles, key management and reconnection are your problem to build on top.

Editorial conclusion

Use JediTerm when you are building a desktop tool that needs a real terminal inside it, because it gives you a VT100 emulation layer, a Swing panel and a local PTY without you writing a terminal emulator. Do not use it as a general SSH client library, because the SSH side comes from JSch and the project is really an emulator with a transport attached. Verify first which licence you want, since the project is dual licensed under LGPLv3 and Apache 2.0 and you choose, that the JSch dependency still meets your security requirements, and how much of the xterm test suite you actually pass, because the claim is most of vttest rather than all of it.

Frequently asked questions

Official sources

1. Issues
2. JetBrains/jediterm on GitHub
3. License: LGPL-3.0
4. README