Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2026: The Year of Java in the Terminal?

xam.dk

Post reply on HN
Print view View original

31–40 of 191 posts

Re: 2026: The Year of Java in the Terminal?

#31

Post by TacticalCoder »

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.

Re: 2026: The Year of Java in the Terminal?

#32

Post by qsort »

vips7L wrote: post #18

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 int…

https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa...

Re: 2026: The Year of Java in the Terminal?

#33

Post by vips7L »

qsort wrote: post #32
vips7L wrote: post #18

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 int…

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.

Re: 2026: The Year of Java in the Terminal?

#35

Post by gunnarmorling »

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.

Re: 2026: The Year of Java in the Terminal?

#36

Post by jen20 »

gunnarmorling wrote: post #20
nickstinemates wrote: post #8

Very clearly written by AI. Java in the terminal sounds awful. Programming Java is awful. No thank you.

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.

Re: 2026: The Year of Java in the Terminal?

#37

Post by wcallahan »

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!

Re: 2026: The Year of Java in the Terminal?

#38

Post by waffletower »

waffletower wrote: post #22

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.

Re: 2026: The Year of Java in the Terminal?

#39

Post by hoppp »

vips7L wrote: post #18

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 int…

Yeah even js is better for CLI, just npm install it. The way its distributed also makes a huge difference.

Re: 2026: The Year of Java in the Terminal?

#40

Post by aoli-al »

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?

Post reply on HN