Every Java developer knows this workflow.
You find a library you want to try.
Then you have to:
- create a project
- write a pom.xml
- wait for your IDE to index dependencies
- write a tiny test
- throw the whole thing away later
All of that, just to call two methods and throw the project away.
I built JetShell — an interactive Java shell for exploring libraries instantly. Type a single /resolve command, and JetShell pulls the artifact along with all its transitive dependencies onto the classpath. No pom.xml. No dependency hell. Just import the class and start calling methods.
GitHub: https://github.com/kawasima/jetshell
What JetShell is really for
JetShell is not just “JShell, but smaller.”
Its real job is to remove the friction of library exploration.
With JetShell, you can:
- resolve a Maven artifact and all its transitive dependencies into your session with a single
/resolvecommand - use Tab completion for group IDs, artifact IDs, and versions
- inspect the full dependency tree with
/deps - read Javadoc from the shell with
/doc - open source code with
/source
The workflow becomes:
find library → /resolve → import class → try API → read docs/source
No temporary project. No IDE indexing pause. No context switch.
A quick example
Here is the kind of thing I wanted to make easy:
-> /resolve org.apache.commons:commons-lang3:3.14.0
| Path .../commons-lang3-3.14.0.jar added to classpath
-> import org.apache.commons.lang3.StringUtils;
-> StringUtils.capitalize("hello world")
| Expression value is: "Hello world"
commons-lang3 has no transitive dependencies, so the benefit is subtle here. Try something heavier:
-> /resolve org.apache.httpcomponents.client5:httpclient5:5.4.3
| Path .../httpclient5-5.4.3.jar added to classpath
| Path .../httpcore5-5.3.3.jar added to classpath
| Path .../httpcore5-h2-5.3.3.jar added to classpath
| Path .../slf4j-api-1.7.36.jar added to classpath
-> import org.apache.hc.client5.http.classic.methods.HttpGet;
-> var req = new HttpGet("https://example.com");
One command resolved httpclient5 and its four transitive dependencies. No need to hunt down each JAR or write a dependency block — JetShell walks the POM graph for you.
Documentation is one keystroke away:
-> /doc StringUtils.isEmpty(
| boolean StringUtils.isEmpty(CharSequence cs)
| Checks if a CharSequence is empty ("") or null. ...
So is the source:
-> /source org.apache.commons.lang3.StringUtils
| 1: /*
| 2: * Licensed to the Apache Software Foundation (ASF) ...
...
JetShell downloads source JARs automatically when needed for third-party libraries.
Why I built it
Java has excellent libraries.
What it often lacks is a low-friction way to poke at them.
In practice, exploring an unfamiliar library usually means paying the full “project setup tax” before you even know whether the API is what you want. That tax includes not just the pom.xml boilerplate, but manually figuring out which transitive dependencies you need — or waiting for Maven/Gradle to download the internet while your IDE re-indexes.
JetShell exists to make that first contact cheap: one /resolve command replaces the entire setup ceremony.
The part I like most: artifact completion
One feature that changes the feel of the tool is Tab completion for artifact coordinates.
-> /resolve org.apache.commons:
JetShell suggests matching artifacts. Then:
-> /resolve org.apache.commons:commons-lang3:
It suggests versions.
It searches both your local ~/.m2/repository and Maven Central. Local results appear immediately; Maven Central results follow after a brief search. Dependency discovery becomes interactive instead of bureaucratic.
Installation
JetShell requires Java 21+. The release is distributed as a self-contained executable JAR:
curl -OL https://github.com/kawasima/jetshell/releases/download/v1.0.1/jetshell
chmod +x jetshell
./jetshell
You can also build from source with Maven.
What JetShell is good for
JetShell is especially useful for:
- exploring unfamiliar Maven libraries — with all transitive dependencies resolved automatically
- trying API calls before committing a dependency to a real project
- reading Javadoc and source without leaving the shell
- checking dependency trees quickly with
/deps - learning Java libraries by interacting with them instead of just reading docs
The REPL is just the medium. The point is cutting the gap between “I wonder if this library does X” and actually knowing.
If this sounds useful, try it
Repository: https://github.com/kawasima/jetshell
If you have ever created a temporary Maven project just to test one class, JetShell was built for exactly that frustration.
