2026: The Year of Java in the Terminal? • Hacker News Board

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

#81

Post by thomashabets2 » Wed, Dec 31, 2025, 6:22 PM UTC

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…

> Java on the other hand makes it impossible to get a single distributable.

Heh, I find this very amusing and ironic, seeing how Write Once Run Anywhere was a stated goal with Java, that failed miserably.

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

#82

Post by Eduard » Wed, Dec 31, 2025, 6:23 PM UTC

binarymax wrote: post #70

The question mark at the end is an easy out for us to claim Betteridge’s law.

"Does binarymax understand the concept of yes-no questions?"

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

#83

Post by newsoftheday » Wed, Dec 31, 2025, 6:24 PM UTC

laughingcurve wrote: post #14

The article makes no compelling points to me as an avid user of these applications. 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

Someone else on the page commented about Oracle. Why are there still people hung up on Oracle or Ellison when if anything, they've helped Java to thrive more.

The real threat has been and continues to be ... Google. They pulled a Microsoft move (that they got busted for) and Google got away with it. Google killed Eclipse as the IDE for Android development and threw that business over to their Russian buddies at JetBrains.

Google is the threat to Java, not Oracle.

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

#84

Post by ninth_ant » Wed, Dec 31, 2025, 6:25 PM UTC

I get the argument from this article that it’s possible.

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.

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

#85

Post by thomashabets2 » Wed, Dec 31, 2025, 6:27 PM UTC

ktpsns wrote: post #76

thomashabets2 wrote: post #75

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

Yeah. Some of my critique applies to the language, some on the JVM and thus cross language.

Kotlin sure is less awful, for example. But the JVM, as I describe, was always a failed experiment.

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

#86

Post by nathell » Wed, Dec 31, 2025, 6:27 PM UTC

Java in the terminal works exquisitely well already, and it’s called Babashka. Clojure rocks, Bash reaches, and Java provides a rock-solid foundation.

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

#87

Post by whalesalad » Wed, Dec 31, 2025, 6:32 PM UTC

Eduard wrote: post #80

whalesalad wrote: post #3

I would use this instead, https://babashka.org/

babashka is for clojure

clojure is java. you have full access to the entire ecosystem, with none of the headaches.

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

#88

Post by gred » Wed, Dec 31, 2025, 6:33 PM UTC

WD-42 wrote: post #24

Looking forward to implementing a AbstractCommandlineParserFactoryBeanServicePatternFactory

> AbstractCommandlineParserFactoryBeanServicePatternFactory

...Locator

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

#89

Post by fweimer » Wed, Dec 31, 2025, 6:36 PM UTC

voidfunc wrote: post #42

chamomeal wrote: post #26

Earlier quoted context omitted.

Yeah it’s funny how “Java runs everywhere” was a huge selling point of the JVM. But now it’s not even included in macOS by default, so if you want somebody to use you Java/clojure CLI they have to install Java. And that will raise eyebrows and make people think “what is this, 2010??”

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.

Bundling the JRE in the bundle typically results in something that is not redistributable with the default OpenJDK license: The Java ecosystem is heavily tilted towards the Apache license, but Hotspot is licensed under the GPL v2 only (no classpath exception). The Apache license and older GPL versions (before 3) are generally assumed to be incompatible.

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

#90

Post by CamouflagedKiwi » Wed, Dec 31, 2025, 6:39 PM UTC

Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go.

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.