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

51–60 of 191 posts

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

#51

Post by sgjohnson »

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??”

graalvm native binaries?

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

#52

Post by icedchai »

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 worked at a couple of startups that were mostly Java based and had several CLI tools. The focus was building "fat jars" then running them with "java -jar ...", or running scripts that did that. The Java VM was a system dependency and getting it baked into the binary just wasn't a practical concern.

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

#53

Post by nu11ptr »

krzyk wrote: post #17
reactordev wrote: post #4

The moment you introduce the jvm, is the moment people flee. Graal would be needed and then your binaries would be huge. No thanks. Go is much simpler. Rust is much smaller. Java can go die in the office storage closet.

Go and "simpler"? Really? C is simpler, Python is simpler, but Go?

Go is one of the simplest languages there is. Not always easy to create something at scale IMO, but certainly simple.

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

#54

Post by voidfunc »

vips7L wrote: post #49
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.

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

You're asking about a fundamentally different thing.

An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around.

If you want a fully statically linked binary you're diving into graalvm and native-image: https://www.graalvm.org/latest/reference-manual/native-image.... This will give you what you want which is basically something you can wget and chmod +x.

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

#56

Post by vips7L »

voidfunc wrote: post #54
vips7L wrote: post #49

Earlier quoted context omitted.

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

You're asking about a fundamentally different thing. An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around. If you want a fully statically linked binary you're diving into graalvm and native-image: https://www.graalvm.org/late…

I'm not asking about a fundamentally different thing. The success of other languages isn't because they produce installers. Have you tried native image for a non-trivial application? I've been using it since it came out; I was the first adopter of native-image for Quarkus on Windows. I even wrote the documentation for it at the time. It is not trivial to use, the compile times are extremely long, and the resources it requires are sometimes more than a developers machine can provide.

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

#57

Post by eduction »

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??”

Openjdk also dropped a lot of OS support, it basically just windows, Mac and Linux now. And AIX.

No more FreeBSD, Solaris, open Solaris (illumos smartos etc).

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

#58

Post by rus20376 »

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…

The article, which you may not have read, specifically calls out the use of JBang[1]for this purpose.

[1] https://www.jbang.dev/

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

#59

Post by vips7L »

icedchai wrote: post #52
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 worked at a couple of startups that were mostly Java based and had several CLI tools. The focus was building "fat jars" then running them with "java -jar ...", or running scripts that did that. The Java VM was a system dependency and getting it baked into the binary just wasn't a practical concern.

I work at a startup that ships a Java cli to our clients. It is a giant pain in the butt. There are constant support requests from users that are using the wrong version of Java, too old or too new. Sometimes they have to wait weeks for authorization to even install the Java runtime. IT departments are extremely strict about installing Java.
Post reply on HN