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'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

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.

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!

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

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

Installation is via brew, so same experience as for all the other CLI tools you're using. The binary size is on the higher end (52 MB), but I don't think this makes any relevant difference for practical purposes. Build times with GraalVM are still not ideal (though getting better). Cross compilation is another sore point, I'm managing it via platform-specific GitHub Action runners. From a user perspective, non of this matters, I'd bet most users don't know that kcctl is written in Java.

I would rather shove ice picks covered in lemon juice than provide Java or Ellison anymore room in the digital ecosystem. And I’m not talking politics here wrt Ellison, just awful

    $ tim "awk '{}'</n" 'tcc -run /tmp/true.c' 'perl</n' 'py2</n' 'py3</n' 'java -jar helloworld.jar>/n'
    97.5 +- 1.5 μs  (AlreadySubtracted)static dash Overhead
    94.9 +- 3.2 μs  awk '{}'</n
    376.7 +- 4.6 μs tcc -run /tmp/true.c
    525.3 +- 2.7 μs perl</n
    3627.7 +- 6.0 μs        py2</n
    6803 +- 11 μs   py3</n
    42809 +- 71 μs  java -jar helloworld.jar>/n

[1]: https://github.com/jarirajari/helloworld [2]: https://github.com/c-blake/bu/blob/main/doc/tim.md

Try building a GraalVM native image. Minutes gone.

    class HelloWorld {
        public static void main(String[] args) {
            System.out.println("Hello, World!"); 
        }
    }
    
    java HelloWorld.java

time java HelloWorld.java

    Hello, World!

    real    0m0.278s
    user    0m0.613s
    sys     0m0.066s

https://www.jbang.dev/

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?

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.

But I don’t get the argument that this is somehow desirable. Just because it’s possible to smash a square peg into a round hole doesn’t make it a good idea.

No show —> not easy enough —> too lazy to look it up, already got python/go/ruby quick cli methods. LLM generated even easier.

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.

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

No thank you.

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 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.

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.

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.

single binary, no complex deps, ftw

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.