Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten

[plusterkopp]

32bit-Installer für Windows runtergeladen, inkl jre15. Verzeichnis .install4j sieht auch OK aus (also mit . ). Startet nicht. Kommandozeile versucht, kein Fenster, keine Fehlermeldung.

Start des JAR mit .\jre\bin\java.exe -jar MediathekView.jar bringt dann obige Meldung, und noch:
java.lang.UnsupportedClassVersionError: Preview features are not enabled for mediathek/Main (class file version 59.65535). Try running with ‘–enable-preview’

Der Tip hilft leider auch nicht, gleiche Meldung.

Selbstgebautes Java16 versucht wegen der class file version:
C:\Program Files (x86)\MediathekView>C:\Apps\Java\openjdk-16\bin\java -jar MediathekView.jar
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

Das Eigenbau-JDK ist natürlich 64bit, aber das sollte wohl nichts ausmachen, zumal das 32bit-JRE ja auch nicht ging.

Was mache ich falsch?

[Ein ehemaliger Benutzer]

@plusterkopp
Versuch’s mal so

[DerReisende77]

@plusterkopp sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

.\jre\bin\java.exe -jar MediathekView.jar

.\jre\bin\java.exe —enable-preview -jar MediathekView.jar ist das richtige Kommando.

Wobei ich mich frage warum Du nicht per exe startest. Mit deinem Kommando fehlen dir wichtige Parameter die das Programm benötigt und die z.T. Schwierigkeiten im Betrieb vermeiden.

[Nicklas2751]

@plusterkopp sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

Das Eigenbau-JDK ist natürlich 64bit,

Warum nutzt du ein JDK 64bit auf einem Windows 32bit? Wenn kein Windows 32bit warum dann der 32bit installer? O.o

Man kann auch die .exe via CMD starten, dann sollten auch da Logs erscheinen. Noch dazu wird im .mediathek3 Ordner eine Log Datei angelegt.

Vom selber starten via command kann ich abraten. Auch andere JREs / JDKs sind nicht zu empfehlen. Besonders für 32bit brauchen wir eine “besondere” JRE inklusive JavaFX.

[styroll]

@derreisende77 sagte:
.\jre\bin\java.exe —enable-preview -jar MediathekView.jar ist das richtige Kommando.

Auch wenn das hier nicht die Ursache des Problems darstellt: Die (pseudointelligente) Forensoftware macht es zwingend nötig, Code in einen “Code-Bereich” (</>-Button) zu setzen (dann gibt’s aus zwei Minuszeichen auch nicht einen Geviertstrich, also einen langen Strich):

--enable-preview

[plusterkopp]

@nicklas2751 sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

@plusterkopp sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

Das Eigenbau-JDK ist natürlich 64bit,

Warum nutzt du ein JDK 64bit auf einem Windows 32bit? Wenn kein Windows 32bit warum dann der 32bit installer? O.o

Ich lasse diverse Programme in 32bit laufen, weil sie dann etwas weniger RAM belegen, was besonders bei Browsern auffällt. Habe nur 16GB. Bin mir auch nicht ganz sicher, wozu MediathekView so viel RAM brauchen soll. Werde mal einen Profiler anwerfen, wenn es wieder startet.

Man kann auch die .exe via CMD starten, dann sollten auch da Logs erscheinen. Noch dazu wird im .mediathek3 Ordner eine Log Datei angelegt.

Da kommen auch keine logs. Die Log-Datei im .mediathek3 Ordner ist leer.

Vom selber starten via command kann ich abraten. Auch andere JREs / JDKs sind nicht zu empfehlen. Besonders für 32bit brauchen wir eine “besondere” JRE inklusive JavaFX.

Bloßes Anclicken der EXE war auch bei mir die erste Wahl, nur ging da halt kein Fenster auf und die Log-Datei bleibt leer.

Habe jetzt mal mit einem eigenen OpenJDK15 gestartet, da kriege ich zumindest die JavaFX-fehlt-Meldung.
Meine cmd.exe läuft komischerweise als Admin, aber mit Cygwin kann ich die MediathekView.exe ohne weitere Parameter starten und kriege auf der Kommandozeile die Meldung:
Error occurred during initialization of VM
Could not reserve enough space for 1310720KB object heap

So toll sind die in die EXE eingebrannten VM-Parameter also scheinbar nicht. Starte ich
./jre/bin/java --enable-preview -Xmx700M -jar MediathekView.jar
scheint es zu funktionieren. Und die IllegalAccessErrors kennt Ihr ja sicher.

