But latency. No Java app I have used in 25ish years has ever started in a reasonable amount of time.
2026: The Year of Java in the Terminal?
91–100 of 191 posts
Re: 2026: The Year of Java in the Terminal?
#92Java 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…
What's wrong with Maven and building fat JARs?
It's not dynamic linking, despite excellent support for very late binding in historic Java versions. (Newer versions require specific launcher configurations to use certain platform features, which breaks late loading of classes that use those features.)
Re: 2026: The Year of Java in the Terminal?
#93Java 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/
I absolutely did read it when Max posted it to /r/java. Jbang doesn’t solve what you think it solves.
Re: 2026: The Year of Java in the Terminal?
#94Earlier quoted context omitted.
> 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.
I know Python has been big in the space for longer than uv's existence, but uv ( https://docs.astral.sh/uv/ ) has made Python packaging dead simple to me
I don't think uv makes distribution simple? Unless I've missed something, it doesn't do anything out of the box to help you produce a standalone artifact - it builds wheels but those are only useful for a user that already has python and pip, and don't do anything to deal with Python version drift etc.
Re: 2026: The Year of Java in the Terminal?
#95Java is legacy... when you started working with Python, Golang, Rust, Typescript, Swift... still need Java??
Re: 2026: The Year of Java in the Terminal?
#96I would use this instead, https://babashka.org/
[deleted]
Re: 2026: The Year of Java in the Terminal?
#97Java 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.
I gave up on Java when Oracle took over, because I thought that it was such a horrific move, but, to their credit, they haven't ruined it for everyone (yet)
They've kept it alive, allowed it to grow, and innovate, even let Green threads back in.
I'm not planning on going back to Java, but that's no longer because Oracle.
Re: 2026: The Year of Java in the Terminal?
#98Earlier quoted context omitted.
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.
> 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.
Re: 2026: The Year of Java in the Terminal?
#99Earlier quoted context omitted.
I know Python has been big in the space for longer than uv's existence, but uv ( https://docs.astral.sh/uv/ ) has made Python packaging dead simple to me
I don't think uv makes distribution simple? Unless I've missed something, it doesn't do anything out of the box to help you produce a standalone artifact - it builds wheels but those are only useful for a user that already has python and pip, and don't do anything to deal with Python version drift etc.
uv can install a version of python of your choosing in addition to pulling the specific versions of libraries specified in your lockfile. it's extremely dummy-resistant.
Re: 2026: The Year of Java in the Terminal?
#100Earlier quoted context omitted.
More gigabytes of ram than your machine has will be gone too.
Luckily, that's only during aot compilation and not runtime.
Right but the inspiration for this article is using Java as a terminal vibe coding language, so the aot step would be part of the critical path.
I’m not surprised this was not obvious to the LLM that “cleaned up my notes” for the “author”.