61–70 of 191 posts
Agree, Java also had straight single file execution forever now. Java foo.java. I use it instead of scripts all the time. Solid language with a lot of flexibility, Oracle has done a good job in last few years. Newer Java frameworks are fairly easy and light to use. We have natively image Lambda functions in production. Work well.
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…
Earlier 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.
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.
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.
The JVM installs cleanly and is self contained, but any artifacts, by default, are not shared system wide as this _always_ have been seen as a security risk. The hot term for it today is "supply chain attack".
Instead, most Java programs tow their dependencies, giving it a bloated feel because its all just there, present in front of you, stored and running as your own user.
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…
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...
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…
There's a poster upthread who seems to have done what you're describing: https://github.com/WilliamAGH/tui4j