JAG3Dv20190908 (OpenJDK12 + JavaFX12) - Java·Applied·Geodesy·3D

Hallo,

ich habe nun mal für Windows, Linux und MacOS jeweils ein Paket erstellt, welches OpenJDK und JavaFX jeweils in der aktuellen Version 12 enthält. Die Windows Version entspricht der früheren Portable-Version und sollte daher problemlos laufen. Die Linux Version habe ich unter Ubuntu 19.04 ausprobiert mit dem beigefügten shell-Script (hier muss zuvor jag3d.sh und ./openjdk/bin/java ausführbar gemacht werden - chmod +x ...). Ungetestet ist die Version für MacOS, da ich hier keine VM zum Testen habe. Aus diesem Grund habe ich die Version mal als pre-release gelabelled.

Download JAG3Dv20190908 (OpenJDK12 + JavaFX12)

Pierre, kannst Du diese Version mal testen und mir sagen, ob die bei Dir läuft und ob mein Shell-Script korrekt ist (sofern man auch hier die Ausführbarkeit hergestellt hat).

Generelle Frage ist natürlich: Ist eine solche Version für alle drei Plattformen tatsächlich nötig oder kann man bspw. bei Linux-Anwendern voraussetzen, dass sie Java auch selbst installiert bekommen und dadurch kein Mehrwert entsteht? Bei der Diskussion mit gf hatte ich teilweise das Gefühl, dass es eher unnötig sei. Ein Nachteil ist sicher die Größe des ZIP-Paketes.

Vielen Dank für Eure Mithilfe.
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Tags:
JAG3D, openjdk, JavaFX12, v20190908

Download JAG3Dv20190908 (OpenJDK12 + JavaFX12)

Hallo Micha, funktioniert bei mir auf Ubuntu 18.04.

Das Start-Scipt würde ich wie folgt ändern, dass man es auch aufrufen kann, wenn man nicht im Verzeichnis steht (und die Quotes stellen sicher, dass es auch mit Leerzeichen im Pfadnamen funktioniert).

#!/bin/sh
JAG3D_HOME=`dirname "$0"`
"$JAG3D_HOME/openjdk/bin/java" -jar -Xms200m -Xmx500m "$JAG3D_HOME/jag3d.jar"

Wozu war 12>/dev/null gedacht?
Meintest Du >/dev/null 2>&1 ?

Generelle Frage ist natürlich: Ist eine solche Version für alle drei Plattformen tatsächlich nötig oder kann man bspw. bei Linux-Anwendern voraussetzen, dass sie Java auch selbst installiert bekommen und dadurch kein Mehrwert entsteht? Bei der Diskussion mit gf hatte ich teilweise das Gefühl, dass es eher unnötig sei. Ein Nachteil ist sicher die Größe des ZIP-Paketes.

Bei Linux kann man ohnehin nur alles falsch machen, egal wie man es macht.

Ubuntu stellt offenbar openjdk und openjfx Pakete bereit, die man einfach nur mit apt-get install installieren braucht. Diese sind auch für die jeweilige Distribution übersetzt und passen daher dazu. Allerdings wird pro Ubuntu-Version nur eine bestimmte openjdk/openjfx-Version unterstützt: 18.04 => 11, 19.04 => 12, 20.04 => 13 (?). D.h. mit einer 18.04 LTS Installation wäre man für die nächsten 5+5 Jahre - solange 18.04 supported wird - auf openjdk/openjfx 11 festgelegt :-(

Die binären Linux-Builds von openjdk und openjfx, die man 'runterladen kann, wurden - so wie ich das verstehe - auf einem Oracle-Linux 7 übersetzt. Es ist daher zu erwarten, dass sie auf einem Oracle-Linux 7 laufen, wenn man alle erforderlichen Prerequisite-Pakete installiert hat. Ob die Binaries auf anderen Linux-Distributionen und deren verschiedenen Versionen laufen (vor allem auf älteren), wird jedoch nicht garantiert. Es existieren einfach sehr viele Abhängigkeiten zu 3rd-Party-Produkten/Paketen. Da hilft nur ausprobieren... (-> auf Ubuntu 18.04 und 19.04 scheinen die Binärpakete von Oracle ja dennoch zu funktioneren).

Btw, im Gegensatz zu Ubuntu habe ich für Oracle-Linux 7 ebenfalls ein openjdk 11 RPM-Paket gefunden, nicht jedoch ein openjfx-Paket. D.h. wenn man openjfx haben möchte, muss man es selbst auf Oracle Linux offenbar ohnehin "zu Fuß" installieren. Wie es bei anderen Distros ausssieht, weiß ich nicht.

Anders als bei Linux haben die Windows-Builds von openjdk und openjfx nur Abhängigkeiten zu Windows selbst, nicht jedoch zu externen 3rd-Party-Pridukten/Paketen (und die wenigen noch benötigen 3rd-Party-DLLs wie z.B. freetype sind direkt im openjdk-Archiv enthalten). Damit ist es natürlich einfacher, die Funktionsfähigkeit der openjdk/openjfx-Binaries unter Windows sicherzustellen, als die Funktionsfähigkeit auf einem beliebigen Linux.

Viele Grüße
gf

Hallo,

Das Start-Scipt würde ich wie folgt ändern

Werde ich 1 zu 1 übernehmen. Danke für die Verbesserung!

Meintest Du >/dev/null 2>&1 ?

Stimmt, so sah das aus ;-) Ich werde dennoch drauf verzichten. Die Fehlermeldungen soll der Anwender sehen und sie hier auch posten können.

