# Ist LibGDX bei der aktuellen Oracle-Strategie noch die richtige Wahl?



## vulcanus (28. Mai 2018)

Hi Zusammen,


beruflich bin ich nun seit ca. sieben Jahren mit Java beschäftigt (hauptsächlich Backend + Swing). Zeit für was „Neues“. Geht hierbei zunächst nur um ein kleines privates Projekt. Im Bereich 2D-Spieleentwicklung gibt dazu ja einige Frameworks/Engines, die alle ihre Vor- und Nachteile haben. Da ich Java als die Sprache bezeichnen würde, mit der ich mit Abstand am meisten Erfahrung habe, liegt libGDX natürlich recht nahe. Allerdings beschäftigen mich zwei Ding:


1.   Die aktuelle Oracle-Politik: Gefühlt schmeißen die grad alles raus, was kein Geld bringen (JavaEE/Swing/JavaFX/Webstart…). Wenn die entsprechende Community nicht aktiv weiterarbeitet, stirbt das Modul. Dazu kommt, dass sie jedes halbe Jahr eine neue Version rausbringen wollen. Meine Befürchtung ist, dass LibGDX (und deren Abhängigkeiten) irgendwann nicht mehr kompatibel mit der aktuellen Java-Version sein wird, bzw. die Entwickler nicht mehr hinterherkommen. Was dann? Stirbt LibGDX damit? Oder sehen hier etwas falsch oder zu schwarz?

2.   Um das Problem verschiedener Java-Versionen aus dem Weg zu gehen, würde ich wohl mit einer Bundled-JRE arbeiten. Wirst ihr, wie hier die rechtlichen Gegebenheiten sind? Muss ich dafür eine Lizenzgebühr zahlen? (OK, dieser Punkt ist Zukunftsmusik, aber er beschäftigt mich bei der Wahl des richtigen Frameworks)


Java und LibGDX haben halt den Scharm, dass mir zumindest ein Teil bekannt vorkommt. Bei Unity z.B. wäre zusätzlich zur Spieleprogrammierung auch die Sprache und die GUI ungewohnt.


Ich gehe davon aus, dass ich schon ein paar Jahre investieren muss, bis etwas Verwertbares hinten rausfällt. Deshalb die aktuellen Gedanken.


Merci fürs lesen und antworten


----------



## httpdigest (28. Mai 2018)

Zu Punkt 1.: libGDX verwendet keines der in dem JRE (in welcher Version auch immer) enthaltenen Desktop-Frameworks. Als Backend für die Desktop-Plattform kommt LWJGL zum Einsatz. Dieses benutzt seit Version 3 GLFW für das OS Window- und OpenGL-Context Management.
Zu Punkt 2.: Du kannst das OpenJDK jederzeit bundled frei und kostenlos ausliefern. Du darfst das OpenJDK nur nicht mit dem Oracle JDK verwechseln.

Das heißt, LibGDX selbst ist schon so geschrieben, dass es sehr wenige Abhängigkeiten zum JRE selbst besitzt - LibGDX ist ja für Multiplattformentwicklung gedacht, also für Android, iOS, Windows/Linux/macOS (unter "Desktop" zusammengefasst) sowie Web/Browser.
Nichtsdestotrotz wirst du sowieso - wie du ja schon sagtest - mit einem bundled JRE arbeiten. Du kannst ja auch nicht davon ausgehen, dass auf dem Zielrechner überhaupt Java installiert sein wird und willst das natürlich auch nicht als systemweite Installation mit deinem Spiel mitinstallieren.
Zur Not kannst du also noch seeeeeehr lange auf OpenJDK 8 deine Spiele basieren. Du wirst dadurch sicherlich keinerlei Nachteile haben.


----------



## vulcanus (28. Mai 2018)

Hi,

zunächst mal Danke für die schnelle Antwort!

Zu 1. : Java EE, Swing etc. waren nur Beispiele, weil sie aus beruflichen Gründen gerade sehr aktuell für mich sind. Wenn ansonsten keine anderen Abhängigkeiten zu anderen Frameworks/Bibliotheken etc existieren, die durch die neue Oracle-Politik Probleme machen könnten, bin ich zufrieden ^^.

