jar File auf Mac mit Doppelklick starten

[nieselfriem]

Hallo Zusammen,

eine von mir erstellte jar-Datei lässt sich auf dem Mac im Terminal ohne probleme mit

java -jar Tableview.jar

starten
Will ich aber nun diese Datei mit einem Doppeklick starten, dann kommt der Berühmte Fehler


Die Java-JAR-Datei „Tableview.jar“ konnte nicht geöffnet werden.
Überprüfe die Konsole auf mögliche Fehlermeldungen.


Wenn man nun die die Informationen der TableView.jar guckt ist dort als "öffnen mit" eingestellt "jar launcher app (Standart) (15.0.1)" eingestellt. Also im Grunde die java Version mit der ich auch den terminalbefehl ausführe.

Da ich in Sachen mach nicht so bewandert bin und das für meine Frau ist, hatte ich gehofft, dass einie mac-Nutzer hier ium Forum eine lösung für mich habe.

Was ich bisher gemacht habe:
1. Datei aus ausführbar gekennzeichnet mit chmod u+x
2. die manifest-Datei geprüft, ob die Main-Class definiert ist.
3. Geprüft ob die richtige jar-Launcherapp mit der richtigen Versionsnummer (15.0.1) die Anwendung starten soll

Was muss ich im Mac konfigurieren, damit hier ein Doppelklick die Anwendung startet?

VG Georg

 

[kneitzel]

Also das hört sich erst einmal alles korrekt an. Was genau ist die Fehlermeldung? Und hast Du mal die Konsole geöffnet und geschaut, was Du da an Meldungen bekommst?

(Und "Konsole" meint wirklich das Konsole Programm unter Dienstprogramme!)

Ansonsten sind sowas immer typische Probleme die man nicht supporten möchte. Ab Java 11 ist der empfohlene Weg, eben kein jar mehr weiter zu geben. Statt dessen baut man mit JLink ein Image, welches man weiter geben kann. Und ab Java 14 macht man am Besten ein app Image, d.h. Deine Java Applikation wird direkt wie eine App auf dem Mac gehandhabt und enthält alles, was es braucht. Dann braucht man kein global installiertes Java mehr oder so ...

Ich setze hier immer sehr gerne auf Gradle. So ein typische build gradle sähe dann so aus:

plugins {
    id 'java'
    id 'org.beryx.jlink' version '2.22.0'
}

group 'de.kneitzel'
version '1.0-SNAPSHOT'

mainClassName = 'swingexample.Application'

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'
}

test {
    useJUnitPlatform()
}

jar {
    manifest {
        attributes(
                'Main-Class': 'swingexample.Application'
        )
    }
}
jlink {
    launcher {
        name = 'swingexample'
    }
}

Um aus dem image dann eine "Applikation" zu bauen, reicht dann nach einem ./gradlew jlink in dem build Verzeichnis ein
jpackage --type app-image -n SwingExample -m SwingExample.main/singexample.Application --runtime-image image

Erläuterung:
- --type gibt an, was gebaut werden soll. Das ist sonst in der Regel ein DMG auf einem Mac. Aber das wollen wir hier ja nicht.
-n Name des Ziels - es wird also ein SwingExample.app gebaut
-m gibt Modul und Klasse der main Methode an.
--runtime-image gibt an, welches image genommen werden soll. Das ist in der Regel in build das Verzeichnis image.

 

[nieselfriem]

Also in der Konsole bei Mac habe ich leider keinen Fehler finden können. Es wird leider nur die Desktop-Fehlermeldung angezeigt. Die anderen packagemethoden sind mir bisher noch nicht bekannt gewesen und mich verwundert ehrlich gesagt, dass es bei Mac mit einem Klick nicht geht, was im Terminal funktioniert. Ach, es kann manchmal so schwierig sein. 🙁 Aber wieder einmal sehe ich, dass ich um Gradle, wi auch schon bei anderen Themen nicht drum herum komme. Was ich jedoch nicht verstehe ist ist folgender Satz "Und ab Java 14 macht man am Besten ein app Image, d.h. Deine Java Applikation wird direkt wie eine App auf dem Mac gehandhabt und enthält alles, was es braucht. Dann braucht man kein global installiertes Java mehr oder so ..." Woher nimmt man dann die JRE? Denn wenn man das ganze auf einem Linux oder Windows System baut, dann habe ich ja kein JRE die ich in das Image einbauen könnte die auch für Mac binärkompatibel ist.

 

[kneitzel]

Also wieso es nicht funktioniert bei Dir, kann ich dann auch nicht sagen. Wenn das Jar File auf der Eingabeaufforderung funktioniert, dann sollte es auch per Doppelklick funktionieren. Die Einstellung, dass es mit dem Jar Launcher App gestartet wird, ist auch korrekt. Ausführrechte werden nicht benötigt (es ist halt wie bei einem Dokument. Es wird ja nur geladen...). Evtl. noch einmal probieren, die Ausführrechte weg zu nehmen ...

Ansonsten ist die Technik hinter JLink ja, dass alle Teile vom JRE, die benötigt werden, in dieses Image hinein kopiert werden. Das Image ist also eine Verzeichnisstruktur, die die ganze Applikation enthält und im bin Ordner ist unter anderem ein Startscript.
Das ist aber alles nicht ganz so toll auf dem Mac, denn durch das Startscript triggert das ein paar Security Hinweise und es will Rechte bekommen, auf Dateien zugreifen zu dürfen (Wenn es z.B. im Homeverzeichnis liegt).

