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 think the python counterexample speaks a lot. A lot of languages "hide" their footprint in /usr/local or in a venv somewhere; out of sight, out of mind.
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.
I know Python has been big in the space for longer than uv's existence, but uv (https://docs.astral.sh/uv/) has made Python packaging dead simple to me
I don't think uv makes distribution simple? Unless I've missed something, it doesn't do anything out of the box to help you produce a standalone artifact - it builds wheels but those are only useful for a user that already has python and pip, and don't do anything to deal with Python version drift etc.
uv can install a version of python of your choosing in addition to pulling the specific versions of libraries specified in your lockfile. it's extremely dummy-resistant.
Right, but that means the end user has to have (or install) uv, and then you ship them all your code, and then they can use uv to run that. That's a development workflow - and exactly what I meant when I said that uv didn't solve distribution in the way a language like Go or Rust does by producing a single binary.
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??”
Bundling the JRE in the bundle typically results in something that is not redistributable with the default OpenJDK license: The Java ecosystem is heavily tilted towards the Apache license, but Hotspot is licensed under the GPL v2 only (no classpath exception). The Apache license and older GPL versions (before 3) are generally assumed to be incompatible.
Every modern openjdk build is licensed as GPLv2 + classpath exception. That exception includes hotspot, since it's part of the jvm. That exemption allows shipping the JVM with your app or linking to it. Otherwise a bunch of enterprise software couldn't exist.
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; I was the first adopter of native-image for Quarkus on Windows. I even wrote the documentation for it at the time. 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.
Or use a graal to build a native-image and ship that around.
But that's not what people want. They want an .exe or a .app, or .rpm, or whatever. That's a container for holding that .jar and it is platform specific and there is no workaround to that problem.
java took a hit on this move by Java and Oracle...and the way they still provide a java executable that tells you to download from somewhere else is really annoying - but you do realize Apple removed python from Mac in 2024 and never distributed python3, right?
So will we see python stop being used?
No, because instead of sitting in corner and mope about it the ecosystem just kept working and filling in the gaps.
Java ecosystems done lot of that - but general public keep having the old changes stuck in their mind.
Java SHOULD never become a player in anything more until Oracle stops being such a threat. Oracle just wants to be a parasite on companies that actually build.
I gave up on Java when Oracle took over, because I thought that it was such a horrific move, but, to their credit, they haven't ruined it for everyone (yet)
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.
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.
I could see how that could be annoying. My experience was with internal apps whee we managed all the infrastructure. Some IT departments are often extremely strict about installing anything. Some won't even let you access a web site without it being proxied through something like ZScaler.
> IT departments are extremely strict about installing Java.
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.
The point is, there are legal complexities which make it unsafe for an employee to go out on their own and download a JRE - sure, they might download Adoptium and be fine, but they also might download one of the ones which requires a commercial license. An IT department isn't going to be comfortable with that risk.
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.
> There is no way to get your jar + the vm into a binary.
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.
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.
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"
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.)
I spent a long time caring about JVM startup time and CLI suitability (and wrote nailgun [0] over 20 years ago and jsap [1] shortly after specifically because of it), so it's pretty wild to see how far things have come. Modern JVM startup speed and GraalVM native-image have eliminated most of the old excuses. jlink+jpackage help a lot with distribution, and JBang takes it to another level. I've used JBang before but still learned some new tricks from this post. Honestly, it feels like what JNLP/WebStart should have evolved into.
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.
Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go.
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.
Its not necessarily fair to use past experience with programming languages that have been seeing major updates year over year. Java as a command line environment has been pretty painless for me, particularly Saxon. Just need to alias the command to include a path to the jre binary.
Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.
Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years.
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.
Right, as I said I also think Python has similar issues with startup time.
I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.
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.
I had no idea what brief was until I read the env var api key docs in the subdirectory. I think you should not lead with "it's a tui4j app!" and "it's terminal chat!". It's a terminal OpenAI ChatGPT interface. Screenshot wouldn't hurt either, given it's an advertisement for the presentation library.
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!
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".
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’m about the same. I’ve had one Java project going for over 10 years. It’s a collection of utilities that I use for work everyday that has grown substantially over the years. It is a CLI program that runs in my Mac, Linux servers and Linux HPC clusters. It is built with a fat-JAR concatenated to a shell stub in front that makes it effectively a single-file install. I also wrote a complete library for defining CLI programs. It is pretty easy to use, but it relies on reflection and annotations, so Graal has been difficult to get working (or was the last time I tried).
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.
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.
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.
The problem is that packaged Java CLI utilities will also take 20MB+. The minimum size is still much too big for that class of programs. Also, AoT compilation was an absolute pain last I tried it, it's a big change for an ecosystem that was always designed as modular and dynamic. I love Java, but for CLI apps I'll take Rust whenever possible.
> 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
Obviously I don't know how that translates to a non-trivial application.
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 SSD would like a word with you :)
I don’t say every app needs to be in the kb range. But it is strange that applications for the terminal eat up multiple megabytes. I see the reason when this is statically linked though and one needs stuff like open ssl etc.
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.
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 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.
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
Someone else on the page commented about Oracle. Why are there still people hung up on Oracle or Ellison when if anything, they've helped Java to thrive more.
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.
I'm a progressive -- just as I am not dumping my climate friendlier Tesla at a loss because Musk is a Nazi buffoon, there is no way I am walking away from my GraalVM compiled babashka binary because another billionaire turd kicked Stephen Colbert off the tonight show. I can mourn and label both as petulant and stupid, without having to bleed my back like Saint Thomas More.
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.
It is not only the language but also the mindset and culture. When in Java System.exit() and even System.println() are treated as smells and I have to actively push to get exceptions from the company wide style I'll just write Rust and be done.
Haven't checked graalvm in a long time. So, I got graalvm-jdk-25.0.1+8.1 for x86_64. It's a lot faster than Julia, and maybe 43ms is not slow in "human terms", but it's still pretty slow compared to some other competition. This was for a helloworld.jar [1]. On my laptop (i7-1370P, p-cores) using tim[2]:
That is just a normal JVM with optional Graal components if enabled, but not being used. The default memory allocation is based on a percentage of available memory and uncommitted (meaning its available for other programs). When people mention Graal they mean an AOT compiled executable that can be run without a JVM installed. Sometimes they may refer to Graal JIT as a replacement for C1/C2 available also in VM mode. You are using a plain HotSpot VM in server mode, as the optimized client mode was removed when desktop use-cases were deprioritized (e.g. JWS discontinued).
You are correct and I apologize for the misimpression.
`native-image -jar helloworld.jar helloworld` did take a whopping 17 seconds to compile, what might be the smallest possible project. That does makes me worry for iterations trying to get better perf in a context where startup overhead matters, BUT the executable it produced did run much faster - only about 1.8x slower than `tcc -run`:
Perl has 2 more shared libraries for ld.so to link, but is somehow faster. So, there may still be some room for improvement, but anyway, thank you for the correction.
(Also, I included 4 of the faster comparative programs to show additionally that the error bars are vaguely credible. In truth, on time shared OSes, the distributions have heavier tails than Gaussian and so a single +- is inadequate.)
--
EDIT: So, the ld.so/dynamic linking overhead was bothering me. I had to get a musl + zlib build environment going, but I did after a few minutes and then found this result with a fully statically linked binary executable:
398.2 +- 4.2 μs ./helloworld-sta>/n
(I should have noted earlier that /n -> /dev/null is just a convenience symlink I put on all my systems. Also, this is all on Linux 6.18.2 and the same CPU as before.)
Also, only around 4.2 MiB of RSS compared to ~1.8 MiB for dash & awk. So, 2.4x the space and only ~4X the time of static awk & dash. That might sound like criticism, but those are usually the efficiency champs. The binary size is kind of hefty (~2x like the RAM use):
$ size *sta
text data bss dec hex filename
2856644 3486552 3184 6346380 60d68c helloworld-sta
So, I guess, in 2026, Java start-up overhead is pretty acceptable. I hope that these "real numbers" can maybe add some precision to the discussion. Someone saying "mere milliseconds" just does not mean as much to me as 400 +- 4 microseconds, and perhaps there are others like me.
Thanks for the corrected evaluation. Just for your awareness, the HotSpot team is working on offering a spectrum of AOT/JIT options under the Leyden project [1]. Currently one has to choose between either a fully open world (JIT) or closed world (AOT) evaluation. The mixed world allows for a tunable knob, e.g. pre-warmup by AOT while retaining dynamic class loading and fast compile times for the application. This will soften the hard edges so developers can choose their constraints that best fit their application's deployment/usage model.
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.
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.
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 :)
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.
It makes a difference in size, in how arguments tend to be handled, and so forth.
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.
> 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.
I'm sorry, but this is a big load of crap and that includes some of the comments in here. Java enthusiasts are the absolute world champions of sugarcoating the shortcomings of Java and the JVM in general.
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.
I'm sorry, but this is a big load of crap and that includes some of the comments in here. Java enthusiasts are the absolute world champions of sugarcoating the shortcomings of Java and the JVM in general.
Love you too.
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.
Check - agreed.
Now, let’s consider how this process looks in Java....<rant>
It feels like you missed the last 5 years of improvements..so let me show you how this works in java when using jbang:
You download JBang, and immediately have all the tools needed to manage dependencies, write applications, and run other Java applications with a simple command.
Since you probably don't believe me I'll show you some of it here:
`jbang init -t cli hello.java` - you get a hello.java that declare picocli dependencies and you can run it as `./hello.java`, you even do `jbang app install hello.java` and just use `hello`. You can do this with your own scripts, preexisting jars or existing Maven artifacts.
- yes it will also have downloaded right JDK for you; you can easily swith to other versions, either `jbang --java 25 hello.java` or even `jbang --java 8 hello.java` if you really wanna go back in time :) The java version can be baked into your script or jar so it is NOT a requirement for your end user to be aware.
`jbang edit hello.java` will offer to install vscodium based IDE that gives you an IDE environment to write java in.
`jbang export fatjar hello.java` gives you a runnable fat.jar
`jbang export maven|gradle hello.java` gives it a full blown maven/gradle if you are forced to be Enterprise Compliant :)
You can even run and distribute these sources by just commiting to a github repo and just do `jbang <repourl>` or use jbang catalogs etc. Lots of opportunities.
Reading this and reddit thread I see that the final publish of jars/executables is still too tedious I'm going to try solve that challenge as we have all the pieces (IMO) with jbang/jreleaser and modern JDKs.
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.
don't play well with upx - how so? yes there is the usual upx overhead but "just works" when I tried using it?
about graalvm native - definitely not going to say its perfect nor easy; but Quarkus definitely have a whole ecosystems of java libraries and framework setup that just works when using native builds.
That said - I think we dont need to go to full native for lots of usecases.
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.
Yeah, I couldn't wait for JDK developers to do it so I built jbang to make that available today.
You've largely ignored everything I’ve said. Instead, you proposed workarounds – which is precisely what most people want to avoid. Who distributes applications as fat jars? What is this? 2004? You’re supposed to distribute your application as executables. I’ve brought up numerous complaint regarding jpackage and jlink, and none of them have been addressed by jbang. Furthermore, you accuse me of not having used Java in the last five years, which is frankly ridiculous; I've spent almost two decades developing software on the JVM. Funnily enough, I had to write my own sbt plugins because jlink and jpackage are so painful to use.
Regarding UpX: it simply doesn’t work with Windows binaries generated by Graal – see this issue: https://github.com/oracle/graal/issues/7605. They've been ignoring this for three years instead of fixing it. Meanwhile, it works perfectly with Go binaries or .NET’s AOT compiler. I’m not trying to bash your project, but the reality is that no one with little to no Java experience is going to discover and install jbang. Features like this should be included with Java out of the box.
You've largely ignored everything I’ve said. Instead, you proposed workarounds – which is precisely what most people want to avoid. Who distributes applications as fat jars? What is this? 2004? You’re supposed to distribute your application as executables.
and still npm, python, and other ecosystems don't do that. they effectively ships what corresponds to jars with dependency metadata.
I also did not say fat jars (even though that works fine too).
Why don't java world be ok with utilizing that option like other ecosystems.
I know why they didn't do it in past when something like jbang did not exist - just like javascript didn't do it before npm (and fast node runtime) came around...
I’ve brought up numerous complaint regarding jpackage and jlink, and none of them have been addressed by jbang.
I explicitly wrote: "Reading this and reddit thread I see that the final publish of jars/executables is still too tedious I'm going to try solve that challenge as we have all the pieces (IMO) with jbang/jreleaser and modern JDKs." so I did not claim jbang solves it - I said I could see how it could be better.
What I did show or at least tried to was that your complaint about something like scala-cli and how Go could do all things out of box...jbang exist to bridge that gap.
Furthermore, you accuse me of not having used Java in the last five years, which is frankly ridiculous;
I did not claim that at all. I said you seem to have missed the last years improvements in this space (jbang being a key one enabling majority of the issues you brought forward).
I've spent almost two decades developing software on the JVM. Funnily enough, I had to write my own sbt plugins because jlink and jpackage are so painful to use.
yes, I agree jlink and jpackage is not good enough.
I haven't tried tackle it yet as I used jreleaser most of time to hide that pain - and I agree its not solved yet...but also trying to show that distributing everything as native OS binaries is NOT an absolute requirement and not what other ecosystems does.
Heck, even Go allow for running git repos by compiling it locally before running it... jbang allow similar workflows - on top of plain java.
Regarding UpX: it simply doesn’t work with Windows binaries generated by Graal – see this issue: https://github.com/oracle/graal/issues/7605. They've been ignoring this for three years instead of fixing it. Meanwhile, it works perfectly with Go binaries or .NET’s AOT compiler.
gotcha - haven't tried it on windows for a while and looks like it did work in GraalVM 21 and just issue on future versions.
I’m not trying to bash your project, but the reality is that no one with little to no Java experience is going to discover and install jbang. Features like this should be included with Java out of the box.
yeah - well neither node, python and others had these to begin with.
Its a very Java'esque mindset to require it in the default toolchain to be considered useful.
I wonder why anyone even still try using maven or gradle or sbt - it does not come with Java itself either :)
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
From Claude:
> 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.
It's a non-issue with GraalVM native binaries. See https://news.ycombinator.com/item?id=46445989 for an example: this CLI tools starts in ms, fast enough you can launch it during tab completions and have it invoke a REST API without any noticeable delay whatsoever.
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.)
I get the argument from this article that it’s possible.
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.
I'm definitely not going try to force it upon those who don't like java - but I'm saying that the Java peg is way more round than most believe so don't just start using another slightly round peg like python, go, javascript etc. because others said its required :)
Honestly, super impressed that that they’ve got the traction they do without it but, I think the takeaway is that Java developers like having everything in the IDE— so I’d imagine agentic in the ide will yield higher returns than switching modalities
There is already a lot of Java in agentic systems and IDE integrations — but that alone won’t break the stereotype.
The real blocker isn’t capability, it’s perception: many people stop before even trying Java in the terminal. All while Python/JS are seeing a surge in terminal tooling, despite similar (or worse) startup cost, dependency sprawl, and multi-GB installs — and the reaction there is often “this is fine, let’s ship and use.”
Until Java is visibly normal in the terminal, agentic features in IDEs won’t change that mental model.
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.
I'm not saying we should phase Java out. But it's pretty clear to me that Java was a bad experiment in almost every aspect, and we should at least not add new use cases for it.
So no. No, please god no, no Java in the terminal.
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.
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.
Legacy doesn't seem to mean what you are implying. I suggest typing the following prompt into any AI and debating it with the AI: "define legacy in terms of programming languages".
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.
> Java will never become a player in CLI tooling until build packaging becomes first class.
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.
I think the python counterexample speaks a lot. A lot of languages "hide" their footprint in /usr/local or in a venv somewhere; out of sight, out of mind.
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.
I know Python has been big in the space for longer than uv's existence, but uv (https://docs.astral.sh/uv/) has made Python packaging dead simple to me
I don't think uv makes distribution simple? Unless I've missed something, it doesn't do anything out of the box to help you produce a standalone artifact - it builds wheels but those are only useful for a user that already has python and pip, and don't do anything to deal with Python version drift etc.
uv can install a version of python of your choosing in addition to pulling the specific versions of libraries specified in your lockfile. it's extremely dummy-resistant.
Right, but that means the end user has to have (or install) uv, and then you ship them all your code, and then they can use uv to run that. That's a development workflow - and exactly what I meant when I said that uv didn't solve distribution in the way a language like Go or Rust does by producing a single binary.
uv does not solve all problems - but it for sure greatly improves chance of python tools working.
jbang is to java, what uv(x) is to python and what npm/npmx is to javascript.
Python packaging isn't really any more difficult than Rust, C# or Go if you use pyinstaller [1]
A single executable is always just one "pyinstaller --onefile --noconsole main.py" away.
[1] https://pyinstaller.org/en/stable/usage.html
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??”
jpackage
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.
Bundling the JRE in the bundle typically results in something that is not redistributable with the default OpenJDK license: The Java ecosystem is heavily tilted towards the Apache license, but Hotspot is licensed under the GPL v2 only (no classpath exception). The Apache license and older GPL versions (before 3) are generally assumed to be incompatible.
Every modern openjdk build is licensed as GPLv2 + classpath exception. That exception includes hotspot, since it's part of the jvm. That exemption allows shipping the JVM with your app or linking to it. Otherwise a bunch of enterprise software couldn't exist.
This is not true.
Even Eclipse and Intellij ship openjdk based runtimes with their distributions and have even stricter GPL limits.
Has jpackage been updated to create things that are not installers and don't extract themselves into several files?
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.
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.
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; I was the first adopter of native-image for Quarkus on Windows. I even wrote the documentation for it at the time. 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.
Every time I've tried to get native-image working with anything more than a basic Swing app it has been absolute hell.
> platform specific
Write once, run everywhere.
java -jar <jar-file>
Or use a graal to build a native-image and ship that around.
But that's not what people want. They want an .exe or a .app, or .rpm, or whatever. That's a container for holding that .jar and it is platform specific and there is no workaround to that problem.
Openjdk also dropped a lot of OS support, it basically just windows, Mac and Linux now. And AIX.
No more FreeBSD, Solaris, open Solaris (illumos smartos etc).
just because Oracle stopped distributing JDK's is not the same as not possible. Anyone can step up to do this.
https://github.com/psumbera/solaris-openjdk seem to work?
I never said it was impossible. I said they dropped support.
ok, but what practical implications does it has?
Pretty sure many other runtimes aren't exactly supported on all platforms by single vendor/projects?
java took a hit on this move by Java and Oracle...and the way they still provide a java executable that tells you to download from somewhere else is really annoying - but you do realize Apple removed python from Mac in 2024 and never distributed python3, right?
So will we see python stop being used?
No, because instead of sitting in corner and mope about it the ecosystem just kept working and filling in the gaps.
Java ecosystems done lot of that - but general public keep having the old changes stuck in their mind.
Lets change that :)
graalvm native binaries?
Java SHOULD never become a player in anything more until Oracle stops being such a threat. Oracle just wants to be a parasite on companies that actually build.
I gave up on Java when Oracle took over, because I thought that it was such a horrific move, but, to their credit, they haven't ruined it for everyone (yet)
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.
They have been better stewards of Java than Sun was IMO. I never would have expected it at the time, but it has turned out alright.
I like that Microsoft has a distribution of OpenJDK. Easy to trust if I'm on a windows system anyway. What's the risk?
https://www.microsoft.com/openjdk
Google is much more of a threat than Oracle.
How so? I've never had an employer or client be threatened with lawsuits from Google.
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.
I could see how that could be annoying. My experience was with internal apps whee we managed all the infrastructure. Some IT departments are often extremely strict about installing anything. Some won't even let you access a web site without it being proxied through something like ZScaler.
Yeah after we got bought our own IT department wouldn't let me use ngrok even though engineering was paying for licensing for it.
> IT departments are extremely strict about installing Java.
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.
Until 2021, now some do require a paid license for commercial use and some Java versions from Oracle can be used for free for commercial use.
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.
The point is, there are legal complexities which make it unsafe for an employee to go out on their own and download a JRE - sure, they might download Adoptium and be fine, but they also might download one of the ones which requires a commercial license. An IT department isn't going to be comfortable with that risk.
> Java on the other hand makes it impossible to get a single distributable.
Heh, I find this very amusing and ironic, seeing how Write Once Run Anywhere was a stated goal with Java, that failed miserably.
It was successful for a while. Java applets were once fairly common. But then Flash largely replaced them, and then Html5 killed them flat.
A very limited "anywhere", but yes.
For that use case, was it active content, was it shipping intermediate representation, was it a sandbox? To all three: yes, very poorly.
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 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.
The article, which you may not have read, specifically calls out the use of JBang[1]for this purpose.
[1] https://www.jbang.dev/
I absolutely did read it when Max posted it to /r/java. Jbang doesn’t solve what you think it solves.
Actually, it probably does. Though I'm more of a fan of Java developing to a stage where it does what these 3rd party projects do and more.
Type the following prompt into any AI and feel free to argue your point with the AI: "what does jbang solve?"
what is it that you feel jbang does not solve in this?
> There is no way to get your jar + the vm into a binary.
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.
[1]: https://keenwrite.com
[2]: https://github.com/kirbylink/warp
[3]: https://repo.autonoma.ca/?action=repo&repo=keenwrite.git&vie...
https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa...
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.
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"
Yes we talked about this on Reddit. I don’t think it’s impossible it’s just work that needs to be done!
I really think that this aligns with the “paving the on ramp” type of stuff. Making the build tooling first class and simple will help adoption.
What's wrong with Maven and building fat JARs?
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.)
>There is no way to get your jar + the vm into a binary.
GraalVM native image allows doing exactly that. Should be as easy as adding a single gradle plugin
Yeah even js is better for CLI, just npm install it. The way its distributed also makes a huge difference.
jbang install does the same. Not enough for you?
I never came across it. I never used anything that installs with jbang, and I bet Im not alone.
Most devs have npm installed always, I don't like it but its effective at delivering software to my development environment.
yes, so now you know it exist - give it a try :)
and yes, works on npm, uvx, etc. too.
`npx @jbangdev/jbang`
isn't this exactly what modules and jlink do?
I spent a long time caring about JVM startup time and CLI suitability (and wrote nailgun [0] over 20 years ago and jsap [1] shortly after specifically because of it), so it's pretty wild to see how far things have come. Modern JVM startup speed and GraalVM native-image have eliminated most of the old excuses. jlink+jpackage help a lot with distribution, and JBang takes it to another level. I've used JBang before but still learned some new tricks from this post. Honestly, it feels like what JNLP/WebStart should have evolved into.
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
[1] https://martiansoftware.com/jsap/
[2] https://github.com/charmbracelet
Strokes chin inquisitively in Babashka... hmmm...
Edit: Heh... https://rattlin.blog/bbgum.html
That's a cool approach!
Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go.
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.
Its not necessarily fair to use past experience with programming languages that have been seeing major updates year over year. Java as a command line environment has been pretty painless for me, particularly Saxon. Just need to alias the command to include a path to the jre binary.
Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.
Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years.
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.
Right, as I said I also think Python has similar issues with startup time.
I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.
It just so happens that I’ve built one already: TUI4J (Terminal User Interface for 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!
I had no idea what brief was until I read the env var api key docs in the subdirectory. I think you should not lead with "it's a tui4j app!" and "it's terminal chat!". It's a terminal OpenAI ChatGPT interface. Screenshot wouldn't hurt either, given it's an advertisement for the presentation library.
Great ideas for both :)
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!
cool - you've hidden that well as I spent a lot of time searching for these.
Will definitely check it out.
...where is the jar for brief? :)
I made some tweaks to the Github releases config, you should be able to do this now as well:
curl -L -o brief.zip https://github.com/WilliamAGH/brief/releases/latest/download... unzip brief.zip cd brief-*/ ./bin/brief
Cool - but I really was hoping for a maven coordinate or a .jar since then I could run it directly with jbang :)
ah - tui4j is continuation of latte. Cool - now I grok why it looked similar. cool!
Hope you enjoy tui4j and brief!
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".
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’m about the same. I’ve had one Java project going for over 10 years. It’s a collection of utilities that I use for work everyday that has grown substantially over the years. It is a CLI program that runs in my Mac, Linux servers and Linux HPC clusters. It is built with a fat-JAR concatenated to a shell stub in front that makes it effectively a single-file install. I also wrote a complete library for defining CLI programs. It is pretty easy to use, but it relies on reflection and annotations, so Graal has been difficult to get working (or was the last time I tried).
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.
> 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 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.
And in 2026 I want to make java TUI's a reality.
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.
Using modules and jlink your Java image would be much smaller than 200mb. Full desktop apps with ui’s can get down to 30mb.
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.
The problem is that packaged Java CLI utilities will also take 20MB+. The minimum size is still much too big for that class of programs. Also, AoT compilation was an absolute pain last I tried it, it's a big change for an ecosystem that was always designed as modular and dynamic. I love Java, but for CLI apps I'll take Rust whenever possible.
But it takes ages to compile. Or at least that was my experience with .NET9 a few years back.
On WSL/Fedora 43, building hello world:
Obviously I don't know how that translates to a non-trivial application.Are you really a developer, because it sounds like you're conflating or confusing language technologies?
This ship sailed a long time ago.
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 SSD would like a word with you :) I don’t say every app needs to be in the kb range. But it is strange that applications for the terminal eat up multiple megabytes. I see the reason when this is statically linked though and one needs stuff like open ssl etc.
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.
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.
Yes - this is what we need more off - just not only in clojure space.
I done https://github.com/jbangdev/jbang-jash for shell processes and smallrye process io also done a lot for nice shell apis.
Files access could be another.
jbang provides the similar binary - for now bash+jvm based but all simple installable. I have native jbang binaries which are even less than 70 mb :)
Definitely going to check out babashka more for inspiration.
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.
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
Someone else on the page commented about Oracle. Why are there still people hung up on Oracle or Ellison when if anything, they've helped Java to thrive more.
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.
I'm a progressive -- just as I am not dumping my climate friendlier Tesla at a loss because Musk is a Nazi buffoon, there is no way I am walking away from my GraalVM compiled babashka binary because another billionaire turd kicked Stephen Colbert off the tonight show. I can mourn and label both as petulant and stupid, without having to bleed my back like Saint Thomas More.
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.
It never ends.
It is not only the language but also the mindset and culture. When in Java System.exit() and even System.println() are treated as smells and I have to actively push to get exceptions from the company wide style I'll just write Rust and be done.
Thats my whole point in my blog - we need to change the mindset.
Other ecosystems just have much less "enterprise rules" applied to them - break free :)
Company wide styles that restrict things generally rather than putting them in context are bad smell itself.
Haven't checked graalvm in a long time. So, I got graalvm-jdk-25.0.1+8.1 for x86_64. It's a lot faster than Julia, and maybe 43ms is not slow in "human terms", but it's still pretty slow compared to some other competition. This was for a helloworld.jar [1]. On my laptop (i7-1370P, p-cores) using tim[2]:
Also, probably there is some way to tune this, but it used over 128 MiB of RSS.[1]: https://github.com/jarirajari/helloworld [2]: https://github.com/c-blake/bu/blob/main/doc/tim.md
That is just a normal JVM with optional Graal components if enabled, but not being used. The default memory allocation is based on a percentage of available memory and uncommitted (meaning its available for other programs). When people mention Graal they mean an AOT compiled executable that can be run without a JVM installed. Sometimes they may refer to Graal JIT as a replacement for C1/C2 available also in VM mode. You are using a plain HotSpot VM in server mode, as the optimized client mode was removed when desktop use-cases were deprioritized (e.g. JWS discontinued).
You are correct and I apologize for the misimpression.
`native-image -jar helloworld.jar helloworld` did take a whopping 17 seconds to compile, what might be the smallest possible project. That does makes me worry for iterations trying to get better perf in a context where startup overhead matters, BUT the executable it produced did run much faster - only about 1.8x slower than `tcc -run`:
Perl has 2 more shared libraries for ld.so to link, but is somehow faster. So, there may still be some room for improvement, but anyway, thank you for the correction.(Also, I included 4 of the faster comparative programs to show additionally that the error bars are vaguely credible. In truth, on time shared OSes, the distributions have heavier tails than Gaussian and so a single +- is inadequate.)
--
EDIT: So, the ld.so/dynamic linking overhead was bothering me. I had to get a musl + zlib build environment going, but I did after a few minutes and then found this result with a fully statically linked binary executable:
(I should have noted earlier that /n -> /dev/null is just a convenience symlink I put on all my systems. Also, this is all on Linux 6.18.2 and the same CPU as before.)Also, only around 4.2 MiB of RSS compared to ~1.8 MiB for dash & awk. So, 2.4x the space and only ~4X the time of static awk & dash. That might sound like criticism, but those are usually the efficiency champs. The binary size is kind of hefty (~2x like the RAM use):
So, I guess, in 2026, Java start-up overhead is pretty acceptable. I hope that these "real numbers" can maybe add some precision to the discussion. Someone saying "mere milliseconds" just does not mean as much to me as 400 +- 4 microseconds, and perhaps there are others like me.Thanks for the corrected evaluation. Just for your awareness, the HotSpot team is working on offering a spectrum of AOT/JIT options under the Leyden project [1]. Currently one has to choose between either a fully open world (JIT) or closed world (AOT) evaluation. The mixed world allows for a tunable knob, e.g. pre-warmup by AOT while retaining dynamic class loading and fast compile times for the application. This will soften the hard edges so developers can choose their constraints that best fit their application's deployment/usage model.
[1] https://openjdk.org/projects/leyden
> Try a GraalVM native image. Milliseconds. Gone.
Try building a GraalVM native image. Minutes gone.
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.
More gigabytes of ram than your machine has will be gone too.
Luckily, that's only during aot compilation and not runtime.
Right but the inspiration for this article is using Java as a terminal vibe coding language, so the aot step would be part of the critical path.
I’m not surprised this was not obvious to the LLM that “cleaned up my notes” for the “author”.
You can do this in Java 21, create this small Java file and run it immediately:
Include the .java extension, you're running the file directly.time java HelloWorld.java
You can do better now:
https://openjdk.org/jeps/330 https://openjdk.org/jeps/458 https://openjdk.org/jeps/512I often combine these approaches with https://get-coursier.io/ when I need to fetch third-party dependencies.
Will 2026 be the year hammers get a little phillips head on the back in case you run into one of those weird ribbed nails?
Java in the terminal works exquisitely well already, and it’s called Babashka. Clojure rocks, Bash reaches, and Java provides a rock-solid foundation.
It sounds Russian, no thanks.
from https://old.reddit.com/r/java/comments/1pzfmka/2026_the_year...
https://www.jbang.dev/
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.
how does this handle classpath
Imagine having to know the programming language used to write a program to run it.
$ 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!
thats why you use jreleaser and publish it so you just run it as `foobar`
Lets please not mix up good dev flows with end user flows...this is not unique problem for java.
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 :)
I didn't know about JBang, it looks awesome. Does it work somewhat like uv?
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.
Why do you think is this?
It makes a difference in size, in how arguments tend to be handled, and so forth.
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.
> 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.
There's a poster upthread who seems to have done what you're describing: https://github.com/WilliamAGH/tui4j
Java feels like the COBOL of our times, and the JVM like the IBM 360 architecture.
I'm sorry, but this is a big load of crap and that includes some of the comments in here. Java enthusiasts are the absolute world champions of sugarcoating the shortcomings of Java and the JVM in general.
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.
I'm sorry, but this is a big load of crap and that includes some of the comments in here. Java enthusiasts are the absolute world champions of sugarcoating the shortcomings of Java and the JVM in general.
Love you too.
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.
Check - agreed.
Now, let’s consider how this process looks in Java....<rant>
It feels like you missed the last 5 years of improvements..so let me show you how this works in java when using jbang:
You download JBang, and immediately have all the tools needed to manage dependencies, write applications, and run other Java applications with a simple command.
Since you probably don't believe me I'll show you some of it here:
`jbang init -t cli hello.java` - you get a hello.java that declare picocli dependencies and you can run it as `./hello.java`, you even do `jbang app install hello.java` and just use `hello`. You can do this with your own scripts, preexisting jars or existing Maven artifacts.
- yes it will also have downloaded right JDK for you; you can easily swith to other versions, either `jbang --java 25 hello.java` or even `jbang --java 8 hello.java` if you really wanna go back in time :) The java version can be baked into your script or jar so it is NOT a requirement for your end user to be aware.
`jbang edit hello.java` will offer to install vscodium based IDE that gives you an IDE environment to write java in.
`jbang export fatjar hello.java` gives you a runnable fat.jar
`jbang export maven|gradle hello.java` gives it a full blown maven/gradle if you are forced to be Enterprise Compliant :)
You can even run and distribute these sources by just commiting to a github repo and just do `jbang <repourl>` or use jbang catalogs etc. Lots of opportunities.
Reading this and reddit thread I see that the final publish of jars/executables is still too tedious I'm going to try solve that challenge as we have all the pieces (IMO) with jbang/jreleaser and modern JDKs.
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.
don't play well with upx - how so? yes there is the usual upx overhead but "just works" when I tried using it?
about graalvm native - definitely not going to say its perfect nor easy; but Quarkus definitely have a whole ecosystems of java libraries and framework setup that just works when using native builds.
That said - I think we dont need to go to full native for lots of usecases.
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.
Yeah, I couldn't wait for JDK developers to do it so I built jbang to make that available today.
You've largely ignored everything I’ve said. Instead, you proposed workarounds – which is precisely what most people want to avoid. Who distributes applications as fat jars? What is this? 2004? You’re supposed to distribute your application as executables. I’ve brought up numerous complaint regarding jpackage and jlink, and none of them have been addressed by jbang. Furthermore, you accuse me of not having used Java in the last five years, which is frankly ridiculous; I've spent almost two decades developing software on the JVM. Funnily enough, I had to write my own sbt plugins because jlink and jpackage are so painful to use.
Regarding UpX: it simply doesn’t work with Windows binaries generated by Graal – see this issue: https://github.com/oracle/graal/issues/7605. They've been ignoring this for three years instead of fixing it. Meanwhile, it works perfectly with Go binaries or .NET’s AOT compiler. I’m not trying to bash your project, but the reality is that no one with little to no Java experience is going to discover and install jbang. Features like this should be included with Java out of the box.
You've largely ignored everything I’ve said. Instead, you proposed workarounds – which is precisely what most people want to avoid. Who distributes applications as fat jars? What is this? 2004? You’re supposed to distribute your application as executables.
and still npm, python, and other ecosystems don't do that. they effectively ships what corresponds to jars with dependency metadata.
I also did not say fat jars (even though that works fine too).
Why don't java world be ok with utilizing that option like other ecosystems.
I know why they didn't do it in past when something like jbang did not exist - just like javascript didn't do it before npm (and fast node runtime) came around...
I’ve brought up numerous complaint regarding jpackage and jlink, and none of them have been addressed by jbang.
I explicitly wrote: "Reading this and reddit thread I see that the final publish of jars/executables is still too tedious I'm going to try solve that challenge as we have all the pieces (IMO) with jbang/jreleaser and modern JDKs." so I did not claim jbang solves it - I said I could see how it could be better.
What I did show or at least tried to was that your complaint about something like scala-cli and how Go could do all things out of box...jbang exist to bridge that gap.
Furthermore, you accuse me of not having used Java in the last five years, which is frankly ridiculous;
I did not claim that at all. I said you seem to have missed the last years improvements in this space (jbang being a key one enabling majority of the issues you brought forward).
I've spent almost two decades developing software on the JVM. Funnily enough, I had to write my own sbt plugins because jlink and jpackage are so painful to use.
yes, I agree jlink and jpackage is not good enough.
I haven't tried tackle it yet as I used jreleaser most of time to hide that pain - and I agree its not solved yet...but also trying to show that distributing everything as native OS binaries is NOT an absolute requirement and not what other ecosystems does.
Heck, even Go allow for running git repos by compiling it locally before running it... jbang allow similar workflows - on top of plain java.
Regarding UpX: it simply doesn’t work with Windows binaries generated by Graal – see this issue: https://github.com/oracle/graal/issues/7605. They've been ignoring this for three years instead of fixing it. Meanwhile, it works perfectly with Go binaries or .NET’s AOT compiler.
gotcha - haven't tried it on windows for a while and looks like it did work in GraalVM 21 and just issue on future versions.
I’m not trying to bash your project, but the reality is that no one with little to no Java experience is going to discover and install jbang. Features like this should be included with Java out of the box.
yeah - well neither node, python and others had these to begin with.
Its a very Java'esque mindset to require it in the default toolchain to be considered useful.
I wonder why anyone even still try using maven or gradle or sbt - it does not come with Java itself either :)
But latency. No Java app I have used in 25ish years has ever started in a reasonable amount of time.
> started in a reasonable amount of time
A hasty generalization with a little confirmation bias, perhaps?
From Claude:> 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.
It’s not a generalisation. I am a specific individual relating my own experiences. I have no idea what your app is and have had zero reason to use it.
It's a non-issue with GraalVM native binaries. See https://news.ycombinator.com/item?id=46445989 for an example: this CLI tools starts in ms, fast enough you can launch it during tab completions and have it invoke a REST API without any noticeable delay whatsoever.
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.
Time comparisons are (or should be) relative. https://news.ycombinator.com/item?id=46447490
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.)
how about jshell? it comes with every java distribution
Shameless plug for jshelled (jshell for gradle projects) https://github.com/gravitation1/jshelled
yes I thought this was going to be about jshell too.
jshell is amazing, I don't think enough people know about it!
2026 is going to be the year of learning languages as you review LLM generated code
Author of blog here - this was posted just as I started eating my New Year Dinner - Happy New Year :)
I get the argument from this article that it’s possible.
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.
I'm definitely not going try to force it upon those who don't like java - but I'm saying that the Java peg is way more round than most believe so don't just start using another slightly round peg like python, go, javascript etc. because others said its required :)
The argument is probably that it’s no longer square.
Article meta comment: show me, don’t tell me.
No show —> not easy enough —> too lazy to look it up, already got python/go/ruby quick cli methods. LLM generated even easier.
I wish the article dug deeper into how the workflow would look like in the practical sense when using jBang and jReleaser.
Thats part of what I want to do more of in 2026 and I hoping others will help as otherwise I'll just be sitting in my own quiet echo chamber :)
Strangely, not a mention of groovy which I seem to remember was somewhat motivated by use cases such as this?
Going to be honest
Absolutely shocked Java wasn’t in the terminal
I know I don’t use it, but wow.
Honestly, super impressed that that they’ve got the traction they do without it but, I think the takeaway is that Java developers like having everything in the IDE— so I’d imagine agentic in the ide will yield higher returns than switching modalities
There is already a lot of Java in agentic systems and IDE integrations — but that alone won’t break the stereotype.
The real blocker isn’t capability, it’s perception: many people stop before even trying Java in the terminal. All while Python/JS are seeing a surge in terminal tooling, despite similar (or worse) startup cost, dependency sprawl, and multi-GB installs — and the reaction there is often “this is fine, let’s ship and use.”
Until Java is visibly normal in the terminal, agentic features in IDEs won’t change that mental model.
Very clearly written by AI. Java in the terminal sounds awful. Programming Java is awful.
No thank you.
When did you last program Java? It’s changed a lot from the Java 8 days.
I am not in the ecosystem anymore but it did a lot of things right.
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.
Can you back up your claim the post is written by AI?
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.
- The question/answer style.
- The "It's not X, It's Y" construction.
This is all in the first sections.
I agree. The entire "The Path Forward" and "The Bottom Line" breakdowns at the bottom gave me the same impression.
I think it’s a mix of human and LLM writing
Max said he wrote it, but used AI to clean it up in the post on /r/java.
No, Java (or frankly anything JVM-based) on the terminal is a terrible experience.
I'm not saying we should phase Java out. But it's pretty clear to me that Java was a bad experiment in almost every aspect, and we should at least not add new use cases for it.
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...
And yet Java is more then Java. There are lots of more modern languages on the JVM. The ecosystem is huge and still has lots of inertia.
Yeah. Some of my critique applies to the language, some on the JVM and thus cross language.
Kotlin sure is less awful, for example. But the JVM, as I describe, was always a failed experiment.
Let's hope not.
I would use this instead, https://babashka.org/
babashka is for clojure
clojure is java. you have full access to the entire ecosystem, with none of the headaches.
came here to say the same
The moment you introduce the jvm, is the moment people flee.
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.
Go and "simpler"? Really?
C is simpler, Python is simpler, but Go?
Indeed
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.
Go is one of the simplest languages there is. Not always easy to create something at scale IMO, but certainly simple.
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.
The question mark at the end is an easy out for us to claim Betteridge’s law.
Yeah, well - I didn't make a factual claim and then questioned it. I asked who is with me? - and no nor yes is not a meaningful answer to that :)
"Does binarymax understand the concept of yes-no questions?"
use rust or go, please
single binary, no complex deps, ftw
[dead]
Go?
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.
Java is legacy... when you started working with Python, Golang, Rust, Typescript, Swift... still need Java??
Legacy doesn't seem to mean what you are implying. I suggest typing the following prompt into any AI and debating it with the AI: "define legacy in terms of programming languages".
Looking forward to implementing a AbstractCommandlineParserFactoryBeanServicePatternFactory
it shows you definitely use a certain niche of Java but I hear you on the funny part.
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 ;)
> AbstractCommandlineParserFactoryBeanServicePatternFactory
...Locator