Probleme nach Java-Update auf V1.8.0_91

Hallo zusammen,

ich habe heute morgen auf meinem Rechner das angebotene Update von V1.8.0_77 auf V1.8.0_91-b14 durchgeführt und seitdem riesige Probleme!

Zunächst fiel mir auf, dass einige NativeSwing-LIBs einen ****NoClassDefFoundError ****werfen (siehe Anlage).
Nach einiger Sucherei sieht es (fast) so aus, als ob die Anwendung aus dem neuen JRE-Ordner (C:\Programme (x86)\Java\jre1.8.0_91) aufgerufen wird. Allerdings sieht man in ersten Anhang auch das gesetzte User-Home-Verzeichnis C:\User\kbr

Zur Erklärung: die Java-Anwendungen hier in der Firma liegen mit allen notwendigen Dateien in einen spezifischen Desktop-Ordner, in dem auch verschiedene Unterordner (für verschiedene Texte, Bilder etc.) existieren. Beim Programmstart wird jeweils geprüft, ob der zugehörige Unterordner existiert. Falls nicht, wird er angelegt (“mkdirs”). Ich habe nun bei mehreren Anwendungen nach dem Start diese Unterordner im genannten JRE-Ordner gefunden …
Die eingestellten Pfade wurden nicht verändert und sind IMHO auch so korrekt:
CLASSPATH: C:\Program Files (x86)\Java\jdk1.8.0_74\bin
JAVA_HOME: C:\Program Files (x86)\Java\jdk1.8.0_74
Path: %JAVA_HOME%\bin;

Ebenso in die Manifestdatei unverändert und IMHO korrekt:
Main-Class: worker.mainApp
Class-Path: jco.jar jspComm.jar Serialio.jar edtftpj.jar foxtrot-core-4.0.jar swingx-1.6.jar WinRegistry-4.5.jar
DJNativeSwing.jar DJNativeSwing-SWT.jar swt-4.3-win32-win32-x86.jar joda-time-2.5.jar
Permissions: all-permissions
Codebase: 501

Ich habe dann mal versucht, in Eclipse im BuildPath die System Bibliothek zu V77 zu entfernen und die V91 dranzuhängen und bekam dabei die mich wirklich überraschende Meldung:
No JREs found in C:\Programme (x86)\Java\jre1.8.0_91
Alle Dateien, die bei der V77 dazu gehören, liegen auch im neuen Pfad!

Auch ein erneutes Herunterladen der Datei jre-8u91-windows-i586.exe und komplette Neuinstallation bringt genau das gleiche Ergebnis!
Nach einer Deinstallation der V91 und Rückkehr zu V77 lief alles wieder gehabt und fehlerfrei …

Hat irgendwer eine Idee, was hier schief läuft?
Kann das ein Bug in der angebotenen V91 sein?

Ich hoffe, dass mir irgendwer helfen kann !
Gruß Klaus

Also CP auf java-home/bin klingt schon irgendwie falsch - mal versucht den cp ganz weg zu nehmen?
Wie siehts mit zusatzlibs in java/ext aus? Nicht dass es sich da jemand als dev zu einfach gemacht hat.
Klingt ziemlich schräg wenn ein jre update zum cnf führt wenn der cp nicht geändert wurde.

Moin,

da in Deinem Screenshot Webstart auftaucht: Update aus der Hölle bei Verwendung von Java… | Forum - heise online

Gruß
Fancy

Kleinigkeiten:
V1.8.0_77 mehrfach genannt aber
CLASSPATH: C:\Program Files (x86)\Java\jdk1.8.0_74\bin
JAVA_HOME: C:\Program Files (x86)\Java\jdk1.8.0_74
?

Codebase mit Webseite ‘ourwebserver.de’ als echte URL ist nur so nebenbei mitkopiert, vom Forum automatisch umgewandelt, oder hat das eine Bedeutung?

Guten Morgen allerseits,

Danke für den Link - dann bin ich ja nicht alleine :wink:
Ich habe gestern Abend noch diesen Link gefunden (fw_error_www), den ich mir mal zu Gemüte führen muss …

EDIT: hmm, hier klappt was mit der Umsetzung nicht … in der Vorschau kommt es noch richtig :confused:
http:__www.java.com_de_download_faq__release_changes.xml