Zu 2. Wird die Kombi OpenJDK und LibGDX denn üblicherweise eingesetzt? Hab dazu noch nicht so viel gefunden. Und auch Windows + OpenJDK hatte ich bisher noch nicht ausprobiert. Funktioniert das gut oder sollte man da lieber auf ein Linux OS umsteigen? Wäre für mich jetzt auch kein Beinbruch.

Dankeschön

--- Danke für den Nachschlag ;-)

Auf sicherheitsrelevante Dinge braucht man nicht zu achten, wenn man eine "veralterte" JDK benutzt?


----------



## httpdigest (28. Mai 2018)

Ich schlage vor, du startest einfach mal mit: https://github.com/libgdx/libgdx/wiki/Project-Setup-Gradle
und arbeitest dich dann Schritt für Schritt vor. Du kannst z.B. mittels https://github.com/libgdx/packr auch eine beliebige JAR Datei zusammen mit einem JRE für jede beliebige Desktop-Plattform paketieren lassen. Das wird auch vom libGDX Buildprozess selbst verwendet, soweit ich weiß.
Mach dir keine Sorgen. LibGDX wird nicht erst von 2 Leuten verwendet, um Spiele zu entwickeln. Jedes Problem, was du eventuell einmal haben wirst, wird sicherlich schon von einer Million anderer Leute gelöst worden sein und auf den einschlägigen Seiten (StackOverflow, GitHub Issues, ...) durchsuchbar sein.
Bezüglich Sicherheit: Du benutzt LibGDX ja nicht, um langläufige Serverprozesse zu entwickeln, die Tür und Tor zum Internet offen haben, sondern nur für lokale Desktopanwendungen. Wenn du irgendwann einmal bei Multiplayer-Entwicklung angekommen bist, würde ich sowieso einen separaten Serverprozess mit dem allerneuesten JDK benutzen. Die meisten "Sicherheitslücken", die mit JRE Updates gefixt werden, basieren sowieso auf alten, nicht mehr vertrauenswürdigen SSL-Zertifikaten (deren Algorithmen entweder als unsicher eingestuft wurden, oder deren Zertifikate kompromitiert wurden und somit entfernt werden müssen). Damit hast du absolut nichts am Hut, da du dich ja sicherlich nicht per SSL mit "irgendeinem" Server verbinden wirst.


----------



## httpdigest (28. Mai 2018)

Aber insgesamt kann ich sagen: Ich bin schon lange Mitglied auf java-gaming.org und auch auf forum.lwjgl.org und habe die Entwicklung von vielen Mitgliedern und ihren Spielen mitverfolgen können. Wenn jemand viele Fragen und Bedenken wie du am Anfang äußert, ist die Wahrscheinlichkeit hoch, dass er oder sie der "Analysis Paralysis" verfallen ist und dann vermutlich nie überhaupt erst anfangen wird, ein Spiel zu entwickeln. Die geäußerten Bedenken kommen dann eher aus dem Unterbewusstsein, das dich davon abhalten möchte, überhaupt erst Energie in die Spieleentwicklung zu stecken. "Einfach anfangen, in kleinen Schritten ausprobieren und mittels kleiner Erfolge Motivation und Sicherheit gewinnen" ist hier die Devise. Nicht gleich versuchen, alle möglichen Probleme am Anfang zu sehen, denn die kann man immer lösen, wenn sie auftreten.


----------



## Flown (28. Mai 2018)

vulcanus hat gesagt.:


> 1. Die aktuelle Oracle-Politik: Gefühlt schmeißen die grad alles raus, was kein Geld bringen (JavaEE/Swing/JavaFX/Webstart…). Wenn die entsprechende Community nicht aktiv weiterarbeitet, stirbt das Modul. Dazu kommt, dass sie jedes halbe Jahr eine neue Version rausbringen wollen. Meine Befürchtung ist, dass LibGDX (und deren Abhängigkeiten) irgendwann nicht mehr kompatibel mit der aktuellen Java-Version sein wird, bzw. die Entwickler nicht mehr hinterherkommen. Was dann? Stirbt LibGDX damit? Oder sehen hier etwas falsch oder zu schwarz?