Vielen Dank erstmal.

[Nicklas2751]

@plusterkopp sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

Ich lasse diverse Programme in 32bit laufen, weil sie dann etwas weniger RAM belegen, was besonders bei Browsern auffällt.

Dann nimm MediathekView 64bit. Nutze die exe und setze in der .vmoptions Datei den Ram auf die gewünschte Maximal länge. Standardmäßig nutzt MediathekView 2GB.

[plusterkopp]

@nicklas2751 sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

@plusterkopp sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

Ich lasse diverse Programme in 32bit laufen, weil sie dann etwas weniger RAM belegen, was besonders bei Browsern auffällt.

Dann nimm MediathekView 64bit. Nutze die exe und setze in der .vmoptions Datei den Ram auf die gewünschte Maximal länge. Standardmäßig nutzt MediathekView 2GB.

Dank compressed oops kann man ja mit Java 64bit auch in kleinem Heap laufen lassen, von daher war die 32bit Geschichte sicher Quatsch. Von der Kommandozeile lief sie letztendlich aber doch. Benutze jetzt trotzdem wieder die 64bit-Version wie seit Jahren vorher auch.

Da ich ja immer noch wissen wollte, was MediathekView mit dem ganzen Heap macht: Der Profiler meldet 130MB Stringduplikate wie erwartet, aber mein Heap wird nur knapp 850MB groß, 55% live. UseStringDeduplication spart nur 80MB, weil die Uhrzeitstrings etc nicht so super lang sind. Also doch String.intern.

In welchen Fällen nutzt man die 2GB?

[DerReisende77]

@plusterkopp String.intern verlangsamt massiv die Geschwindigkeit. Außerdem gibt es andere Seiteneffekte die man beachten muss. -XX:+UseStringDeduplication reduziert Duplikate aber man muss auch den Threshold beachten wann die M auch dedupliziert. Und nebenbei wird das auch vom Programm verwendet.

[plusterkopp]

@derreisende77 sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

@plusterkopp String.intern verlangsamt massiv die Geschwindigkeit.

…es macht zusätzliche Arbeit, ja. Mir kam die Frage nur, weil Ihr ja darauf hinweist, daß die neueren Versionen mehr Heap brauchen und da habe ich mich gefragt, wofür.

Mal davon abgesehen, daß die massive Verlangsamung wohl nicht ganz zutrifft, würde ich denken, daß Ihr beim Laden der Filmdaten eher von der Netzwerkverbindung begrenzt seid, als von String.intern. Falls doch, kann man auch zu einem späteren Zeitpunkt in einem eigenen Thread oder Timerjob über die DatenFilm-Instanzen laufen und die Strings internalisieren. Wie gesagt, nur wichtig, wenn man Heap sparen will.

Falls Euch Performance wichtig ist, könnt Ihr auch bei YourKit als OpenSource-Projekt nach einer kostenlosen Lizenz fragen.

Außerdem gibt es andere Seiteneffekte die man beachten muss.

welche?

-XX:+UseStringDeduplication reduziert Duplikate aber man muss auch den Threshold beachten wann die M auch dedupliziert. Und nebenbei wird das auch vom Programm verwendet.

Wenn man mit der EXE startet, wird es nicht benutzt, aber man kann es per .vmoptions anmachen. Leider spart es nicht den ganzen String ein und lohnt sich am meisten bei langen char[]. Das mit dem Schwellwert habe ich nicht kapiert, was meinst Du da?

[DerReisende77]

@plusterkopp String.intern() wurde in früheren Versionen eingesetzt.
Und wenn Du eine Behauptung bzgl. Nichtzutreffen einer Verlangsamung aufstellst solltest Du das bitte begründen, meine Aussage beruht auf Hotspot Monitoring von Version 13.0 bis 13.7 mittels JProfiler. Ich sauge mir das nicht aus den Fingern und ja wir haben eine gesponsorte Version mit der auch Teile der Geschwindigkeitsverbesserungen der neueren Versionen getraced wurden.

Seiteneffekte von String intern u.a. in Bezug auf die maximale String table size und Auswirkungen auf den Speicherverbrauch kannst Du bei Oracle et al nachlesen. Desweiteren gibt es zig Performance Artikel weshalb String.intern scheisse ist. Ein Beispiel für die tolle Performance findest Du hier

