warp VS Main

jpackage is not the only tool for bundling Java. There is also warp-packer, an open-source tool to create self-contained binary applications from Node.js, .NET Core, and Java. warp-packer requires a similar workflow to Method 2, where you create your modified Java Runtime image and an executable script before bundling everything together into an executable.

https://github.com/dgiagio/warp just googled it, no direct experience

KeenWrite is my free, open-source, cross-platform desktop Markdown text editor developed using JavaFX. The installer script uses warp-packer to create installation-free self-extracting binaries for Windows and Linux.

My desktop text editor[1] is written using JavaFX and leans on Warp Packer[2] to create installer-free, multi-platform executable binaries (without jlink). A user contributed a new dark theme[3], which blends nicely with the desktop.

The JavaFX-based WebView (an HTML rendering component) is lauded, but has no direct API to control the scroll position and is itself a memory hog. Scrolling must be handled through JavaScript, and that indirection is as unwieldy as you can probably imagine. FlyingSaucer is a workable alternative to WebView, but comes with numerous technical issues that rear themselves when embedding a Swing widget inside a JavaFX application---as I discovered during development.

Were I to start from scratch, I would definitely seek out alternative cross-platform programming languages for desktop application development.

[1]: https://github.com/DaveJarvis/keenwrite

[2]: https://github.com/dgiagio/warp

[3]: https://i.ibb.co/QpqS0NS/screenshot.png

"Java -- possible, but you'll need a startup script to just call java -jar some-tool.jar; (also not a good fit for short-lived tools, mainly due to startup times;)"

Two technologies to look at:

* Warp Packer -- https://github.com/dgiagio/warp/

* Liberica Native Image Kit -- https://bell-sw.com/pages/liberica-native-image-kit/

Warp Packer bundles my JavaFX desktop application, KeenWrite into single binary executable files:

* https://github.com/DaveJarvis/keenwrite/releases/download/2.... (Linux)

* https://github.com/DaveJarvis/keenwrite/releases/download/2.... (Windows)

* https://github.com/DaveJarvis/keenwrite/releases/download/2....

The start-up time for the first launch of the .bin or .exe is slow because it unpacks to a user directory. Subsequent starts are fine enough, even when running from the command-line as a short-lived task. Here's the script that creates the self-contained executable files:

https://github.com/DaveJarvis/keenwrite/blob/master/installe...

To create a release for all three files, I run a single shell script from a build machine:

https://github.com/DaveJarvis/keenwrite/blob/master/release....

I could probably generate a binary for MacOS, but not enough people have asked.

(merged) ScoopInstaller/Main #4757 kubescape: Update url and binary naming

As I see it, part of the drive behind tools like Scoop is to overcome the limitations of the binary-shipping strategy common to Windows developers. They are successful at this, I agree, but only partially successful. They come from the tradition of programs like Ninite, which were explicitly built as ways to make the binary approach suck less than it did before.

I see the success of these programs as essentially stemming from the insertion of user interests in the form of a maintainer-like process. Sure, they're still working with the binaries, but the actual process of installing and managing these binaries is controlled by users, for users: https://github.com/ScoopInstaller/Main/tree/master/bucket

This means that you get moderation and in many cases modification to the behavior of the program. In a freeware environment like Windows that's full of shitware, at the very least you can in many cases strip out the ads. That's absolutely not nothing, but at the end of the day it comes from a group of user-maintainers stepping up and saying to developers that no, you cannot simply do whatever you want on my system with your software. That's ... sort of the whole point of a software distribution, in the Linux world!

When I want the latest version of a CLI tool on Linux, I simply `pacman -S package`. That's it; one command. I don't see how it could be any simpler or better than that, and on top of that I'm getting the benefits of moderation and integration with the rest of my system. Perhaps you are emphasizing latest version here, and hinting that you don't get that on Linux distros? That depends entirely on the distro; a software distribution is (roughly) a collection of user interests. An Arch user wants (and gets) the latest versions of all upstream software. A Debian user does not want this or see constant updating to the latest version as an advantage, so that's not what they get.

Here is the definition: https://github.com/ScoopInstaller/Main/blob/master/bucket/avr-gcc.json

Those are all automated by the auto-update script.

Check Merged PRs https://github.com/ScoopInstaller/Main/pulls?q=is%3Apr+sort%... and you will see that the last non-bot one was merged 17 days ago.