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.
2026: The Year of Java in the Terminal?
121–130 of 191 posts
Re: 2026: The Year of Java in the Terminal?
#122Earlier quoted context omitted.
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.
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:
> 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
Re: 2026: The Year of Java in the Terminal?
#123Re: 2026: The Year of Java in the Terminal?
#124You can do this in Java 21, create this small Java file and run it immediately: class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); } } java HelloWorld.java Include the .java extension, you're running the file directly. time java HelloWorld.java Hello, World! real 0m0.278s user 0m0.613s sys 0m0.066s
You can do better now:
#!/usr/bin/env java --source 25
void main() {
IO.println("Hello, World!");
}
I often combine these approaches with https://get-coursier.io/ when I need to fetch third-party dependencies.
Re: 2026: The Year of Java in the Terminal?
#125Earlier quoted context omitted.
> 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.
Re: 2026: The Year of Java in the Terminal?
#126Earlier quoted context omitted.
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.
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.
Re: 2026: The Year of Java in the Terminal?
#127But latency. No Java app I have used in 25ish years has ever started in a reasonable amount of time.
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…
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.)
Re: 2026: The Year of Java in the Terminal?
#128Java 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…
>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
Re: 2026: The Year of Java in the Terminal?
#129It 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…
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!
Re: 2026: The Year of Java in the Terminal?
#130Haven'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]: $ tim "awk '{}' /n' 97.5 +- 1.5 μs (AlreadySubtracted)static dash Overhead 94.9 +- 3.2 μs awk '{}' /n Also, probabl…
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).