Bei Linux kann man ohnehin nur alles falsch machen, egal wie man es macht.

Das sind natürlich keine guten nach Nachrichten. Welche Variante würde Dir die Arbeit erleichtern?

Allerdings wird pro Ubuntu-Version nur eine bestimmte openjdk/openjfx-Version unterstützt: 18.04 => 11, 19.04 => 12, 20.04 => 13 (?). D.h. mit einer 18.04 LTS Installation wäre man für die nächsten 5+5 Jahre - solange 18.04 supported wird - auf openjdk/openjfx 11 festgelegt

Ja, das Problem besteht natürlich bei den LTS-Versionen immer. Dennoch könnte man auch hier sicher schon neuere Pakete installieren - allerdings nicht aus dem vorgesehenen Repository.
Insbesondere den Drag & Drop Fehler bekommt man so nicht behoben, da dieser wohl erst in Version 13 gefixt wird (außer mit dem Workaround).

Ob die Binaries auf anderen Linux-Distributionen und deren verschiedenen Versionen laufen (vor allem auf älteren), wird jedoch nicht garantiert.

Ja, dass stimmt. Aber dies kann ich für Windows auch schon nicht mehr, da es keine (offiziellen) 32 bit SDKs mehr gibt. Für Linux habe ich noch CentOS geprüft. Auch hier gabs keine Probleme.

Es bleibt die Frage, ob es Sinn macht. Für JavaFX selbst sehe ich den Mehrwert schon. Bleibt die Frage nach dem SDK - rein oder raus?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Tags:
javafx, linux, openjdk, ubuntu, CentOS

Hallo Micha,

Die Fehlermeldungen soll der Anwender sehen und sie hier auch posten können.

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

Welche Variante würde Dir die Arbeit erleichtern?

Mir persönlich ist das egal. Ich kann mir das openjdk und openjfx auch selbst runterladen. Und wenn es nicht läuft installiere ich mir notfalls auch eine VM mit passendem Linux und passenden Prerequisite-Paketen.

Die Frage ist IMO, was will/braucht der DAU, der kein IT-Mann ist, und der auch nichts mit Java am Hut hat? 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.

Diese Anforderung deckt Dein letztes Paket mit inkludiertem openjdk und openjfx sicher am besten ab. Das Archiv sollte jedoch unter Linux kein "normales" .zip sein, weil die Dateizugriffsrechte dort verloren gehen. Es gibt wohl Zip-Varianten, die die Rechte mit einpacken können, bin mir aber nicht sicher, ob unzip unter Linux diese Archive dann auspacken kann. Bessere Alternative wäre m.E. der gute alte Tar, mit gzip-, bzip2- oder xz-Komprimierung (wobei xz auf älteren Systemen eventuell noch nicht unterstützt wird). Nachteil ist halt die Größe - nach dem Auspacken sind ~450MB belegt.

Ich wollte auch nochmals wissen, wie es mit der Lauffähigkeit auf älteren Linux-Versionen aussieht und habe mir dazu in einer VM ein 7 Jahre altes Ubuntu 12.04 LTS installiert (das 2017 End of Maintenance hatte). Ldd hat dort zwar diverse Bibliotheken nicht gefunden, die von java und javafx referenziert werden, dennoch ließ sich JAG3D starten, weil Du offenbar die ganzen Multimedia/Video/Sound/... Funktionen von javafx nicht benutzt (diese hätten wohl nicht mehr funktioniert). Dass es sich starten ließ, ist m.E. aber ein gutes Zeichen ;-)

Viele Grüße
gf

Guten morgen gf,

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

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi Micha,

vielen Dank für die Umsetzung der neuen Funktionen, probiere ich, sobald Zeit vorhanden natürlich direkt mal aus. :-)

Ich schaue mir das auf MacOS an, dass dauert aber ein paar Tage.

Viele Grüße
Pierre

Hi Pierre,

Dank für Deine Mithilfe. Ich habe inzwischen eine virtuelle Maschine erstellt aber die funktioniert nicht korrekt, sodass ich es nicht testen kann. Ferner erscheint mir der Ausdruck "migrieren" besser geeignet als "integrieren". Das muss ich also in jedem Fall abändern. Sollte es unter MacOS laufen, bliebe auch hier die Frage, ob es einen Vorteil hat gegenüber der Variante ohne OpenJDK.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,

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

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi 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

Hi,

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

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo,

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

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Tags:
JAG3D, OpenJDK, JavaFX, JAG3Dv20190929

RSS Feed of thread