Java will never become a player in CLI tooling until build packaging becomes first class. Go, Rust, and other languages are so common because their build tooling is dead simple. You can easily get a single file distributable in a single command. go build, cargo build, dotnet publish —-self-contained.
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.
I worked at a couple of startups that were mostly Java based and had several CLI tools. The focus was building "fat jars" then running them with "java -jar ...", or running scripts that did that. The Java VM was a system dependency and getting it baked into the binary just wasn't a practical concern.
I work at a startup that ships a Java cli to our clients. It is a giant pain in the butt. There are constant support requests from users that are using the wrong version of Java, too old or too new. Sometimes they have to wait weeks for authorization to even install the Java runtime. IT departments are extremely strict about installing Java.
Yeah it’s funny how “Java runs everywhere” was a huge selling point of the JVM. But now it’s not even included in macOS by default, so if you want somebody to use you Java/clojure CLI they have to install Java. And that will raise eyebrows and make people think “what is this, 2010??”
You're asking about a fundamentally different thing.
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.
I'm not asking about a fundamentally different thing. The success of other languages isn't because they produce installers. Have you tried native image for a non-trivial application? I've been using it since it came out. It is not trivial to use, the compile times are extremely long, and the resources it requires are sometimes more than a developers machine can provide.
Non-trivial, doesn’t work with standard build tooling, and unless something has changed it produces installers that extract into several different files. You don’t just get a standalone statically linked binary that you can hand off.
Java startup time shouldn't really be an issue with a terminal program. I have written some pretty complex Java and Rust and C++ terminal programs, they are basically indistinguishable on run time. The reason Java starts up slow for most people is that they are running webapps with Spring and 50 dependencies and loading Tomcat, not because they are just booting a JVM and running through some functions.
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
+1 on the AOT compilation. I was surprised there is still a noticeable difference between Graal and a "standard" JVM even if you have eliminated all the other cruft. Both are practically usable, no question, but the latter really felt "instant".
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".
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.
As a practical example for a Java-based CLI tool in the wild, here's kcctl, a command line client for Kafka Connect: https://github.com/kcctl/kcctl/. It's a native binary (via GraalVM), starting up in a few ms, so that it actually be invoked during tab completions and do a round-trip to the Kafka Connect REST API without any noticeable delay whatsoever.
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.
The article makes no compelling points to me as an avid user of these applications.
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
Babashka has been available and has had a growing following since 2019. I have many babashka shebang deployed scripts with fast startup. While I would never desire to use Java syntax, AOT capable JVM based Clojure libraries are available and can be loaded dynamically. Built via graal. https://babashka.org
babashka comes with some excellent namespaces. Highlights include babashka.fs -- a functional and effective wrapper around Java file system classes, and babashka.process -- useful functions for interacting with shell processes, i/o and pipelines. I find babashka packaging to be minimal and much more convenient than python for scripting. No massive virtual environments, just a smaller than 70mb binary needs to be available on my machine. Borkdude FTW.
I've been a Java developer for twenty years. I've used it for everything front front end to distributed systems. I've built gradle plug-ins and clips with JAVA. I have every shortcut in intellij memorized.
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
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.
Same here. Was using Java in the alpha/beta/gamma days. Have built a lot with it. Would not use it for command line tooling by default, only if it happened to be the simplest option (like maybe a library or something does nearly everything needed).
Maybe some of the old beliefs regarding startup time etc are no longer valid. Maybe the programming model isn’t as verbose as it used to be. But I don’t want to distribute a 200MB+ binary. I have colleagues who tell me that c# scripting is so awesome. One only needs .NET installed or use AOT or whatever. Sorry but Go and Rust and good forgive a python script is smaller and mostly easier to read and write then most stuff I seen other languages shoehorning into. I have nothing against Java but it isn’t the right hammer for this problem. At least for me. And I wish people wouldn’t constantly strive for the single language for every problem mindset. Yes in a Java shop it might make more sense to write cli tools and scripts also in Java. But that doesn’t mean it is the most effective toolchain in the long run.
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.
My biggest complaint about Java development is the state of LSP/DAP support. I’ve tried writing Java in VS Code, and the support is still very incomplete. There are two features I want the most: (1) automatically downloading source code for dependencies, and (2) pausing all threads when a breakpoint is hit (https://github.com/microsoft/vscode-java-debug/issues/722
).
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?
Agree, Java also had straight single file execution forever now. Java foo.java. I use it instead of scripts all the time. Solid language with a lot of flexibility, Oracle has done a good job in last few years. Newer Java frameworks are fairly easy and light to use. We have natively image Lambda functions in production. Work well.
Languages lose users when the tooling becomes too heavy.
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.
I concur with Nick, and the last time I programmed Java professionally was late 2024, with all of the latest and greatest frameworks (obviously not my choice) and tooling (which, to be fair to the Java ecosystem, is second to none).
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.
I'm not sure I'd go so far as to claim it was definitely written by AI (after all, LLMs tend to write the way they do because it reflects their training material), but it does have a large number of suspicious constructions that suggest it could have been:
- "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.
Well, the year is 2003 and I am on a hot dungeon with bad Air Conditioning, figuring out the correct spells for a black magic ant build. A few years later I am writing tons of XML, first for vanilla J2EE, then for spring. We complained, we wondered, nobody cared until one day we decided "fuck that shit, I don't care if ruby is slow as molasses, I just want the pain to go away!"
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.
I've been writing Java utils for the terminal since forever. Mostly because I was extremely familiar with Java. It's never been really slow unless you were loading shitload of classes, like apps that package the entire kitchen sink do or as Clojure does for example. For Clojure now there's Babashka: super quick.
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.
There are approximately no use cases that would get me to run a CLI written in Java on my machine, especially if it required having a JVM installed. There's just no reason for it.
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.
Assuming JVM installation is not required (to which I agree, it shouldn't be), why would you care which language a CLI tool is written in? I mean, do you even know whether a given binary is implemented in Go, Rust, etc.? I don't see how it makes any meaningful difference from a user perspective.
> Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.
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.
Yes - Go is both a simpler language than Java which does not lend itself to (nor does the ecosystem tolerate) the kind of architectural malpractice that enterprise Java typically becomes.
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.
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).
[1] https://www.jbang.dev/
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".
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!
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 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
Try building a GraalVM native image. Minutes gone.
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
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.
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.
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.
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?
https://www.jbang.dev/
single binary, no complex deps, ftw
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.
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.
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.
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?
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.