Bei JPackage wird dann aus dem Script und allem drum herum ein Binary gebaut. Das heißt man benötigt kein Startscript mehr. (Es gibt immer noch Dateien drumherum, aber beim Mac fällt das nicht mehr auf, da dort ja alles im app Ordner "untertaucht".

Mit diesen Grundlagen können wir uns an das "Cross-Compiling" wagen. Das JLink benötigt also erst einmal ein JRE der Zielplattform. Die kann man natürlich herunter laden (als ZIP) und entpacken. Das jmod Verzeichnis vom muss dann mit angegeben werden (--module-path).
Ein Problem, das aber auftritt, ist: Unter Windows werden die Unix Rechte nicht gesetzt. Wenn Du also unter Windows etwas für Mac oder Unix baust, dann funktioniert das Image erst einmal nicht, da die Execute Rechte fehlen. (Das übliche Problem halt. Das gibt es auch beim Gradle Wrapper wenn man diesen unter Windows hinzu fügt. gradlew hat dann nicht das Ausführ-Recht). Hier wäre mein Ratschlag, dass man dies eben nicht unter Windows macht sondern unter Linux (WSL2).

Somit kann man das JLink Ergebnis schon einmal für andere Plattformen bereit stellen.
Jpackage selbst habe ich bisher nicht ausprobiert und habe da noch keine wirklichen Erfahrungen. Ich selbst baue bisher immer auch auf dem Zielsystem selbst.

 

[kneitzel]

Da mich das jetzt etwas interessiert hat, habe ich noch etwas herum gespielt:
Meine Versuche mit Hilfe des jlink Plugins mehrere Images zu bauen, sind leider unter Windows fehlgeschlagen. Er konnte die jmods der anderen Plattformen nicht lesen ...

Mein Versuch beinhaltete:

jlink {
    targetPlatform("win", "c:/tmp/other-jdk/jdk-win-15.0.1")
    targetPlatform("linux-x64", "c:/tmp/other-jdk/jdk-linux-15.0.1")
    targetPlatform("mac", "c:/tmp/other-jdk/jdk-mac-15.0.1/Contents/Home")
    launcher {
        name = 'SwingExample'
    }
}

Aber er stieg immer aus, dass er das Modul nicht lesen konnte:
Error: Error reading module: c:\tmp\other-jdk\jdk-linux-15.0.1\jmods\java.base.jmod

Das Modul ist aber natürlich da gewesen:

C:\Projects\SwingExample>dir c:\tmp\other-jdk\jdk-linux-15.0.1\jmods\java.base.jmod
 Volume in drive C has no label.
 Volume Serial Number is 847E-0C11

 Directory of c:\tmp\other-jdk\jdk-linux-15.0.1\jmods

22.10.2020  21:12        21.817.735 java.base.jmod
               1 File(s)     21.817.735 bytes
               0 Dir(s)  314.448.572.416 bytes free

C:\Projects\SwingExample>

Im Augenblick habe ich da keinen weiteren Ansatz muss ich gestehen ....

Und da ich den JPackage Ansatz für mich als wichtig ansehe, ist der Ansatz auch nicht wirklich Zielführend. Denn spätestens an dem Punkt würde es beim Cross-Build nicht weiter gehen:
JEP 343 Non-goals (https://openjdk.java.net/jeps/343#Non-Goals):
"There will be no support for cross compilation. For example, in order to create Windows packages one must run the tool on Windows. The packaging tool will depend upon platform-specific tools."

Es gibt teilweise Hinweise, dass Leute das mit Containern hin bekommen haben. Also für alle Plattformen ein Container haben.
(MacOS läuft auch im Container: https://www.ifun.de/docker-osx-stellt-macos-als-docker-container-bereit-155203/)

Das wäre für mich der vielversprechendere Ansatz um zu den Images zu kommen.

 

[kneitzel]

Oh nee ... Fehler gefunden. Ich hatte noch mein JAVA_HOME auf einem 11er JDK, daher hat gradlew das 11er JLink genommen und das kann natürlich nicht mit 15er jmods umgehen....

JAVA_HOME umgesetzt und schwups:
- gradlew jlink läuft durch.
- in build/image have ich SwingExample-linux-x64, SwingExample-mac, SwingExample-win

Damit habe ich dann aber noch nicht die Binaries, die ich gerne hätte. Jpackage bietet dieses cross Plattform nicht.

Daher wird die Lösung tatsächlich auf Docker hinauslaufen, diese targetPlatform Elemente verschwinden wieder und dann läuft in jedem Container einfach das gradle Ziel jpackageimage.

Also kurz die Zusammenfassung der Schritte:
a) JDKs für die Plattformen herunter geladen (ZIP/tar.gz) und entpackt in c:\tmp incl. umbenennen des Verzeichnisses.
b) targetPlatform Angaben (siehe #5) gesetzt. (Das jlink Plugin unterstützt auch die Angabe von download URLs für die JDKs. Dann lädt das auch selbst die JDKs herunter.)