Live data from Hacker News

2026: The Year of Java in the Terminal?

xam.dk

111–120 of 191 posts

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

#111
post #91

But 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 instance, a single node Kafka broker starts in ~300 ms.

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

#112
post #74
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 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.

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

#113
post #21
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…

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.

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

#114
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.

My SSD would like a word with you :) I don’t say every app needs to be in the kb range. But it is strange that applications for the terminal eat up multiple megabytes. I see the reason when this is statically linked though and one needs stuff like open ssl etc.

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

#115
post #59

Earlier quoted context omitted.

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.

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

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

#116
post #93

Earlier quoted context omitted.

The article, which you may not have read, specifically calls out the use of JBang[1]for this purpose. [1] https://www.jbang.dev/

I absolutely did read it when Max posted it to /r/java. Jbang doesn’t solve what you think it solves.

Actually, it probably does. Though I'm more of a fan of Java developing to a stage where it does what these 3rd party projects do and more.

Type the following prompt into any AI and feel free to argue your point with the AI: "what does jbang solve?"

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

#117
post #21
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…

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.

[deleted]

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

#118
post #21

Earlier 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.

Are you really a developer, because it sounds like you're conflating or confusing language technologies?

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

#119
Haven'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, probably there is some way to tune this, but it used over 128 MiB of RSS.

[1]: https://github.com/jarirajari/helloworld [2]: https://github.com/c-blake/bu/blob/main/doc/tim.md

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

#120
post #95

Java is legacy... when you started working with Python, Golang, Rust, Typescript, Swift... still need Java??

Legacy doesn't seem to mean what you are implying. I suggest typing the following prompt into any AI and debating it with the AI: "define legacy in terms of programming languages".
Post reply on HN