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

41–50 of 191 posts

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

#41

Post by oncallthrow »

jen20 wrote: post #36
gunnarmorling wrote: post #20

Earlier quoted context omitted.

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…

I think it’s a mix of human and LLM writing

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

#42

Post by voidfunc »

chamomeal wrote: post #26
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 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.

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

#43

Post by manoDev »

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 will never become a player in CLI tooling until build packaging becomes first class.

Python packaging has always been painful and it’s a popular option for CLI regardless.

I don’t think there only rational explanations, technology choices are a lot about culture and dogmas too.

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

#44

Post by Hovertruck »

jen20 wrote: post #36
gunnarmorling wrote: post #20

Earlier quoted context omitted.

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…

I agree. The entire "The Path Forward" and "The Bottom Line" breakdowns at the bottom gave me the same impression.

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

#45

Post by Scubabear68 »

FriendlyMike wrote: post #15

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

Same here. Was using Java in the alpha/beta/gamma days. Have built a lot with it. Would not use it for command line tooling by default, only if it happened to be the simplest option (like maybe a library or something does nearly everything needed).

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

#46

Post by voidfunc »

larusso wrote: post #11

Maybe some of the old beliefs regarding startup time etc are no longer valid. Maybe the programming model isn’t as verbose as it used to be. But I don’t want to distribute a 200MB+ binary. I have colleagues who tell me that c# scripting is so awesome. One only needs .NET installed or use AOT or whatever. Sorry but Go and Rust and good forgive a python script is smaller and mostly easier to read and write then most st…

This ship sailed a long time ago.

Our Go CLI tools are like 100MB+ and often we bundle them in containers that are in the GB+ territory. Nobody cares or at least has cared enough to tell us to minimize stuff.

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

#48

Post by gunnarmorling »

jen20 wrote: post #25

There are approximately no use cases that would get me to run a CLI written in Java on my machine, especially if it required having a JVM installed. There's just no reason for it. The rounding error there is Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else. That said, if the Java community wanted to port reasonable tooling to their…

Assuming JVM installation is not required (to which I agree, it shouldn't be), why would you care which language a CLI tool is written in? I mean, do you even know whether a given binary is implemented in Go, Rust, etc.? I don't see how it makes any meaningful difference from a user perspective.

> Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.

Why do you think is this?

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

#49

Post by vips7L »

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.

Has jpackage been updated to create things that are not installers and don't extract themselves into several files?

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

#50

Post by RickJWagner »

Languages lose users when the tooling becomes too heavy.

You have to learn ( and maintain knowledge of ) build tooling, unit test frameworks, tools for front end / back end development, distribution and packaging systems, directory structures to accommodate all those, etc. ad nauseum.

Then something new and shiny comes out, with much smaller tooling. The lure of easy software construction seduces the user.

It never ends.

Post reply on HN