ich habe eine neue Version von JAG3D erstellt. Diese enthalten das kürzlich veröffentlichte JavaFX 13, sodass die Probleme unter Ubuntu obsolet sein sollten. Für Windows ist zusätzlich OpenJDK 13 mit dabei, die anderen Plattformen müssten Java selbst bereitstellen.

/Micha

Mein Vorschlage wäre, für Linux und macOS JAG3D nur mit javafx anzubieten und für die Windows-User das komplette Out-of-the-Box-Paket als Portable-Version.

Okay, danke für Deine Einschätzung. Das entspricht letztlich auch der Intension von gf - insbesondere was die Abhängigkeiten betrifft. Dann würde ich es so machen, und nur der Windows-Version das SDK beilegen.

würde ich das Skript so aufbauen:

#!/bin/bash
cd $(dirname "$0")
"openjdk/Home/bin/java" -jar -Xms200m -Xmx500m jag3d.jar

Okay, dass gehlaten wir mal hier als Demo. Wenn das SDK nicht dabei ist, muss es auch kein Script hierfür geben.

Nachteil das Fenster der Konsole bleibt offen und muss nachher noch geschlossen werden.

Unter Linux gibts hierfür nohup, um die Shellinstanz unabhängig von der Applikationsinstanz zu starten.

Viele Grüße
Micha

ich habe mal bewusst auf einer schon sehr betagten OS X Version (10.11) von 2015 getestet. Aktuell ist macOS 10.15 ... Auf dem Rechner ist keinerlei Java-Runtime etc. vorhanden. Beim direkten Aufruf (aus dem JAG3D-Verzeichnis) über das Terminal/Konsole mit manueller Eingabe von "openjdk/Home/bin/java" -jar -Xms200m -Xmx500m jag3d.jar startet JAG3D problemlos.

Beim Start über das Skript aus der command-Datei scheint der Pfad nicht korrekt zu sein. Hier bekomme ich auf der Konsole:
line 3: ./openjdk/Home/bin/java: No such file or directory

Ändere ich hier die die zweite Zeile zu:
JAG3D_HOME="$(dirname "$BASH_SOURCE")"
scheint das eine Problem gelöst zu sein, dennoch erhalte ich eine Fehlermeldung:
Error: Unable to access jarfile jag3d.jar

Nach ein wenig länger rumprobieren und lesen, als ich es eigentlich vorhatte, würde ich das Skript so aufbauen:
#!/bin/bash
cd $(dirname "$0")
"openjdk/Home/bin/java" -jar -Xms200m -Xmx500m jag3d.jar
dann startet JAG3D unabhängig vom Pfad per Doppelklick auf die command. Nachteil das Fenster der Konsole bleibt offen und muss nachher noch geschlossen werden. Hier gibt es ganz sicher einen deutlich eleganteren Weg bspw. über AppleScript, dafür fehlt mir aber jetzt die Zeit.

Zur Gretchen-Frage: Wenn jemand in der Lage ist sich Java selbst zu installieren und sich dazu ein passendes Shell-Skript zum Start zu schreiben, dann sicher die Linux-Anwender. Bei Mac sehe ich das zumindest ähnlich, da ist die Installation der Java JDK von Oracle einfach und openjdk nun auch nicht wirklich kompliziert.

Mein Vorschlage wäre, für Linux und macOS JAG3D nur mit javafx anzubieten und für die Windows-User das komplette Out-of-the-Box-Paket als Portable-Version.

Viele Grüße
Pierre

in Anlehnung an gfs Script würde ich ggf. das shell-Script so aufbauen:

#! /bin/bash
JAG3D_HOME="$(dirname "BASH_SOURCE")";
"$JAG3D_HOME/openjdk/Home/bin/java" -jar -Xms200m -Xmx500m jag3d.jar

Vielleicht geht dies ja noch besser.

Viele Grüße
Micha

Ich jedenfalls würde sie gerne sehen, wenn welche kommen.

Der Stacktrace von den geworfenen Exceptions sollten alle zum Anwender durchgereicht werden.

Der will vermutlich einfach ein File 'runterladen und starten, ohne sich groß Gedanken zu machen, was er sonst noch braucht, und wie er es zum Laufen bekommt.

Ja, dass denke ich auch. Für jemanden wie Dich, der gern die Installationen aus dem Repository nutzen will, ergibt sich kein Nachteil. Wenn Du bspw. den SDK-Ordner löscht, wird automatisch Deine installierte Java-Version verwendet.

Das Archiv sollte jedoch unter Linux kein "normales" .zip sein, weil die Dateizugriffsrechte dort verloren gehen.

Interessanter Punkt, Danke für den Hinweis. Ich entwickle auf einem Windows System, wodurch Dateirechte keine Rolle spielen (zumindest in den meisten Verzeichnissen). Ubuntu als Testumgebung lasse ich in einer VM laufen. Dort kann ich die Rechte schnell setzen. Ich vermute, ich müsste den TAR (und eine Komprimierung von diesem) dann wohl direkt unter Ubuntu erzeugen.

Nachteil ist halt die Größe - nach dem Auspacken sind ~450MB belegt.

Ja, das stimmt. Als FX noch Teil des SDK war (also bis Java 9), war es auch kein Problem. Der Anwender sollte Java in einer Version XY mind. haben und gut. Nachdem Oracle aber das SDK lieber etwas schlanker haben will und viele wesentliche Libs entfernt hat, fühlt es sich an, als hätten sie ein Problem auf die Nutzer übertragen. Kurzum: Mit der Größe und der plattformspezifischen Bereitstellung von Versionen bin ich mehr als unglücklich.

Ich wollte auch nochmals wissen, wie es mit der Lauffähigkeit auf älteren Linux-Versionen aussieht [...] Dass es sich starten ließ, ist m.E. aber ein gutes Zeichen

Danke für diesen Test. Gut zu wissen, dass es dort auch funktionieren würde.

Besten Dank für Deine Einschätzung.
Micha