Läuft nicht unter neuem Java9
-
-
Hallo!
Am Pfad liegt’s nicht, der ist hier auch korrekt.
Jedoch scheint der Launcher Mediathekview.exe unter Windows ein Problem mit der neuen Java-Version zu haben. Meiner Vermutung nach wird der neue Versions-String “java.runtime.version=9+181” nicht korrekt erkannt.Als Workaround funktioniert bei mir der direkte Aufruf der .jar-Datei ohne den Launcher:
Im Programmverzeichnis von Mediathekview:
“java -jar MediathekView.jar”In MediathekView selber wird die Java-Version “9” korrekt angezeigt.
Ich hoffe das hilft bei der Analyse.
Guß,
Michael -
@msunix Das Problem ist ja nicht der Pfad. MV wurde mit Java 8 erstellt und läuft nicht mit Java 9. Daher musst Du parallel Java 8 installieren und dafür sorgen, dass es mit MV verknüpft wird.
-
Hallo!
@MünchenSued:
Du selbst hattest oben den Pfad ins Spiel gebracht.
MV selbst läuft hier problemlos mit Java 9, wenn man es mit o.g. Kommandozeile startet. Lediglich der Launcher möchte unbedingt 1.8.xx haben, daher muss dieser angepasst werden; bis das passiert ist starte ich MV halt über eine eigene kleine Batchdatei, Java 8 werde ich deshalb nicht parallel installieren.NB: Gruß aus München Ost!
Michael
-
@MenchenSued sagte in Läuft nicht unter neuem Java9:
@msunix Das Problem ist ja nicht der Pfad. MV wurde mit Java 8 erstellt und läuft nicht mit Java 9. Daher musst Du parallel Java 8 installieren und dafür sorgen, dass es mit MV verknüpft wird.
Nein, da Java (zum größten Teil) abwärtskompatible ist. Erkennt die JVM das und führt MV richtig aus.
Das hier beschriebene Problem kommt daher, dass Launch4J scheinbar noch ein Problem mit Java 9 hat deshalb geht die Exe nicht. -
@Nicklas2751 sagte in Läuft nicht unter neuem Java9:
Nein, da Java (zum größten Teil) abwärtskompatible ist
Ok, dachte, das wäre so ähnlich wie .NET. Danke für den Hinweis.
-
@nicklas2751 sagte in Läuft nicht unter neuem Java9:
Das hier beschriebene Problem kommt daher, dass Launch4J scheinbar noch ein Problem mit Java 9 hat deshalb geht die Exe nicht.
Verbesserungsvorschlag: Statt für Windows vier exe-Dateien auszuliefern, vier cmd-Dateien (ehemals bat) ausliefern. Darin kann man als Anwender auch leicht zusätzliche Aufrufparameter eintragen. Und die Abhängigkeit von Launch4J entfällt auch noch.
-
@georg-j In zukunft wird hier wahrscheinlich eherl aunch4j eingesetzt und so dem Anwender ein Installer + integrierte JRE angeboten. Ganues steht aber noch nicht.
-
@nicklas2751 Ich rede von dem MV-Aufruf unter Windows nach der Installation, nicht von der Installation selbst.
-
@georg-j sagte: Ich rede von dem MV-Aufruf unter Windows nach der Installation, nicht von der Installation selbst.
Das stimmt, jedoch spricht @Nicklas2751 mit seiner Aussage einen relevanten Punkt an: Viel wichtiger und hilfreicher für eine Mehrheit der (Windows-)User ist es wohl, einen Installer bereitzustellen, als spezielle Startdateien in Form von Cmd-Dateien statt Exe-Dateien zur Verfügung zu stellen.
Um deinen Wünschen gerecht zu werden, bräuchte es weniger 3 Cmd-Dateien, sondern bloss eine, die fortgeschrittene Benutzer mittels Auskommentieren konfigurieren könnten. Und genau das gab es schon, bevor das neuen Team übernommen hat (leider wurde diese Datei “MediathekView__Start.bat” mit Einführung von MV 13 entfernt):
:: Wenn man in den Einstellungen (nicht im Filter!!), das :: Laden der Filmliste auf die letzten 14 Tage reduziert, :: bekommt man eine Filmliste mit weniger als 18.000 :: Einträgen. Damit läßt sich MV leicht mit nur wenig :: Speicher starten, und ohne Einschränkung anwenden. :: Nachdem die Einstellungen geändert wurden, und :: MV neu gestartet wird, versuch es hiermit: :: java -Xms128M -Xmx256M -jar ./MediathekView.jar :: ================================================ :: Das sind verschiedene Möglichkeiten das Programm :: zu starten, die anderen Aufrufe sind auskommentiert :: der Pfad zum Programm "PFAD" muss angepasst werden :: Durch Entfernen des "::" vor einer Zeile wird die Zeile als Befehl interpretiert. :: Durch Schreiben eines "::" zu Beginn einer Zeile wird diese nicht mehr als Befehl interpretiert. :: Start in einer extra Dos-Box die minimiert startet :: Die Parameter "-Xms128M -Xmx1G" helfen bei geringem Arbeitsspeicher. start /min javaw -Xms128m -Xmx1024m -jar "C:\Users\PFAD\MediathekView.jar" :: Start mit mehr Speicher für das Programm :: java -Xms128M -Xmx1G -jar "C:\Users\PFAD\MediathekView.jar" :: Start mit noch mehr Speicher, falls neue Filmliste trotzdem nicht voll geladen werden kann :: java -Xms128M -Xmx1.5G -jar "C:\Users\PFAD\MediathekView.jar :: Start mit Pfad zu Java :: "%path-to-32-Bit-java%\javaw.exe" -Xms128M -Xmx1G -jar "C:\Users\PFAD\MediathekView.jar" :: "Einstellungen/.mediathek3" legt den Ort relativ zur Datei "MediathekView.jar" :: im MV-Programmordner fest. Wer keine portablen Einstellungen verwenden will, :: löscht diese Zeichenfolge. Wer die Programm-Einstellungen zum Beispiel auf das :: Laufwerk D: legen will, kann alternativ einen entsprechenden Pfad angeben, :: z.B. "D:\MediathekView\Einstellungen\.mediathek3". Die Ordner "Einstellungen" bzw. :: "MediathekView" müssen vorhanden sein bzw. zuerst erstellt werden. :: start javaw -Xms128M -Xmx1G -jar MediathekView.jar "Einstellungen\.mediathek3" exit :: Es wird ein Proxyserver verwendet. :: java -jar -Dhttp.proxyHost=proxyserver -Dhttp.proxyPort=8080 "C:\Users\PFAD\MediathekView.jar" :: Der Parameter "-Djava.net.preferIPv4Stack=true", "-Djava.net.preferIPv6Addresses=true" ermöglicht eine :: Verbindung zum Internet, wenn der verwendete Netzwerk-Stack von Java nicht automatisch :: richtig erkannt wird, wodurch die Filmliste nicht geladen werden könnte. :: java -Djava.net.preferIPv4Stack=true -Xms128M -Xmx1G -jar "C:\Users\PFAD\MediathekView.jar" :: java -Djava.net.preferIPv6Addresses=true -Xms128M -Xmx1G -jar "C:\Users\PFAD\MediathekView.jar" :: -Dhttp.proxyHost=proxyserver :: -Dhttp.proxyPort=8080 :: -Djava.net.preferIPv4Stack=true :: -Djava.net.preferIPv6Addresses=true :: -Xms128M :: -Xmx1G :: Weitere Infos können z.B. hier gefunden werden :: https://docs.oracle.com/javase/7/docs/api/java/net/doc-files/net-properties.html :: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html :: http://www.heise.de/developer/artikel/Feintuning-der-Speicherbelegung-von-Java-Programmen-mit-visualgc-227258.html
-
Ein Installer, der seine eigene Java-Version mitbringt, kann dazu führen, dass diese Java-Version beim Benutzer lange nicht aktualisiert wird, weil jener die Anwendung nicht aktualisiert. So läuft bei mir noch ein in Intels “RAID Web Console 2” integriertes Java vom Mai 2014.
Die exe-Dateien würden mit der ausgelieferten Java-Version immer funktionieren, die cmd-Dateien vermutlich sogar mit allen Java-Versionen.
Eine cmd-Datei hatte ich mir selbst erstellt, und ich passe den MV-Aufruf darin von Zeit zu Zeit an den Speicherbedarf meiner wachsenden Filmliste an.
-
@georg-j sagte: So läuft bei mir noch ein in Intels “RAID Web Console 2” integriertes Java vom Mai 2014.
Eben, wo ist das Problem? Allfällige Sicherheitsbedenken betrafen /betreffen das Java Browser Plugin, das in diesem Zusammenhang aber keine Rolle spielt.
-
Auch Java selbst bleibt nicht von Sicherheitslücken verschont. Darüber hinaus gibts mit veralteten Versionen immer wieder mal Probleme mit verschlüsselten Verbindungen, da die neuere Methoden noch nicht unterstützen.
Und statt mehrerer EXE-Dateien, würde auch eine mit ausführlich kommentierter Konfigdatei genügen. Dann erspart man sich auch das Neuerstellen, wenn mal wieder Parameter geändert werden müssen. Wobei ich da für den portablen Start eine zweite mit eigener Konfigdatei dazu packen würde.
-
@mvsfsvm sagte: Auch Java selbst bleibt nicht von Sicherheitslücken verschont.
Natürlich, wie jede (andere/externe) Software auch (z.B. FFmpeg). Es ist ja nicht verboten, das Programm frisch zu packen, wenn man meint, das sei nun wirklich nötig bzw. wenn eh eine neue MV-Version erscheinen soll. Es geht hier primär um Benutzerfreundlichkeit.
-
@mvsfsvm sagte in Läuft nicht unter neuem Java9:
Auch Java selbst bleibt nicht von Sicherheitslücken verschont.
[Randnotiz]:
Im Gegenteil, Java gilt als ähnlich risikobehaftet wie der Adobe Flash Player. heise.de empfiehlt daher, Java im Browser vollständig zu deaktivieren (auf Windows ist dies z. B. möglich über das Java Control Panel in der Systemsteuerung, Reiterkarte “Sicherheit” > “Java-Content im Browser akivieren” = abhaken).Java-erfordernde Programme wie MediathekView bleiben dabei uneingeschränkt lauffähig, eventuelle Java-Sicherheitslücken können beim Surfen im Internet aber nicht mehr ausgenutzt werden.
-
@sina sagte in Läuft nicht unter neuem Java9:
Java im Browser vollständig zu deaktivieren
Jap und damit ist das sog. Java Applet. gemeint. Das hat nichts mit der JRE (dem was MV verwendet) zu tun. Moderne Webbrowser verwenden das Applet daher auch nicht mehr.
-
Hallo Entwickler!
Java 8 ist ja inzwischen doch schon in die Jahre gekommen (kostenloser Support endet zum Jahreswechsel 2018/19). Demnächst steht Java 11 an. Bislang nutze ich Version 13.0.6 problemlos unter Java 10. Die aktuelle 13.2.1 besteht aber dummerweise auf Java 8.
Interessant ist auch, dass Oracle das Konzept der JRE aufgibt und Endanwender zwingen wird, ein JDK zu installieren, wenn sie zukünftig noch Java-Programme laufen lassen wollen. Ist insgesamt eine Abkehr vom Desktop.
Weiterhin ist JavaFX ebenfalls abgekündigt. Ich war überrascht, dass Mediathek-View Abhängigkeiten dazu hat, weil mir die Oberfläche nicht nach FX aussieht. Aber mit dem Open-JDK läuft es daher auch nicht, sondern steigt aus:
Exception in thread “main” java.lang.NoClassDefFoundError: javafx/concurrent/Task
…
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at mediathek.Main.setupPortableMode(Main.java:149)Wie sieht Euer Plan für die Zukunft aus? Harte Abhängigkeiten zu Java8 und FX scheinen mir nicht so furchtbar sinnvoll. Dabei wächst die Bedeutung der Mediatheken und damit auch der Bedarf für Eure Software.
LG
private_lock