NoClassDefFoundError

Status
Nicht offen für weitere Antworten.

-frank

Bekanntes Mitglied
Hallo,

ich bekomme bei meinem Programm eine java.lang.NoClassDefFoundError-Exception.
allerdings NICHT jedes mal. Das Programm läuft ne zeitlang, erzeugt auch viele Instanzen der entsprechenden Klasse und irgendwann wird die Exception geworfen. Danach gehts auch wieder (also wenn im Programm später wieder ne Instanz der Klasse erzeugt wird)

Besonderheiten bzw. mögliche Fehlerquellen(?): ich verwende Swing, viele Threads und UDP-Kommunikation.

bei Google (bzw. auch hier in den FAQ) finde ich nur Fälle, wo Leute den classpath falsch gesetzt haben oder ähnliches.

hat jemand ne ahnung, woran der fehler liegen kann bzw. worauf ich achten muss?
 
korrektur: in der zweiten ausführung des programms hatte ich den fehler nicht. in der ersten schon (habe das programm 2x gestartet aus der kommandozeile)

vermutung: ist es möglich, dass man das programm zu früh startet, bevor das ant-build fertig ist und so die klasse zerstört ist? (die entsprechende klasse befindet sich neben allen anderen in einem jarfile)
oder wirf java sowieso ne exception, wenn ich ein auf ein jar-file zugreifen möchte, welches gerade geschrieben wird?
 
Es ist nicht immer so, dass beim Erzeugen eines Objekts überhaupt auf das Jar-File zugegriffen wird; wenn das erste Objekt einer Klasse erzeugt wurde, ist der Byte-Code dem ClassLoader ja bereits bekannt.

Um das Problem etwas einzugrenzen, wäre etwas mehr Input gut: verwendest Du einen eigenen ClassLoader? Tritt der Fehler nur mit einer bestimmten Klasse auf? Wie sehen der Stack-Trace der Exception und die betr. Stelle im Quelltext aus?
 
Murray hat gesagt.:
Es ist nicht immer so, dass beim Erzeugen eines Objekts überhaupt auf das Jar-File zugegriffen wird; wenn das erste Objekt einer Klasse erzeugt wurde, ist der Byte-Code dem ClassLoader ja bereits bekannt.

aber beim Start muss er einmal das JarFile laden. kann es sein, dass es zu diesem Zeitpunkt gerade verändert wurde? (sollte es da nicht ne Exception geben?)

Um das Problem etwas einzugrenzen, wäre etwas mehr Input gut: verwendest Du einen eigenen ClassLoader? Tritt der Fehler nur mit einer bestimmten Klasse auf? Wie sehen der Stack-Trace der Exception und die betr. Stelle im Quelltext aus?

ich verwende (wissentlich) keinen anderen ClassLoader.
Ich bilde mir ein, dass ich den Fehler schon 1-2 mal vorher beim Schreiben/Testen dieses Programms hatte. bin mir aber nicht sicher, ob es da dieselbe klasse betroffen hat.

stacktrace war relativ uninteressant. unterste zeile war die run-methode aus dem neuen thread. dann kommt zwei methodeaufrufe höher schon die exception beim erzeugen einer klasse mit new ABC(String, INetSocketAddress, Hashtable). zeilenangaben gabs aber nicht (unknown source)

ich kann den fehler aber nicht reproduzieren. falls er wiederkehrt, schaue ich mir das ganze genauer an und poste nochmal. ich vermute aber schon, dass es irgendwie mit dem verzögerten build zusammenhängt...

hmmmm, lösung? :
wenn ich das programm starte, bevor das jarfile rechtzeitig erzeugt wurde, dann bekomme ich (wie erwartet) eine exception gleich beim start. was ist aber, wenn das jarfile schon da ist und DANACH noch mal vom build verändert wird? (ich erzeuge nämlich aus dem jarfile, ein signiertes jarfile).
ich schätze es müsste an dieser änderung liegen oder?
 
Alle Klassen die schon geladen wurden sind davon vermutlich nicht betroffen und beim Rest kann es wohl unter Umständen knallen.
Warum machst du dir eigentlich solche Sorgen?
Warte doch einfach bis der build abgeschlossen ist bevor du das Prog startest :bae:
 
Wildcard hat gesagt.:
Alle Klassen die schon geladen wurden sind davon vermutlich nicht betroffen und beim Rest kann es wohl unter Umständen knallen.
Warum machst du dir eigentlich solche Sorgen?
Warte doch einfach bis der build abgeschlossen ist bevor du das Prog startest :bae:

hehe, naja..., ich mache mir über fehler sorgen, deren ursache ich nicht kenne. jetzt wo mir klar ist, woran es lag, warte ich einfach ne sekunde länger 😉
 
Status
Nicht offen für weitere Antworten.

Zurück
Oben