Bundle JRE with Zettelkasten

[Elmari]

@RalfBarkow @strengejacke Wie im anderen Ticket angekündigt, hier ein extra Ticket für die Frage des Bundlings.
Hier nochmal eine Zusammenfassung: Ab Java 9+ gibt's kein JRE mehr und da Oracle die Lizensierung geändert hat und die Verwendung nur noch für Entwicklungs- und Nicht-kommerzielle-Zwecke kostenlos erlaubt, existieren mittlerweile OpenJDK-Seiten wie Sand am Meer gefühlt (AdoptOpenJDK, Zulu, Amazon Corretto, ...). Das macht's also alles nicht wirklich übersichtlicher für einen "normalen" Benutzer. Außerdem müssten diese sich dann in Zukunft das JDK runterladen, obwohl sie ja eigentlich nur eine Runtime brauchen.
Statt den JREs kann man sich mittlerweile mit jlink eine eigene JRE bauen, die auf die Komponenten zugeschnitten ist, die tatsächlich vom Programm (hier der Zettelkasten) gebraucht werden. Dadurch schrumpft die Größe des JREs auf 20-40mb (meiner Erfahrung bis jetzt nach). jlink ist aber ein Kommandozeilenprogramm und kommt daher also auch für normale Benutzer nicht in Frage.
Stattdessen also die Überlegung die selbst gebaute JRE mitzubündeln. Das Bauen dieser könnte man, so wie es bisher aussieht, bei jedem Build ebenfalls automatisiert über Actions laufen lassen. Das Ansprechen dieser JRE ist außerdem direkt über launch4j und dem mac app bundler möglich.
Ein Problem, was ich aktuell sehe ist, dass es keine Möglichkeit gibt die JRE mit in die launch4j Exe zu packen. Stattdessen kann man die exe nur so konfigurieren, dass sie auf ein jre relativ zur exe zugreift, statt java im PATH zu suchen. Auf der Homepage von launch4j empfehlen sie daher einen Installer zu bauen, sodass die beiden Dateien ihre relative Position zueinander halten.
Einen Installer könnte man relativ einfach mit innosetup bauen oder man benutzt dafür das neue jpackage von Java 14 benutzen (das macht das fast vollständig automatisiert). Dann könnte man auch wieder die zkn3-Registrierung aktivieren, aber ich weiß nicht, ob für euch ein Installer eine Option ist.

Also:

• Vorteile des Bundlings
  • keine Auswahl eines JDKs nötig
  • keine manuelle Installation des JDKs nötig
  • kleinere Größe im Vergleich zu JDK + Zettelkasten
  • JRE kann direkt in .app gebundled werden
• Nachteile
  • Größe des Zettelkasten wächst
  • Unter Windows Bundling effektiv nur über Installation möglich

Auf Linux bin ich jetzt nicht eingegangen, da hatten wir bisher ja auch nur die .jar-Datei. Das Bauen von .deb und .rpm Paketen sollten wir uns vielleicht mal irgendwann später anschauen.

[RalfBarkow]

@Elmari Vielen Dank für Deine umfangreiche Darstellung der Situation. Ich möchte mich zunächst einmal in die Thematik einlesen und beginne mit Containerize Java, Part 1 – the JVM …

… the JVM itself. If one aims for minimizing the image size or the JVM’s startup time, one might have to create a custom image. […] Another aspect is the large number of JVM variants that have emerged recently. Some of these JVMs contain their own optimizations, e.g. Amazon Corretto [2] or Eclipse OpenJ9 [3], which affect size and resource consumption. In the further course, we use OpenJDK HotSpot and Eclipse OpenJ9 provided by AdoptOpenJDK [4] to show the practical impact of these differences. The versions of OpenJDK (build 11.0.6+10) and Open J9 (build openj9-0.18.1) used are listed in the appendix.

[Elmari]

Gerne. Dein link scheint da ja auch nochmal etwas Infos zu zu geben.
Hier noch ein Link zur jlink Verwendung: jax

[RalfBarkow]

Auf der Homepage von launch4j …

@Elmari Was verstehen die Leute von Launch4j unter "public JRE" ? (siehe unter jdkPreference )

Update 2020-04-03 19:33
Ich denke, "public JRE" ist ein anderes Thema, siehe What are the differences between private jre and public jre?

[Elmari]

Was wir dann hätten wäre ein private JRE, weil es nur dem Zettelkasten zur Verfügung steht und nicht systemweit installiert ist. Dieses private JRE würden wir dann mit launch4j und dem Mac app bundler referenzieren

