I'm not convinced that requiring users to already have JBang installed is the best adoption strategy. But a native package that pulls in JBang if needed and drops a shim launcher/desktop shortcut seems like a natural approach and maybe a fun project.
On the TUI side, java could really use something as approachable and pretty as go's Charmbracelet [2]. Once developers regularly see compelling java TUIs in the wild, it'll change their perception.
The tooling is here, or at least really close. At this point, it's mostly outdated opinions holding java back in the terminal.
[0] https://martiansoftware.com/nailgun
Edit: Heh... https://rattlin.blog/bbgum.html
Java on the other hand makes it impossible to get a single distributable. There is no way to get your jar + the vm into a binary. You could use graal native image, but build times are super slow, use too many resources, and it’s non-trivial to get working.
Build tooling in the Java ecosystem just isn’t good enough.
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.
The JVM installs cleanly and is self contained, but any artifacts, by default, are not shared system wide as this _always_ have been seen as a security risk. The hot term for it today is "supply chain attack".
Instead, most Java programs tow their dependencies, giving it a bloated feel because its all just there, present in front of you, stored and running as your own user.
It does all of this work for you and its a standard tool that dumps out a platform specific application bundle.
The only people living in 2010 are the ones that choose to live there with incredibly outdated takes on things they dont understand.
An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around.
If you want a fully statically linked binary you're diving into graalvm and native-image: https://www.graalvm.org/latest/reference-manual/native-image.... This will give you what you want which is basically something you can wget and chmod +x.
No more FreeBSD, Solaris, open Solaris (illumos smartos etc).
They've kept it alive, allowed it to grow, and innovate, even let Green threads back in.
I'm not planning on going back to Java, but that's no longer because Oracle.
Heh, I find this very amusing and ironic, seeing how Write Once Run Anywhere was a stated goal with Java, that failed miserably.
Understandably so, given that some Java runtimes (most notably, Oracle's) require a paid license for commercial use. Having users installing that can get the company in hot water.
Or do what the rest of the world does, use Eclipse Adoptium (the best JDK in my opinion) or the one from OpenJDK, Microsoft, etc.
You and the parent raising the specter of Oracle's Java licensing isn't applicable any more. It isn't 2009.
Type the following prompt into any AI and feel free to argue your point with the AI: "what does jbang solve?"
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 with cross-platform packaging.
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; after the first run, subsequent launches are quick.
[2]: https://github.com/kirbylink/warp
[3]: https://repo.autonoma.ca/?action=repo&repo=keenwrite.git&vie...
GraalVM native image allows doing exactly that. Should be as easy as adding a single gradle plugin
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.)
https://github.com/WilliamAGH/tui4j
It combines a port of BubbleTea from Go, and Textual and other inspired rewrites of other functionality.
It’s a fork of someone’s earlier work that I sought to expand/stabilize.
I built a beautifully simple LLM chat interface with full dialog windows, animations, and full support for keyboard and mouse interactivity parity, showing what this Java library is capable of.
Example chat app: https://github.com/WilliamAGH/brief
Would love to see others build similar things with it!
I wasn’t expecting the main topic of what I’ve been building to appear on the cover of hacker news today, so I was caught a bit unprepared, but they were definitely on the todo list next!
Python has many similar properties, but at least there I can understand that Python is a 'pretty' language to write things in. Java has never been something that I have ever wanted to choose, and far, far less so when there's a big hill to climb like this.
I guess I fundamentally disagree with all the statements in the article like "This needs to change". I don't think it does. I would much rather than people wrote CLIs in Go or Rust than Java, 100% of the time the latter has been more painful for me to consume.
Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.
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.
Getting AoT compiled Java programs has been a life saver. Running java -jar main.java -foo -bar is very annoying and not friendly. It needs to be packaged so you can just run tool -foo -bar
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".
Even with all this it takes me substantially less time to get go, python, or ts working as a cli. Java cli is a solution looking for a problem
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.
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.
Installation is via brew, so same experience as for all the other CLI tools you're using. The binary size is on the higher end (52 MB), but I don't think this makes any relevant difference for practical purposes. Build times with GraalVM are still not ideal (though getting better). Cross compilation is another sore point, I'm managing it via platform-specific GitHub Action runners. From a user perspective, non of this matters, I'd bet most users don't know that kcctl is written in Java.
I’m confused by your disregard of C# AOT. It produces binaries as small as go or rust. 1.1 MB for hello world on linux.
> time dotnet publish
Restore complete (0.4s)
dn-hw net10.0 linux-x64 succeeded (2.4s) → bin/Release/net10.0/linux-x64/publish/
Build succeeded in 3.1s
real 0m3.571s
user 0m2.784s
sys 0m0.673s
> time go build main.go
real 0m3.309s
user 0m8.864s
sys 0m1.741s
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.
$ tim "awk '{}'</n" 'tcc -run /tmp/true.c' 'perl</n' 'py2</n' 'py3</n' 'java -jar helloworld.jar>/n'
97.5 +- 1.5 μs (AlreadySubtracted)static dash Overhead
94.9 +- 3.2 μs awk '{}'</n
376.7 +- 4.6 μs tcc -run /tmp/true.c
525.3 +- 2.7 μs perl</n
3627.7 +- 6.0 μs py2</n
6803 +- 11 μs py3</n
42809 +- 71 μs java -jar helloworld.jar>/n
[1]: https://github.com/jarirajari/helloworld [2]: https://github.com/c-blake/bu/blob/main/doc/tim.md
I would rather shove ice picks covered in lemon juice than provide Java or Ellison anymore room in the digital ecosystem. And I’m not talking politics here wrt Ellison, just awful
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.
Try building a GraalVM native image. Minutes gone.
I’m not surprised this was not obvious to the LLM that “cleaned up my notes” for the “author”.
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
java HelloWorld.java
time java HelloWorld.java
Hello, World!
real 0m0.278s
user 0m0.613s
sys 0m0.066s #!/usr/bin/env java --source 25
void main() {
IO.println("Hello, World!");
}
I often combine these approaches with https://get-coursier.io/ when I need to fetch third-party dependencies.
$ 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 can’t find any editor or IDE that comes close to IntelliJ. If we want Java in the terminal, we may also need to think how to write Java in the terminal or are they orthogonal?
But I don’t get the argument that this is somehow desirable. Just because it’s possible to smash a square peg into a round hole doesn’t make it a good idea.
No show —> not easy enough —> too lazy to look it up, already got python/go/ruby quick cli methods. LLM generated even easier.
This is what writing a CLI application in Go looks like: you download Go and immediately have all the tools needed to manage dependencies, write applications, and compile them into lightweight, distributable binaries with a simple command.
Now, let’s consider how this process looks in Java. First, you need to download A(!) JDK – and there are multiple ones. Many newcomers struggle with the variety of JDKs, but let's move past that. The JDK alone doesn’t handle dependencies; it’s highly likely you’ll end up using either Maven or Gradle, both of which are complex and tiresome, requiring you to deal with either XML (Maven) or Groovy/Kotlin. What seems to be missed is the potential of tools like JBang, which should ideally come out of the box. The Scala people addressed this effectively with scala-cli which is now the default Scala runner. Anyway, you’re still far from finished. You've just figured out how to write applications; now you need to figure out how to distribute them. This involves understanding jpackage – if you want an application smaller than 100MB, you’ll likely need to use jlink beforehand. And, heaven forbid, your application uses Java 9+ modules, as then you'll be wrestling with the complexities of modularity itself. If you’ve managed to navigate all of this, you’ll end up with an application that includes a bundled JRE. A compressed, modularized “hello world” application can easily size at least 30MB and take several hundred milliseconds to start.
Then there's Graal Native, which allows you to compile your applications ahead of time into natively executable binaries. However, compiling Java applications ahead of time is complicated by runtime class initialization, reflection etc. which is why the Graal compiler needs significant configuration beforehand. There are tracing agents to help you compile such configurations, but even with them, it’s incredibly tiresome and not always reliable. Furthermore, the produced binaries tend to be large and don't play well with upx.
I think the JDK developers could learn from Scala CLI, which is now the default Scala runner. I'm convinced it would really help Java if it came with something like that out of the box.
So no. No, please god no, no Java in the terminal.
More ranting here: https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...
Kotlin sure is less awful, for example. But the JVM, as I describe, was always a failed experiment.
You have to learn ( and maintain knowledge of ) build tooling, unit test frameworks, tools for front end / back end development, distribution and packaging systems, directory structures to accommodate all those, etc. ad nauseum.
Then something new and shiny comes out, with much smaller tooling. The lure of easy software construction seduces the user.
It never ends.
And GraalVM compiled Java is more than speedy.
Back in, say, 2005, two decades ago, on computers from back then, sure, the java startup time from the CLI were noticeable. But on today's computers?
Nowadays when it comes to terminal apps I wrote both Clojure (Babashka), Bash and Java (recently I needed something from a .jar and had no convenient Clojure wrapper and didn't want to bother, so I just wrote my CLI app in Java).
Maybe, maybe, maybe that I do feel the startup time when I run my CLI Java app on Raspberry Pis. Raspberry Pi 2 and 3s that is (for I don't have any newer).
Startup times aren't an issue. But there may be other reasons to prefer other languages to write CLI apps.
The rounding error there is Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.
That said, if the Java community wanted to port reasonable tooling to their platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped.
> 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?
As for why Pkl was in Java: it was originally built to configure apps written in Java, and heavily uses Truffle. Pkl is a name chosen for open sourcing, it had a different name internally to Apple before that which made the choices a little more obvious.
There's a poster upthread who seems to have done what you're describing: https://github.com/WilliamAGH/tui4j
But also when running on the JVM, things have improved dramatically over the last few years, e.g. due to things such as AOT class loading and linking. For instance, a single node Kafka broker starts in ~300 ms.
graalvm is literally 500x more overhead than a statically linked dash script.
Maybe not an issue for terminal UIs, but the article mentions both TUIs and CLI tools. A lot of people use CLI tools with a shell. As soon as you do `for file in *.c; do tool "$file"; done` (as a simple example), pure overhead on the order of even 10s of ms becomes noticeable. This is not theoretical. I recently had this trouble with python3, but I didn't want to rewrite all my f-strings into python2. So, it does arise in practice. (At least in the practice of some.)
A hasty generalization with a little confirmation bias, perhaps?
$ time keenwrite.bin --version
KeenWrite version 3.6.5
Copyright 2016-2025 White Magic Software, Ltd.
user 0m0.329s
> It's worth noting this is a common perception about Java, and there's some historical truth to it (especially with Swing desktop applications from the 2000s). However, the absolute statement "no Java app... ever" is the fallacy - it's an overgeneralization from limited personal experience to a universal claim.
Graal would be needed and then your binaries would be huge.
No thanks. Go is much simpler. Rust is much smaller. Java can go die in the office storage closet.
C is simpler, Python is simpler, but Go?
https://leapcell.io/blog/the-origins-and-design-philosophy-o...
Go was originally designed to make life easier for googlers and make software engineering easy. In 2025, I can attest to the fact that Go is simple. Go is easy. Whether you can accomplish what you want in Go is another story. However, Go has a very basic structure and easy flow. Complexity comes from not understanding the go philosophy.
Forgive me if in 2026 I get triggered at the mere mention of the phrase "java build".
Lots of us had long relationships with Java, relationships marked by toxicity and abuse. We moved on. Now Java says it is changed, it has matured. Well, it could be true, probably it is even true, but on the other hand, now your toxic ex found out his father, and his name is Larry Ellison.
No thank you.
I am not in the ecosystem anymore but it did a lot of things right.
The experience after having spent over a decade primarily doing Go, Rust and Erlang (with a smattering of TypeScript, C#, Python, Swift, C, C++ etc) was the final push over the line to leave that employer.
- "Look, I’m going to say something that might sound crazy...."
- But here’s the thing: there’s nothing stopping us...
- Emdashes. I don't believe that alone they are a tell for AI any more than they are a tell for the cultured, but in combination with other things, maybe.
- The question/answer style.
- The "It's not X, It's Y" construction.
This is all in the first sections.