String Deduplication wird evtl. bei der win32 Version noch nicht benutzt da der commit dafür noch nicht gemerged wurde, die macOS Version benutzt das. Weiterhin wird das ganze in den nächsten Versionen eh komplett umgestellt womit ich mir eine verbesserte Speichernutzung erhoffe. Das muss aber alles getestet werden.

Welchen Threshold meine ich? -XX:StringDeduplicationAgeThreshold. Dieser bestimmt nach welchem GC Zyklus das erste Mal bestimmte Objekte angepasst werden.

[plusterkopp]

@derreisende77 sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:

@plusterkopp String.intern() wurde in früheren Versionen eingesetzt.
Und wenn Du eine Behauptung bzgl. Nichtzutreffen einer Verlangsamung aufstellst solltest Du das bitte begründen

Steht neben meinem Namen ENTWICKLER? Begründen könnte ich das nur mit einem Vergleich von mit/ohne. Das würde bedeuten: eine Version von MediathekView mit und eine ohne String.intern(). Darauf bezieht sich doch Deine Verlangsamungsaussage, oder?
Wir reden hier ja nicht davon, daß die Map-Variante schneller ist, oder daß es generell schneller ist, eine Methode nicht aufzurufen, als sie aufzurufen. Das steht außer Frage. Und wenn ich bislang schrieb String.intern, könnte man das auch als irgendeine Art der Stringzusammenlegung verstehen. Ob nun nur das langsame String.intern, die CHM-Version, oder das verzögerte Zusammenlegen mittels Timerjob (der aber den Nachteil hat, daß man erstmal doch den vollen Heap braucht).

Wie gesagt, es ging darum, daß das Programm jetzt mehr Heap braucht als früher. Wenn Euch die Geschwindigkeit beim Anlegen der Filmliste wichtiger ist als der Heap, dann laßt es halt so.

Seiteneffekte von String intern u.a. in Bezug auf die maximale String table size und Auswirkungen auf den Speicherverbrauch kannst Du bei Oracle et al nachlesen. Desweiteren gibt es zig Performance Artikel weshalb String.intern scheisse ist. Ein Beispiel für die tolle Performance findest Du hier

Das SOF Artikel ist etliche Jahre alt und neuere Kommentare weisen durchaus darauf hin, daß das Stringtable-Problem nicht mehr so dramatisch ist wie zu JDK-1.6 Zeiten. Aber trotzdem braucht String.intern Zeit. Auf meinem ollen i7-3770 etwa 500ns für 1M unterschiedliche Strings mit völlig überfüllter Stringtabelle.

Wenn Ihr also 500.000 DatenFilm-Instanzen habt mit je 13 String-Feldern (den Optional-Kram nicht mitgerechnet), dann wären das 3s, wahrscheinlich aber weniger, wenn man das intelligent mit CHM macht.

String Deduplication wird evtl. bei der win32 Version noch nicht benutzt da der commit dafür noch nicht gemerged wurde, die macOS Version benutzt das. Weiterhin wird das ganze in den nächsten Versionen eh komplett umgestellt womit ich mir eine verbesserte Speichernutzung erhoffe. Das muss aber alles getestet werden.

Warum auch immer Ihr da nach OS unterscheidet… Es wird auch bei der Win64-Version nicht benutzt. Mir wie gesagt egal, kann man ja konfigurieren.

Welchen Threshold meine ich? -XX:StringDeduplicationAgeThreshold. Dieser bestimmt nach welchem GC Zyklus das erste Mal bestimmte Objekte angepasst werden.

Hier mal die VM-Optionen, die ich so sehe:

uintx StringDeduplicationAgeThreshold          = 3                                         {product} {default}
 bool StringDeduplicationRehashALot            = false                                  {diagnostic} {default}
 bool StringDeduplicationResizeALot            = false                                  {diagnostic} {default}
uintx StringTableSize                          = 65536                                     {product} {default}
 bool UseStringDeduplication                   = true                                      {product} {command line}

Möglicherweise müßtet Ihr das auf 1 setzen, aber wenn ich mir mit
-Xlog:logging=trace,gc*=info,safepoint=info,ergo*=info,classhisto*=trace,gc+ergo+cset=trace:file="gc.log":time,tags,level:filesize=1G
mal euer gc.log ansehe, habt Ihr auch nach dem Erzeugen der meisten Strings noch ausreichend GCs, um alle Strings zu erwischen.

Und nächstes Mal sind wir nicht so auf Krawall gebürstet, Herr ENTWICKLER, gelle?

drückerchen!