Stop Creating Throwaway Maven Projects Just to Try a Java Library

kawasima — Thu, 12 Mar 2026 09:17:39 +0000

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 /resolve command
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:<Tab>

JetShell suggests matching artifacts. Then:

-> /resolve org.apache.commons:commons-lang3:<Tab>

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.

DEV Community: kawasima