Bug - Fixed r25726 crashes on launch due to unchecked use of new Taskbar APIs

[MCroft]

Do we need to target Java 16+, or is it sufficient to build with Java 16+? If the latter, we could probably do this today.

Since we bundle it, we should be easier about the requirement. However, it will require more work from @fewyn, since you can't cross-compile the packages with this tool, (which suuucks). So it has to build on each platform. It also makes us need to be very specific about how we package things.

I think they are doing the "compile on each platform" thing because this is descended from JavaFX. If anyone wants to really make a big change, we could switch from Swing to JavaFX, which requires this kind of "build each platform" stuff, but at least that won't be a cost if we've already gone to JPackage.

Here's an example, if anyone wants to experiment.. IT's from the incubator version, but that's a single change to remove the .incubator part of the path.

A Guide to jpackage in Java | Baeldung

Learn about the usage of the jpackage command-line tool introduced in Java 14.

www.baeldung.com

 

[heeheehee]

By cross-compile, you mean across OSes, right? As opposed to across Java versions?

I've been staring at github actions a bit more, and I think we'd be able to use those to build in Windows / Mac / Linux VMs which would theoretically render the cross-platform issue moot.

 

[MCroft]

Update: works. There are a lot of command line options this skips (icon, signing the app for the MF app store, etc.

jpackage --input ./ --name KoLmafiaApp --main-jar KoLmafia-25731-M.jar --main-class net.sourceforge.kolmafia.KoLmafia --type PKG

 

[MCroft]

By cross-compile, you mean across OSes, right? As opposed to across Java versions?

I've been staring at github actions a bit more, and I think we'd be able to use those to build in Windows / Mac / Linux VMs which would theoretically render the cross-platform issue moot.

yeah, you can only make the mac version on a mac and the linux version on linux. Can GitHub be used to run on AppleSilicon for the new macs?

 

[MCroft]

and of course there's a (or many) gradle plugins: https://github.com/petr-panteleyev/jpackage-gradle-plugin

 

[heeheehee]

yeah, you can only make the mac version on a mac and the linux version on linux. Can GitHub be used to run on AppleSilicon for the new macs?

Doesn't seem like it. I'd expect that it would be able to build the regular mac version and your new M1 machine would just run it via Rosetta at some performance hit. But I have no idea how any of this stuff works.

 

[MCroft]

We can also publish the jar for people with their own JDKs. The mac installer is 67MB, which makes it 3x as large as the jar itself.

 

[gausie]

I think this is another application for the launcher project idea that I have

 

[fronobulax]

I'm getting confused. I admit that around Java 1.1 or so I swallowed the "write once, run anywhere" Kool Aid and it is still in my system.

For a Java app, what is the benefit of compiling and building a release targeted for an OS on that OS? What problem does it solve or pre-empt? Have we moved to the idea that a release is more than just a jar and I missed it?

A decade ago we built a jar, bundled it with a jre and wrapped things with an installer. The jre and installer were OS specific. We did it because we could control the environment our jar ran in and users could run the app on a locked down system where they did not have Admin privs or permission to change a jre. In those days it was certainly much easier to assemble the bundle on the target OS but there were workarounds.

 

[MCroft]

I'm getting confused. I admit that around Java 1.1 or so I swallowed the "write once, run anywhere" Kool Aid and it is still in my system.

For a Java app, what is the benefit of compiling and building a release targeted for an OS on that OS? What problem does it solve or pre-empt? Have we moved to the idea that a release is more than just a jar and I missed it?

A decade ago we built a jar, bundled it with a jre and wrapped things with an installer. The jre and installer were OS specific. We did it because we could control the environment our jar ran in and users could run the app on a locked down system where they did not have Admin privs or permission to change a jre. In those days it was certainly much easier to assemble the bundle on the target OS but there were workarounds.

It does seem to be against the spirit of that, doesn’t it?

But the Jar is still the same jar and we don’t have to stop publishing it for people who we can’t jpackage for. Like M1 macs, although I expect that will come.

This helps people who only get Java for KoLmafia and never update Java and don’t know why the latest jar won’t run.

And people who update Java but their OS does something ridiculous and breaks their install.

And if we want to put it in any app stores, we can sign it. Not sure if that is a good idea, because of our rate of change, but it becomes possible. Or if the OSes start requiring signed apps as an anti-malware thing.

And if we need different Java modules, we can just supply them.

And if we ever want to ditch swingX and use JavaFX, it requires this.

But we can also publish the jars.

 

[fronobulax]

It does seem to be against the spirit of that, doesn’t it?

But the Jar is still the same jar and we don’t have to stop publishing it for people who we can’t jpackage for. Like M1 macs, although I expect that will come.

This helps people who only get Java for KoLmafia and never update Java and don’t know why the latest jar won’t run.

And people who update Java but their OS does something ridiculous and breaks their install.

And if we want to put it in any app stores, we can sign it. Not sure if that is a good idea, because of our rate of change, but it becomes possible. Or if the OSes start requiring signed apps as an anti-malware thing.

And if we need different Java modules, we can just supply them.

And if we ever want to ditch swingX and use JavaFX, it requires this.

But we can also publish the jars.

So basically "we" are expanding the definition of "release" in terms of packaging and artifacts. I guess the only downsides are resource usage at GitHub and KoLmafia.us and having to document and explain to users just what they need to download.

 

[MCroft]

So basically "we" are expanding the definition of "release" in terms of packaging and artifacts. I guess the only downsides are resource usage at GitHub and KoLmafia.us and having to document and explain to users just what they need to download.

I see it all as a reaction to changes in toolchains and environments. We have cloud build pipelines, containerized builds, CI, ample storage, fast internet, and such that make it easier for us to create and a user to find a convenience package than for them to install and maintain java and learn how to launch a jar.

It's not ideal for anyone wanting to use the CLI (although still doable), but it might help some users.

And our cost is, as you mention, build resources, storage, and making a clear download page.

We used to publish the .exe, but I don't think we have recently. There are definitely arguments against it. I think it's a trade-off of "we know the user has the JVM we expect" vs. "I don't have the tools to help you debug your problem on your platform".

It's a tool, if we want it.

 

[heeheehee]

IMO, if storage is free, and builds are easily automated, then there's no reason not to publish all three of exe / dmg / jar via github.

If users want to continue downloading and running the jar, they're free to do so, but now they'll have options.