Versionsnummern
stimmt, das habe ich undeutlich beschrieben :frowning:
mit V1.8.0_77 / _91 ist die Versionsnummer des JRE !!
als JDK ist noch die 74er-Version drauf!

ourwebserver.de

Nein, das hat keine Bedeutung, habe nur die echte Adresse überschrieben (und nicht an eine automatische Umwandlung gedacht) - mea maxima culpa …

CP auf java-home/bin

Oh, richtig, da hatte ich auch ein kleine Anpassung versucht.
Ursprünglich stand zu Beginn des CP der Pfad „C:\ProgramData\Oracle\Java\javapath“, wo ja eine Zeitlang die drei Dateien JAVA.exe, JAVAW.exe und JAVAWS.exe lagen. Diese waren durch das Update wohl auf 0 byte Größe gestezt worden, sprich: leer …
Da weiter hinten noch der Pfad auf das JDK („C:\Program Files (x86)\Java\jdk1.8.0_74\bin“) eingetragen war, habe ich in auf die oben beschriebene Weise nach vorne gesetzt

Was sich mir aber immer noch kollosal stört, ist die Tatsache, dass es so ausschaut, als ob die Anwendungen aus dem JRE-Verzeichnis heraus gestartet würden, da hier scheinbar die Existenz des spezifischen Verzeichnisses „WORKER-Dateien“ geprüft wird und es dann dort neu erzeugt wird, da es ja nicht vorhanden ist (bei einer weiteren Applikation genauso, aber die kann ich wenigstens starten, da alle LIBS gefunden werden).

Ist trotz allem sehr frustrierend, dass Oracle da ständig extreme Dinge in den Updates ändert und dann schlagartig erstmal gar nicht mehr geht :mad:

Gruß Klaus

*** Edit ***

Moin nochmals,

[quote=vfl_freak;133099]Ich habe dann mal versucht, in Eclipse im BuildPath die System Bibliothek zu V77 zu entfernen und die V91 dranzuhängen und bekam dabei die mich wirklich überraschende Meldung:
No JREs found in C:\Programme (x86)\Java\jre1.8.0_91
Alle Dateien, die bei der V77 dazu gehören, liegen auch im neuen Pfad![/quote]
Dies scheint doch wohl auch ernsthaft auf ein Problem innerhalb des Updates hinzudeuten, oder ??
Gruß Klaus

Gestatte mir die Frage: Warum legst du den CLASSPATH (!) auf das bin-Verzeichnis von Java? Ich gehe doch mal von aus dass du weist was der CP ist, oder?
Weiter: Es ist richtig dass die Files im genannten Verzeichnis 0 Byte groß sind, denn es handelt sich dabei um die NTFS-Variante von den unter Unix bekannten Softlinks. Was jedoch nicht funktioniert ist wenn statt java-home/bin entsprechend dieses “link”-Verzeichnis im PATH steht - auch irgendwie merkwürdig - dürfte aber eine Eigentheit der Win-API sein.

Alles in allem trotzdem merkwürdiges verhalten. Sicher, Oracle hat wohl das eine oder andere geändert - aber dass es dabei die Auflösung des CP zerschießt - unwahrscheinlich. Ich selbst hab noch kein Update gefahren (Kann mir mal wer den Unterschied zwischen u91 und u92 erklären?), kann mir aber nicht vorstellen dass es bei mir zu irgendwelchen vergleichbaren Problemen führen wird. Wenn doch meld ich mich natürlich gerne.

Moin,

Streng genommen habe ich das eingetragen, es stand immer schon drin!
Ich habe jetzt nur versucht, aufgrund der Probleme und einiger Hinweise im Web, da rumzufrickeln :slight_smile:

[QUOTE=Sen-Mithrarin;133131]
Weiter: Es ist richtig dass die Files im genannten Verzeichnis 0 Byte groß sind, denn es handelt sich dabei um die NTFS-Variante von den unter Unix bekannten Softlinks. Was jedoch nicht funktioniert ist wenn statt java-home/bin entsprechend dieses „link“-Verzeichnis im PATH steht - auch irgendwie merkwürdig - dürfte aber eine Eigentheit der Win-API sein.[/QUOTE]
Bis vor einigen Releases war das unter Win sogar notwendig, weshalb der Pfad bei mir auch im CP stand, da anderfalls bspw. javaws nicht mehr gefunden wurde …
Dieses ewige Hin und Her von Oracle kotzt mich sowie langsam an :sick::twisted:

