2026: the Year of Java in the Terminal?

C is simpler, Python is simpler, but Go?

I was amazed when I tried Graal the first time, but also had to think that this is probably what C/C++ or Rust devs just see as "normal".

I am not in the ecosystem anymore but it did a lot of things right.

$ python foobar

Nope.

$ gcc foobar

Nope.

$ g++ foobar

Aw,come on.

$ go foobar

Damnit.

$ rust foobar

$ c# foobar

WTF did they use for this program??!!

$ node foobar

This is such a waste of time.

$ java foobar

Bullshit!

$ ocaml foobar

Come on, there arent't that many more programming languages!

$ tcl foobar

Finally!

I’m confused by your disregard of C# AOT. It produces binaries as small as go or rust.

Our Go CLI tools are like 100MB+ and often we bundle them in containers that are in the GB+ territory. Nobody cares or at least has cared enough to tell us to minimize stuff.

The real threat has been and continues to be ... Google. They pulled a Microsoft move (that they got busted for) and Google got away with it. Google killed Eclipse as the IDE for Android development and threw that business over to their Russian buddies at JetBrains.

Google is the threat to Java, not Oracle.

Then when I had ability to write java scripts with dependencies, we added auto download of JDK and then made it so could run any jar (not just scripts) and I suddenly now have full debug support for anything I do + I can install and run this on any docker container or laptop - even my parents or a library computer running some ancient windows. Try that with npm and python :)

All I'm saying - I hear you and I grok why. What I'm saying that for at least close to 5 years at least last 3.5 years there been a way to use the jvm as easy and more reliable than python/nodescript/typescript....run cli's, swing/jfx, backend apps etc.

And in 2026 I want to make java TUI's a reality.

That's a great way of putting it. I'm a Java developer also; I'm most comfortable with Java and, dare I say, I like Java. But Java would be far down the list of tools I'd use to make a CL program.

All of that to say, I’m also familiar with the problem.

For the past 3-4 years I’ve reached more for Go to my new CLI projects. Small differences in installed Java versions across clusters can be a problem, but for me the biggest issue is dealing with JVM arguments. I writing code for working with genomics data files. Sometimes these are large, and sometimes they are small. And I hate having to tell both my job scheduler (SLURM mainly these days) and the JVM how much memory to use.

This isn’t a problem in Go. So, that’s the language I gravitate to these days.

Python packaging has always been painful and it’s a popular option for CLI regardless.

I don’t think there only rational explanations, technology choices are a lot about culture and dogmas too.

[1] https://www.jbang.dev/

Heh, I find this very amusing and ironic, seeing how Write Once Run Anywhere was a stated goal with Java, that failed miserably.

I haven't really had the burning need for app+jvm since I used graalvm and made jbang and its now trivial to run app + shared jvm for me - but I can see the utility for it.

Noted down the various pointers and existing attempt to explore in 2026 !

About build and publishing - this I feel is also solvable.

Especially if we stop trying to solve it for all possible mutations of gradle/maven builds and just make it work for jars...this is where jbang/jreleaser really simplifies more than I think many realize.

So in 2026 I'll definitely try get more recipes published on this and also see if we can make something like `jbang publish` "Just Work"

What actually matters is how easy it is to install, run, and update an application, and that depends entirely on the target user.

For end-user apps, this is basically solved: use jpackage to ship an installable app with a bundled, trimmed JRE. Better yet, distribute via the OS app store so updates are handled for you (on Linux, Flatpak is probably the right answer today).

For CLI tools, you’re already assuming a more technical audience. At that point you have two real options: - ship everything bundled (Go/Rust static binaries, pyinstaller, jpackage) - ship just the app and rely on a smart launcher/runtime manager (npx, bunx, uvx, jbang)

The real question isn’t "is it a single binary?", it’s "how do users install, run, and update it?". In practice, that’s already been solved by developer package managers like brew and scoop. All the Go and Rust CLIs on my machine are installed via brew, not manually downloaded from GitHub releases.

You also want CLIs on PATH or inside a dev environment (mise, direnv, etc.), so whether that executable is a true single binary or a symlink to a bundle is mostly irrelevant.

So the trade-off becomes, do you support `brew install foo-java-tool` with a bundled JRE, or do you ask users to `brew install jbang` and then `jbang install foo-tool`? Either way, the end result is the same, you run `foo-tool`.

Note, Claude Code for instance supports both options (curl | bash, brew cask, and npm -i) and that hasn't stopped it from being the most popular CLI tool released this/last year.

There’s definitely room for improvement in Java’s packaging story, I just think the focus shouldn’t be on "single binary" as the primary goal.

It's not dynamic linking, despite excellent support for very late binding in historic Java versions. (Newer versions require specific launcher configurations to use certain platform features, which breaks late loading of classes that use those features.)

GraalVM native image allows doing exactly that. Should be as easy as adding a single gradle plugin

My text editor, KeenWrite[1], offered binaries for Linux, macOS, and Windows. The Windows binary was axed due code signing costs and requiring third-party builds, rather than any technical issues.

One way is to create self-extracting executable binaries using a tool such as warp[2]. I've built an installer script[3] (install.sh) to create platform-specific launchers. Running `time keenwrite.bin --version` on Linux shows 0.327s.

[1]: https://keenwrite.com

[2]: https://github.com/kirbylink/warp

[3]: https://repo.autonoma.ca/?action=repo&repo=keenwrite.git&vie...

...Locator

When I started showing that its just fine to name a class, `myapp` and run it with jbang myapp.java people got all weirded out.

No technical constraints in java; just bad old habits limiting peoples mindset ;)

> Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.

Why do you think is this?

There's a poster upthread who seems to have done what you're describing: https://github.com/WilliamAGH/tui4j

I'm happy to say I think all have their upsides and downsides and all of them evolve and should all try not to be stuck in old perceptions. And yes Java is held back by those perceptions and I'm saying lets not get bogged down by perceptions like yours from trying to evolve and improve.

Will definitely check it out.

...where is the jar for brief? :)

"java.maven.downloadSources": true in config if you don't just use maven's automatic download for it.

pause all threads does look like a valid omission. Feels like something someone should go contribute - any takers?

on your question - I do actually miss having a good an easy java in terminal editing experience. I use a nvim starter pack to do it BUT here there is no good jbang enabled LSP to make it truly smooth ...also on my 2026 wish list :)

jshell is amazing, I don't think enough people know about it!

The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by convention. I would love a rich java ecosystem of TUI/CLI libraries to reuse all of my existing business logic and company libraries. The lack of extremely streamlined wrappers is the only barrier. In my work environment, this would be a great addition.