alt Hacker NewsJava 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 into a binary. You could use graal native image, but build times are super slow, use too many resources, and it’s non-trivial to get working.
Build tooling in the Java ecosystem just isn’t good enough.
Replies
> There is no way to get your jar + the vm into a binary.
My text editor, KeenWrite[1], offered binaries for Linux, macOS, and Windows. The Windows binary was axed due code signing costs and requiring third-party builds, rather than any technical issues with cross-platform packaging.
One way is to create self-extracting executable binaries using a tool such as warp[2]. I've built an installer script[3] (install.sh) to create platform-specific launchers. Running `time keenwrite.bin --version` on Linux shows 0.327s; after the first run, subsequent launches are quick.
[2]: https://github.com/kirbylink/warp
[3]: https://repo.autonoma.ca/?action=repo&repo=keenwrite.git&vie...
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.
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??”
> 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.
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.
The article, which you may not have read, specifically calls out the use of JBang[1]for this purpose.
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.)
Yeah even js is better for CLI, just npm install it. The way its distributed also makes a huge difference.
> 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.