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

181–190 of 191 posts

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

#181

Post by NovaX »

cb321 wrote: post #155
NovaX wrote: post #130

Earlier quoted context omitted.

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 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`: 97.0 +- 1.7 μs (AlreadySubt…

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

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

#182

Post by mands »

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…

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.

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

#183

Post by vips7L »

maxandersen wrote: post #153
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…

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

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.

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

#184

Post by martylamb »

slowmovintarget wrote: post #131
martylamb wrote: post #79

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…

Strokes chin inquisitively in Babashka... hmmm... Edit: Heh... https://rattlin.blog/bbgum.html

That's a cool approach!

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

#185

Post by nailer »

thangalin wrote: post #101
nailer wrote: post #91

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? $ 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 st…

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.

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

#186

Post by wcallahan »

maxandersen wrote: post #161
wcallahan wrote: post #37

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…

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

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

#187

Post by wcallahan »

maxandersen wrote: post #162
maxandersen wrote: post #161

Earlier quoted context omitted.

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? :)

ah - tui4j is continuation of latte. Cool - now I grok why it looked similar. cool!

Hope you enjoy tui4j and brief!

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

#188

Post by voidfunc »

nineteen999 wrote: post #141
voidfunc wrote: post #42

Earlier quoted context omitted.

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.

> platform specific Write once, run everywhere.

java -jar

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.

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

#189

Post by maxandersen »

wcallahan wrote: post #186
maxandersen wrote: post #161

Earlier quoted context omitted.

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 :)

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

#190

Post by pregnenolone »

maxandersen wrote: post #172
pregnenolone wrote: post #109

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

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, distrib…

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.

Post reply on HN