Zu JavaEE: Heißt jetzt JakartaEE und wird jetzt von der Eclipse Foundation weiterentwickelt in einem Open-Source Prozess, mit exakt den gleichen Leuten die auch schon bei JavaEE mitgearbeitet (Oracle, Redhat, IBM, Intel, ...) haben und diesen JCP nicht mehr durchleben müssen. Das hat den Vorteil die Firmenpolitiken beiseite zu schaffen und die Entwicklung schneller voranzutreiben.

Zu Swing: Wird schon lange nicht mehr weiterentwickelt und ist nur aus legacy Gründen noch drinnen, weil doch einiges darauf basiert.

Zu JavaFX: Ist der natürliche Nachfolger von Swing und ist ausgegliedert worden, damit es in einem eigenen Releasezyklus arbeiten kann. Somit ist man nicht an die JDK Releases gebunden (wird aber fast im selben Repository entwickelt).

Zu Webstart: Ist und bleibt nur eine OracleJDK Erscheinung und kann für OpenJDK via IcedTea (sozusagen als Plug-In) nachgeladen werden.

Die Angst das irgendwas nicht mehr läuft ist unbegründet. Wenn du hier unabhängig sein möchtest, dann lieferst du deinen eigene Java Version einfach mit dazu und fertig.


vulcanus hat gesagt.:


> 2. Um das Problem verschiedener Java-Versionen aus dem Weg zu gehen, würde ich wohl mit einer Bundled-JRE arbeiten. Wirst ihr, wie hier die rechtlichen Gegebenheiten sind? Muss ich dafür eine Lizenzgebühr zahlen? (OK, dieser Punkt ist Zukunftsmusik, aber er beschäftigt mich bei der Wahl des richtigen Frameworks)


Alles ist frei für deine Nutzung, außer du verwendest die Commercial Features - die du auch extra aktivieren musst - für OracleJDK. Sonst gibt es hier nichts zu bedenken.


----------



## JuKu (30. Mai 2018)

vulcanus hat gesagt.:


> 1.   Die aktuelle Oracle-Politik: Gefühlt schmeißen die grad alles raus, was kein Geld bringen (JavaEE/Swing/JavaFX/Webstart…). Wenn die entsprechende Community nicht aktiv weiterarbeitet, stirbt das Modul. Dazu kommt, dass sie jedes halbe Jahr eine neue Version rausbringen wollen. Meine Befürchtung ist, dass LibGDX (und deren Abhängigkeiten) irgendwann nicht mehr kompatibel mit der aktuellen Java-Version sein wird, bzw. die Entwickler nicht mehr hinterherkommen. Was dann? Stirbt LibGDX damit? Oder sehen hier etwas falsch oder zu schwarz?



Wie bereits erwähnte wurde ist libGDX völlig unabhängig vom JRE.
Ich muss zwar zugeben, dass es unter Java 9 (dank des Modulsystems) einige Schwierigkeiten gegeben hat (genauer gesagt in LWJGL3), diese aber mittlerweile ausgeräumt wurden. Und man kann nicht davon ausgehen, dass das Java EC ständig solche inkompatiblen Versionen absegnen wird, Jigsaw war das größte Feature dieser Art und dieses musste sogar nachgebessert werden, weil der EC dieses eben nicht so durchgehen ließ.
Vertrau einfach den Leuten vom JCP, die wissen schon, was sie tun. 

Bezüglich der anderen Libraries:
Swing ist - wie oben bereits erwähnte wurde - schon lange deprecated und sollte eig. nicht mehr verwendet werden. Der Nachfolger ist und bleibt JavaFX, auch wenn sich Oracle lange nicht dazu bekannt hat. Im Zuge der Modularisierung hat man versucht alles unnötige aus dem JRE auszugliedern, um das JRE selbst kleiner zu halten (was gerade für Embedded Systems praktisch ist). Abgesehen von Swing & Webstart gibt es aber meines Wissens keine Libraries, die Oracle direkt abgesetzt hat. Alles andere wird ja von der Community weiterentwickelt.

Da die libGDX Maintainer desweiteren (meines Wissens) auch aus der Games Branche kommen und libGDX für ihre eigenen kommerziellen Projekte einsetzen (z.B. für Pathway, Webseite), ist es auch in ihrem Interesse, dass libGDX auch weiterhin unter neuen Java Versionen funktioniert. 
Deshalb würde ich mir an deiner Stelle keine Gedanken darüber machen und einfach mal loslegen.


----------



