Strangely, not a mention of groovy which I seem to remember was somewhat motivated by use cases such as this?
2026: The Year of Java in the Terminal?
71–80 of 191 posts
Re: 2026: The Year of Java in the Terminal?
#72Earlier quoted context omitted.
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.
Re: 2026: The Year of Java in the Terminal?
#73I'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.
Re: 2026: The Year of Java in the Terminal?
#74Java 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 int…
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.
Re: 2026: The Year of Java in the Terminal?
#75I'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...
Re: 2026: The Year of Java in the Terminal?
#76I'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.
Re: 2026: The Year of Java in the Terminal?
#77how about jshell? it comes with every java distribution
Re: 2026: The Year of Java in the Terminal?
#78Article 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.
Re: 2026: The Year of Java in the Terminal?
#79I 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
Re: 2026: The Year of Java in the Terminal?
#80I would use this instead, https://babashka.org/
babashka is for clojure