[QUOTE=Sen-Mithrarin;133131]
Alles in allem trotzdem merkwürdiges verhalten. Sicher, Oracle hat wohl das eine oder andere geändert - aber dass es dabei die Auflösung des CP zerschießt - unwahrscheinlich. Ich selbst hab noch kein Update gefahren (Kann mir mal wer den Unterschied zwischen u91 und u92 erklären?), kann mir aber nicht vorstellen dass es bei mir zu irgendwelchen vergleichbaren Problemen führen wird. Wenn doch meld ich mich natürlich gerne.[/QUOTE]
lt. „http://www.oracle.com/technetwork/java/javase/overview/index.html“: Java SE 8u91 is the latest Security Alert releases for JDK 8. Java SE 8u92 is the latest patch-set update with additional
features
- was auch immer das genau heißen mag …
Über den normalen Updates-Mechanismus und bei der anschließenden Prüfung scheint 91 aktuell zu sein!

Gruß Klaus

Danke für der Erklärung mit u91/u92.

Bzgl. des javapath im PATH: soll wohl ein möglicher Ausweg sein um nicht in C:\Windows packen zu müssen - macht aber für Win selbst keinen Unterschied.

Was den CP angeht: Es ist ja der Pfad in dem Java nach .class-Files sucht. Für Win zur Ausführung ist er nicht relevant. Was aber sehr merwürdig ist das anscheinend java-home als working-dir genutzt wird was ja normalerweise nicht der Fall sein sollte.

Lässt für mich eigentlich nur zwei Möglichkeiten zu: entweder hat Oracle das Update komplett versaut oder bei dir passt was nicht. Da ich aber grad auf Arbeit bin kann ich dazu erst heute Abend nach nem eigenen Test darauf genauer antworten.

Moin,

erstmal Danke für Deine Mühe :slight_smile:

Nun ja, habe es ja nur zitiert … oder besser: kopiert :wink:

Denke ich auch … aber muss man den Zugriff alle paar Update wieder ändern ??? :grr:

Wurde wohl auch beim Installieren des JDK automatisch eingetragen …

Das stört mich auch am Meisten (neben der Tatsache, dass das 91er JRE in Eclipse nicht verlinkt werden kann)
Das trat auch sofort nach Einspielen des Updates auf - ohne weitere Änderungen :confused:

Möglicherweise … nun ist es ja auch noch recht frisch!

Das Hauptproblem scheint aber mittlerweile wohl das Nicht-Finden der LIBs zu sein (siehe Anlage und Link dazu weiter oben im Beitrag von Fancy).
Eine zweite Applikation, die die genannten NativeSwing-Libs nicht nutzt, startet zwar hakelig, läuft aber immerhin

Wir harren hier erst mal der Dinge die da kommen und lassen keine Updates > 77 zu …

Danke und Gruß
Klaus

Shit, das problem scheint mit der von mir verwendeten “NativeSwing”-Lib zusammenzuhängen.
Ich habe mal alle diesbezüglichen Stellen auskommentiert - dann lief es wieder …

Da werde ich dann mal graben müssen, ob wir sie ersetzen können …

Aha, ich spinne also doch nicht :stuck_out_tongue:
https://bugs.openjdk.java.net/browse/JDK-8154899
::headbang::

[quote=vfl_freak;133184]Aha, ich spinne also doch nicht
https://bugs.openjdk.java.net/browse/JDK-8154899[/quote]Wieso soll ein Bug in openJDK zu Fehlern im Oracle-JDK führen?

bye
TT

Moin,

ich weiß nicht WIE - jedenfalls ist es genau das Fehlverhalten, das hier auftritt !!

Gruß Klaus

[ot]

[QUOTE=Timothy_Truckle;133189]Wieso soll ein Bug in openJDK zu Fehlern im Oracle-JDK führen?
[/QUOTE]
Oracle bedient sich doch vom OpenJDK, oder hab’ ich da was falsch verstanden?
[/ot]

afaik stellt das openjdk-projekt seit v7 die offizielle Referenzimplementierung dar. Die Hauptunterschiede finden sich im native-Code sowie den nicht-API-Klassen in sun.* und com.sun.* bzw com.ibm.* oder sonstigen implementierungsspezifischen Paketen. Oder kurz: in allem was nicht durch die API-Doku oder die Lang-Specs vorgegeben ist.