search

Rails-18xx / Rails

Rails 18xx Java Application Main Repository
GNU General Public License v2.0
36 stars 22 forks source link

Build Native Installers/Executables #110

Closed madoar closed 4 years ago

madoar commented 4 years ago

One or two weeks ago Java 14 has been released. One of the new features of this release is the new jpackage tool, which can be used create self-contained Java applications, see https://openjdk.java.net/jeps/343 for more details.

My idea is now to use this tool instead of our current maven plugins to build our applications/installers. The benefit of the jpackage tool is that it comes with a packaged Java Runtime, which removes the need to install a JRE separately.

I do not propose to increase our supported Java version to 14 I propose to add an additional step to our GitHub Actions pipeline that uses JDK 14 to build an executable that is then automatically added to the Releases page on GitHub.

neutronc commented 4 years ago

sure as an alternative i am willing to do that. Question : what will be the acceptance of the enduser getting the JRE bundled ?

madoar commented 4 years ago

I have no clue actually. It is important to have in mind that this approach would bundle the OpenJRE and not a commercial one like the Oracle JRE. I can't remember that I was asked to accept an enduser agreement when installing OpenJDK on my system...

jklap commented 4 years ago

What is the benefit of switching to the use of jpackage over the use of our current Mac app bundler?

The current plugin (maven or the gradle version) also has the ability to embed the JRE via the bundleJRE option also so I think that is a wash. And I think we then lose out on the ability to generate the dmg without additional work with jpackage?

One nice thing about jpackage is that is does also support rpm & deb generation but don't know that it has the currently flexibility as our current plugins on how to define the structure.. likely not some much of an issue now as our usage is pretty basic (or actually just straight up broken) but just something to keep in mind.

madoar commented 4 years ago

What is the benefit of switching to the use of jpackage over the use of our current Mac app bundler?

jpackage has the big benefit that it is part of the JDK. It does not require any thirdparty plugins. The Mac app bundler as far as I know is currently only part of the gradle build script (please correct me if I'm wrong). If I remember correctly I previous tried to add it for maven as well but I had some problems integrating it.

The current plugin (maven or the gradle version) also has the ability to embed the JRE via the bundleJRE option also so I think that is a wash. And I think we then lose out on the ability to generate the dmg without additional work with jpackage?

A big advantage of jpackage is that it uses jlink behind the scene, which allows you to strip down your JRE to a minimum size. For example if your application does not require network code why should your JRE contain the relevant logic? jlink can detect this for a Java application and cut down a JRE to contain only the required functionality. This minimizes the size of your final installers/executables.

Another issue with our current (maven-/gradle-) plugin-based approach is that at least some of the plugins do not package a JRE with the executable. This is problematic because as far as I understand Java the trend is to not deliver the JRE separately in a distant future version. This makes it unwise to provide a Java Application without a corresponding JRE. Instead there are two alternative approaches which I think are meant as a long-term replacement:

jklap commented 4 years ago

I'm not too worried about including other plugins; use of plugins is a given these days with builds.

FYI, I've also redone the gradle build scripts bringing it up to date and killed it's dependency on the maven build. I'll be pushing that PR next week. I also think that we should settle on a single build tool-- I've used both maven and gradle extensively but do have a leaning towards gradle. The gradle update does include both the Mac app build and the RPM and deb builds found currently in the maven pom.

But in any case, regarding the question at hand here, this just seems like it's adding some complexity with low return (have to add JDK 14 to the build, etc to only give us jlink improvements) but if this is something you would like to take on and POC it, more power to you from my perspective!

madoar commented 4 years ago

PR #114 illustrates in a POC what I'm proposing. Remaining Tasks:

Feel free to tell me what you think about this approach.

blentz commented 4 years ago

My general guidance is to do whatever is easiest for the end-user. If we can support native installers and executables without too much overhead, I'm okay with that. 🙂

In terms of JDK version support, I don't think we need to support more than N+1 versions. So, now that 14 is out, let's focus on making sure things work on JDKs 13 and 14. Anything older is nice, if it works, but I think our time is better spent elsewhere rather than maintaining backward compatibility with ancient JDKs.