[RalfBarkow]

Gerne. Dein link scheint da ja auch nochmal etwas Infos zu zu geben.
Hier noch ein Link zur jlink Verwendung: jax

@Elmari Merci für Deinen Link auf das jax Tutorial. Ich darf mich revanchieren Kleine JREs mit OpenJDK 13 erstellen . Kennst Du Dich mit dem "Modulsystem" aus?

Update 2020-04-03 19:47
Oder anders gefragt, ist unser Zettelkasten Projekt bereit für das Modulsystem?

[Elmari]

Ein bisschen Erfahrung hab ich mit dem Modulssystem, aber auch nicht wahnsinnig viel. Ich hab's aber gerade mal getestet und es scheint soweit alles modular zu laufen. Ich push's gleich mal in einen feature branch.

[Elmari]

branch ist hier. Seaglass musste ich leider deaktivieren, das war nicht mehr kompatibel. Alternativ dazu hab ich zwei neue LaFs hinzugefügt, die funktionieren. Die Mindestjavaversion ist jetzt außerdem 11

[strengejacke]

Sea glass kann gerne raus.

[RalfBarkow]

Die Mindestjavaversion ist jetzt außerdem 11

Ist das für alle okay? @Elmari Warum ist Java 11 nun neues Mimimalrequirement? Brauchen wir Java 8 nicht mehr zu unterstützen?

[Elmari]

Das Modulsystem gibt es bei Java erst seit Version 9, Java 8 kann damit nicht umgehen. Java 11 war aber seit Java 8 wieder die erste LTS-Version, daher Java 11. Die Annahme war ja, dass wir dann das selbst-gebaute JRE in Zukunft mit dem Zettelkasten mitliefern, daher müssen wir Java 8 dann tatsächlich nicht mehr unterstützen (und auch sonst, in Hinblick auf Java, nicht mehr auf die Gegebenheiten beim User achten). Aber über das Bundling können wir natürlich noch diskutieren :) Aktuell ist es ja auch nur im Featurebranch.

[Elmari]

Wir hatten hierzu jetzt glaube ich noch keine abschließende Meinung gefunden, zumindest kam mir das bisher nicht so vor. Ich würde daher gern einfach nochmal die Frage in den Raum stellen: Was haltet ihr davon, die JRE in zukünftigen Versionen mitzubundlen und was haltet ihr (um obig beschriebene Probleme zu umgehen) von einem Installer für den Zettelkasten unter Windows?

[Elmari]

Für den Fall, dass Bundling für euch okay ist: Mit commit 8e049 gibt es jetzt im modularity-branch ein NSI-Installer-Script für Windows und ein Maven Plugin für's Bauen von .deb-Dateien für Debian.

[strengejacke]

Wenn es auch hier automatisiert ablaufen kann, und der Aufwand gering ist, überwiegt das deutlich dem "Nachteil" der Dateigröße. Seit der ersten Zettelkasten Version 2002 und dem Umstieg auf Java 2009 ist mittlerweile relativ viel Zeit ins Land gezogen, sodass weder Speicher noch Bandbreite ein Problem sind.

[Elmari]

Ok, super.
Ja, das sollte alles automatisiert ablaufen können. Das Programm, was den Windows Installer baut, (NSIS) läuft zwar nicht als maven plugin, kann aber dafür hier wieder über die GitHub Actions ausgeführt werden, stellt also auch kein Problem dar. Das Bauen der JRE geht über Maven.

[RalfBarkow]

Was haltet ihr davon, die JRE in zukünftigen Versionen mitzubundlen

Diesen Vorschlag finde ich gut; vlg. zum Konzept 'statische Images':

MENGE-SONNENTAG, Rainald, 2020. Java: Project Leyden soll Anwendungen durch statische Images optimieren. Developer [online]. 28 April 2020. [Zugriff am: 28 April 2020]. Verfügbar unter: https://www.heise.de/developer/meldung/Java-Project-Leyden-soll-Anwendungen-durch-statische-Images-optimieren-4710684.html

[RalfBarkow]

Modulsystem

Painlessly Migrating to Java Jigsaw Modules - a Case Study

[RalfBarkow]

See Robert Ladstätter's "A native Scala JavaFX application via GraalVM"

get closer to my goal to compile […] to a native binary.

[Elmari]

See Robert Ladstätter's "A native Scala JavaFX application via GraalVM"

get closer to my goal to compile […] to a native binary.

sounds interesting! unfortunately this may (at the moment) not work for swing apps like zettelkasten: oracle/graal#2644

[RalfBarkow]

See #308

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.