warp VS Codename One

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.

codenameone.com — Open source, cross-platform, mobile app development toolchain for Java/Kotlin developers. Free for commercial use with an unlimited number of projects

This was resolved in this issue: https://github.com/codenameone/CodenameOne/issues/3706

Naturally depends on the use case, yet they work good enough to be in business for 20 years.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm-tools/

https://www.codenameone.com/

Android 5 & 6 (only changed back into JIT/AOT due to long compile times), https://www.infoq.com/news/2014/07/art-runtime/

Unfortunely the best well known, Excelsior JET, is no longer in business, most likely due to GraalVM and OpenJ9 being available as free beer, while PTC, Aicas Codename One are safe in their domains.

There is also RoboVM (https://github.com/MobiVM/robovm) as free beer, however it actually started as a commercial product, and the acquisition from Xamarin kind of stagnated it (naturally).

At Codename One, we were using App Engine when our daily billing suddenly skyrocketed from a few dollars to hundreds. The potential cost was so high it threatened to bankrupt us within a month. Despite our best efforts, including educated guesses and fixing everything we could, we were never able to pinpoint the specific bug. Instead, we had to solve the problem through brute force.

We don't use GraalVM since our project was developed prior to its existence and we aimed for deeper native integration than it can offer: https://github.com/codenameone/CodenameOne

XMLVM, Codename One and iSpectrum (cross compile Java code from an Android app or creating one from scratch

I suggest filing an RFE in the issue tracker.

Thanks. It's always good to get another reminder. Yes, it was reported. u/shannah78 is working on this but we have time until November.

please check this issue https://github.com/codenameone/CodenameOne/issues/3686

We use ParparVM which we wrote. It compiles a subset of Java 8 (sort of) to native by translating the bytecode to C and passing that through XCode. The reason we took this path and not the path of "direct to native", is that it allows for future compatibility.