## Schmetterhand (2. Jun 2018)

Mal ganz allgemein: Ich finde diesen schnellen release cycle von Oracle ebenfalls bedenklich, z.B. war Java 9 nicht mehr abwärtskompatibel, während alle anderen Java-Versionen diesen "Standard" bisher hielten. Wie sollen denn die "armen" freiwilligen Programmierer diesen schnellen Veränderungen hinterherkommen (gerade libGDX, aber auch alle anderen)?



httpdigest hat gesagt.:


> Zur Not kannst du also noch seeeeeehr lange auf OpenJDK 8 deine Spiele basieren. Du wirst dadurch sicherlich keinerlei Nachteile haben.


Das stimmt und ist auch vorerst beruhigend, aber man möchte doch allgemein nur ungern auf alte Programmversionen, egal bei was, aufbauen, oder nicht? Meistens kommen irgendwann Bugs, Sicherheitslücken etc. raus, und dann "steht man da" und kann keine neue Version benutzen, weil sie nicht mehr kompatibel ist.

Alles in allem gefällt mir Oracles Strategie nicht. Zum Glück hat Sun damals Java fast komplett ge-OpenSource-ed und somit zukünftigen Konzernen wie Oracle, die Java evtl. closed source machen wollten, den Wind aus den Segeln genommen. 

Gruß


----------



## httpdigest (2. Jun 2018)

Schmetterhand hat gesagt.:


> [...]aber man möchte doch allgemein nur ungern auf alte Programmversionen, egal bei was, aufbauen, oder nicht? Meistens kommen irgendwann Bugs, Sicherheitslücken etc. raus, und dann "steht man da" und kann keine neue Version benutzen, weil sie nicht mehr kompatibel ist.


Ja, das stimmt wohl. Aber, wenn wir im Kontext dieses Threads zu Spieleprogrammierung mit libGDX bleiben und nicht bei egal was, dann ist die Wahrscheinlich dafür, dass Leute überhaupt erstmal ein Spiel _fertig_ bekommen, um viele viele Größenordnungen kleiner als die Wahrscheinlichkeit, dass das Spiel durch eventuelle Sicherheitslücken in dem JRE in irgendeiner Weise beeinflusst wird. Wie gesagt: Man sollte Probleme lösen, wenn sie auftreten und sich zuerst einmal um die eigentliche Entwicklung eines Spiels kümmern. In drei bis vier Jahren, wenn das Spiel dann eventuell fertig ist, sieht die Welt dann eh wieder ganz anders aus.


----------



## mrBrown (2. Jun 2018)

Schmetterhand hat gesagt.:


> Mal ganz allgemein: Ich finde diesen schnellen release cycle von Oracle ebenfalls bedenklich, z.B. war Java 9 nicht mehr abwärtskompatibel, während alle anderen Java-Versionen diesen "Standard" bisher hielten. Wie sollen denn die "armen" freiwilligen Programmierer diesen schnellen Veränderungen hinterherkommen (gerade libGDX, aber auch alle anderen)?



Naja, im wesentlichen musste man nur warten, bis alle relevanten Libs umgestellt waren, das ging mal mehr, mal weniger schnell. Viel mehr als das Anpassen ans Modul-System war meistens aber auch nicht nötig.

Abgesehen davon seh ich das genau andersrum. Der Bruch mit der Abwärtskompatibilität war einfach irgendwann nötig, und er schnellere Zyklus macht es nur leichter.
Jedes halbe Jahr ein paar wenige neue Features sind einfach deutlich leichter zu handhaben, als alle 3, 4, 5 Jahre ein riesiger Berg an Features.




Schmetterhand hat gesagt.:


> Das stimmt und ist auch vorerst beruhigend, aber man möchte doch allgemein nur ungern auf alte Programmversionen, egal bei was, aufbauen, oder nicht? Meistens kommen irgendwann Bugs, Sicherheitslücken etc. raus, und dann "steht man da" und kann keine neue Version benutzen, weil sie nicht mehr kompatibel ist.


Dafür wird es wohl LTS-Versionen geben.
Und wenn es irgendwann Lücken gibt, ist der Umstieg auf eine neuere Version tendenziell leichter geworden, weil eben nur eine begrenzte Anzahl an Features, und nicht riesig viele.


----------

