Kompatibilität mit neueren Java-Versionen herstellen (>15)

[freggeldoe]

versuchte Nutzung auf Java 16 unter Arch Linux wirft Fehler aufgrund verwendeter "preview features":

Fehler: Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten
        java.lang.UnsupportedClassVersionError: mediathek/Main (class file version 59.65535) was compiled with preview features that are unsupported. This version of the Java Runtime only recognizes preview features for class file version 60.65535

[derreisende77]

13.7.1 verwendet java 15. der develop branch hier für 13.8 ist für java 16. Alternativ von der Website ein nightly laden.

[derreisende77]

Es wird in 13.8 behoben sein

[freggeldoe]

Alternativ von der Website ein nightly laden.

Danke, das funktioniert vorerst für meine Zwecke.

[dvzrv]

Hi! Ich package mediathekview fuer Arch Linux.

Da es derzeit nicht moeglich ist fuer Nutzer die das Paket auf einem neuen System installieren (die java runtime 15 wurde aufgrund von EOL schon aus den repositories entfernt) dieses auch zu nutzen, wollte ich mich erkundigen ob ein release schon absehbar ist, oder ob und welche commits genutzt werden koennen oder muessen um die Kompatibilitaet mit java runtime 16 herzustellen.

[derreisende77]

Die Änderungen für 16 mit 13.7.1 sind immens. Das sollte nicht ganz so einfach sein. Ich versuche in den nächsten 3 Wochen zu releasen. 13.8 ist quasi fertig, es gibt derzeit "nur" einen showstopper mit exceptions unter legacy windows 32 bit die ich fixen muss.

[Markus-N]

Nur so als Idee ...
Sofern ich richtig informiert bin, wird Java 17 wieder ein LTS-Release sein.

Spricht irgendwas dagegen, ab Java 17 nur noch LTS-Releases als Basis zu benutzen ?

Solche Probleme wären damit gelöst - zumindest bei Arch Linux. Da gibt es die LTS-Java's (sowie das jeweils zugehörige JavaFX) als Pakete, die man parallel zum jeweils neuesten Java installieren kann.

[derreisende77]

Jupp, aber solange Oracle bzw die community in den jeweiligen Releases Sachen fixed (oder erstmalig Features für den weiteren Betrieb auf Plattformen bereitstellt) die vorher Auswirkungen auf die App hatten wird auch wieder über die LTS gesprungen werden. Alles hat seine Vor- und Nachteile und ich bin mir nicht sicher ob die jetzt angelegte Geschwindigkeit gut für Java ist.

[Markus-N]

Den Teil in Klammern habe ich nicht so ganz kapiert :-)

Ich bin jetzt davon ausgegangen, dass es zum Job der LTS Versionen gehört, neben Security-Fixes auch die grundsätzliche Lauffähigkeit auf allen unterstützten Plattformen zu erhalten.

Demnach müsste man den LTS-Pfad nur verlassen, wenn man schicke neue fancy features unbedingt haben will.
Das ist natürlich Geschmackssache, aber aus User-Sicht wäre mir wichtiger, dass es keine längere Ausfallzeit wegen Java-Versions-Inkompatibilitäten gibt.

Und wie sich in diesem Fall herausgestellt hat, sind insbesondere die preview features ein ganz heißes Eisen, dass man nur mit der Kneifzange anfassen sollte - oder noch besser gleich komplett links liegenlassen.

Ich finde übrigens das UI super so wie es jetzt ist, d.h. ich sehen keinen Grund, nach Java 17 noch von LTS abzuweichen. :-)
Auch nicht eventuelle neue Sprach-Features, mit denen irgendwas eleganter gelöst werden kann. Es reicht, dass es tut. :-)

[derreisende77]

Preview features werden zukünftig eher nicht mehr verwendet werden, das haben wir auch erst zu spät bemerkt wie bescheiden das ist. User-Sicht ist das eine, das andere ist die Lauffähigkeit zu gewähren. Da gibt es abseits von Linux durchaus manchmal Handlungsbedarf ;)

[dvzrv]

Kann dieses Ticket wieder geoeffnet werden? Eine neue Version, die dieses Problem addressiert ist ja noch nicht released.

Ich bekomme eine Menge E-Mails von Nutzern, die mediathekview nun nicht mehr nutzen koennen aufgrund der Inkompatibilitaet und frage mich derzeit was ich als Packager tun kann, da ich keine EOL Java Version in die Repos bringen werde, um ein einzelnes Paket am Laufen zu halten (ich maintaine ueber 700 Pakete und hab dafuer keine Zeit).

Ist es moeglich eine pre-release Version zu machen? Die kann ich dann wenigstens als Paket anbieten, bis die restlichen Probleme zum naechsten Release behoben sind.

[derreisende77]

@Nicklas2751 Bitte wirf einen Blick auf das 32 bit windows Problem mit.

@dvzrv Kannst Du ggf eine 13.8 Version releasen mit einem nightly build als Grundlage und das im späteren Verlauf durch das „offizielle“ 13.8 ersetzen?

[dvzrv]

@derreisende77 Ich kann eine prerelease version anhand eines git tags bauen, siehe: https://wiki.archlinux.org/title/VCS_package_guidelines#Git (das waere dann z.b. 13.7.1.r123.<commit>)

Ich braeuchte nur einen commit, den ihr als funktional erachtet.

[derreisende77]

Wenn der Test mit der heutigen Nightly erfolgreich ist unter win32 dann werden wir 13.8 voraussichtlich Montag releasen. Ich denke ich habe alle 32 bit Probleme nun beheben können während der Tests.

[gruenkaeppchen]

War der Test nicht erfolgreich ?!

[fred0r]

lustig - wollte auch grad fragen

[derreisende77]

Die Mac-Version wurde heute von Apple notarisiert und an den Admin weitergeleitet für das Release. Sollte also zeitnah erscheinen.

[derreisende77]

13.8 wurde released