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
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.
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.
I agree the build might take a bit extra but its for sure not much for smaller clis. Making jbang native added 1-2 minutes and its all done in github action runners so in practice I don't see this as a problem as it does not affect the end user.
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
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
I felt and did the same as you - until I made jbang as I was tired of seeing kotlin script being included to just write java...
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.
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.
jar + vm into single binary feels like a solvable problem.
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"
I’m not convinced that “single binary” really matters in practice. 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 just the app and rely on a smart launcher/runtime manager (npx, bunx, uvx, jbang), and assume your technical audience can install that first
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), isn't a single binary, and that still 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.
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
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.
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 guess I should never use Go because I was stuck not having a working debugger, complain about Python because it is single threaded, or javascript because its a typeless mess, or C# for only running on Windows?
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.
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.
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.
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.
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?
hmm - automatic download of source code just works for me in vscode...?
"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 :)
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.
65 comments
[ 2.8 ms ] story [ 62.4 ms ] threadhttps://www.jbang.dev/
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.
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
No thank you.
Try building a GraalVM native image. Minutes gone.
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
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
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.
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 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"
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), and assume your technical audience can install that first
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), isn't a single binary, and that still 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.
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 ;)
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.
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'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.
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.
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.
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!
Will definitely check it out.
...where is the jar for brief? :)
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?
"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 :)
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.
single binary, no complex deps, ftw