Wie behebe ich einen NoSuchMethodError?
https://stackoverflow.com/questions/35186
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich bekomme ein NoSuchMethodError Fehler beim Ausführen meines Java-Programms.Was ist los und wie kann ich es beheben?
Lösung
Ohne weitere Informationen ist es schwierig, das Problem zu lokalisieren, aber die Ursache liegt höchstwahrscheinlich darin, dass Sie eine Klasse mit einer anderen Version der Klasse kompiliert haben, der eine Methode fehlt als der, die Sie beim Ausführen verwenden.
Schauen Sie sich den Stacktrace an ...Wenn die Ausnahme beim Aufrufen einer Methode für ein Objekt in einer Bibliothek auftritt, verwenden Sie beim Kompilieren und Ausführen höchstwahrscheinlich separate Versionen der Bibliothek.Stellen Sie sicher, dass Sie an beiden Stellen die richtige Version haben.
Wenn die Ausnahme auftritt, wenn eine Methode für von Klassen instanziierte Objekte aufgerufen wird Du gemacht, dann scheint Ihr Build-Prozess fehlerhaft zu sein.Stellen Sie sicher, dass die tatsächlich ausgeführten Klassendateien beim Kompilieren aktualisiert werden.
Andere Tipps
Ich hatte Ihr Problem, und so habe ich es behoben.Die folgenden Schritte sind eine funktionierende Methode zum Hinzufügen einer Bibliothek.Ich hatte die ersten beiden Schritte richtig gemacht, den letzten jedoch nicht, indem ich die Datei „.jar“ direkt aus dem Dateisystem in den Ordner „lib“ in meinem Eclipse-Projekt gezogen habe.Außerdem musste ich die vorherige Version der Bibliothek sowohl aus dem Build-Pfad als auch aus dem Ordner „lib“ entfernen.
Schritt 1 – Fügen Sie .jar zum Erstellungspfad hinzu
Schritt 2 – Quellen und Javadocs zuordnen (optional)
Schritt 3 – Ziehen Sie die JAR-Datei tatsächlich in den Ordner „lib“ (nicht optional).
Beachten Sie, dass Sie im Falle einer Reflexion eine erhalten NoSuchMethodException, während Sie mit nicht reflektierendem Code erhalten NoSuchMethodError.Ich neige dazu, an sehr unterschiedlichen Orten zu suchen, wenn ich mit dem einen oder dem anderen konfrontiert werde.
Wenn Sie die Möglichkeit haben, die JVM-Parameter zu ändern, sollten Sie durch das Hinzufügen einer ausführlichen Ausgabe sehen können, welche Klassen aus welchen JARs geladen werden.
java -verbose:class <other args>
Wenn Ihr Programm ausgeführt wird, sollte die JVM Standard-Out-Informationen ausgeben, wie zum Beispiel:
...
[Junit.framework.Assert aus Datei:/C:/Program%20Files/junit3.8.2/junit.jar geladen]
...
Dies wird normalerweise verursacht, wenn ein Build-System wie verwendet wird Apache-Ameise Dadurch werden Java-Dateien nur dann kompiliert, wenn die Java-Datei neuer als die Klassendatei ist.Wenn sich eine Methodensignatur ändert und Klassen die alte Version verwenden, werden die Dinge möglicherweise nicht korrekt kompiliert.Die übliche Lösung besteht darin, eine vollständige Neuerstellung durchzuführen (normalerweise „ant clean“ und dann „ant“).
Manchmal kann dies auch dadurch verursacht werden, dass mit einer Version einer Bibliothek kompiliert, aber mit einer anderen Version ausgeführt wird.
Bei Verwendung Maven oder einem anderen Framework, und Sie erhalten diesen Fehler fast zufällig, versuchen Sie es mit einer Neuinstallation wie ...
clean install
Dies funktioniert besonders wahrscheinlich, wenn Sie das Objekt geschrieben haben und wissen, dass es über die Methode verfügt.Hat bei mir funktioniert.
Dies kann auch das Ergebnis der Verwendung von Reflexion sein.Wenn Sie Code haben, der eine Klasse widerspiegelt und eine Methode nach Namen extrahiert (z. B.:mit Class.getDeclaredMethod("someMethodName", .....)) Dann müssen Sie jedes Mal, wenn sich der Methodenname ändert, z. B. während einer Umgestaltung, daran denken, die Parameter der Reflektionsmethode zu aktualisieren, damit sie mit der neuen Methodensignatur übereinstimmen getDeclaredMethod Anruf wird ein werfen NoSuchMethodException.
Wenn dies der Grund ist, sollte der Stack-Trace den Punkt anzeigen, an dem die Reflektionsmethode aufgerufen wird, und Sie müssen nur die Parameter aktualisieren, damit sie mit der tatsächlichen Methodensignatur übereinstimmen.
Nach meiner Erfahrung tritt dies gelegentlich auf, wenn private Methoden/Felder in Unit-Tests getestet werden und a TestUtilities Klasse zum Extrahieren von Feldern zur Testüberprüfung.(Im Allgemeinen mit Legacy-Code, der nicht für Unit-Tests entwickelt wurde.)
Wenn Sie eine Webanwendung schreiben, stellen Sie sicher, dass sich im globalen Bibliotheksverzeichnis Ihres Containers und auch in Ihrer App keine widersprüchlichen Versionen einer JAR-Datei befinden.Möglicherweise wissen Sie nicht unbedingt, welches JAR vom Klassenlader verwendet wird.
z.B.
- tomcat/common/lib
- mywebapp/WEB-INF/lib
Diese Probleme werden durch die Verwendung desselben Objekts in denselben beiden Klassen verursacht.Die verwendeten Objekte enthalten keine neue Methode, die in der neuen Objektklasse enthalten ist.
ex:
filenotnull=/DayMoreConfig.conf
16-07-2015 05:02:10:ussdgw-1: Open TCP/IP connection to SMSC: 10.149.96.66 at 2775
16-07-2015 05:02:10:ussdgw-1: Bind request: (bindreq: (pdu: 0 9 0 [1]) 900 900 GEN 52 (addrrang: 0 0 2000) )
Exception in thread "main" java.lang.NoSuchMethodError: gateway.smpp.PDUEventListener.<init>(Lgateway/smpp/USSDClient;)V
at gateway.smpp.USSDClient.bind(USSDClient.java:139)
at gateway.USSDGW.initSmppConnection(USSDGW.java:274)
at gateway.USSDGW.<init>(USSDGW.java:184)
at com.vinaphone.app.ttn.USSDDayMore.main(USSDDayMore.java:40)
-bash-3.00$
Diese Probleme werden durch die begleitende ähnliche Klasse 02 verursacht (1 in src, 1 in der JAR-Datei, hier ist „gateway.jar“).
Dies bedeutet, dass die entsprechende Methode in der Klasse nicht vorhanden ist:
- Wenn Sie JAR verwenden, dekompilieren Sie und prüfen Sie, ob die jeweilige JAR-Version die richtige Klasse hat.
- Überprüfen Sie, ob Sie die richtige Klasse aus Ihrer Quelle kompiliert haben.
Bei mir ist es passiert, weil ich den Argumenttyp in der Funktion von Objekt a in String a geändert habe.Ich könnte es mit Clean und Build erneut beheben
Ich habe diesen Fehler gerade behoben, indem ich mein Eclipse neu gestartet und die Anwendung ausgeführt habe.Der Grund für meinen Fall könnte darin liegen, dass ich meine Quelldateien ersetze, ohne mein Projekt oder Eclipse zu schließen.Was dazu führte, dass ich eine andere Version der Klassen verwendete.
Versuchen Sie es so:Entfernen Sie alle .class-Dateien in Ihren Projektverzeichnissen (und natürlich alle Unterverzeichnisse).Wiederaufbau.
Manchmal mvn clean (wenn Sie Maven verwenden) bereinigt keine manuell erstellten .class-Dateien javac.Und diese alten Dateien enthalten alte Signaturen, die dazu führen NoSuchMethodError.
Ich füge nur vorhandene Antworten hinzu.Ich hatte dieses Problem mit Tomcat in Eclipse.Ich hatte eine Klasse geändert und folgende Schritte ausgeführt:
Bereinigt und das Projekt in Eclpise erstellt
MVN-Neuinstallation
- Tomcat neu gestartet
Trotzdem stand ich vor dem gleichen Fehler.Dann Ich habe Tomcat und das Tomcat-Arbeitsverzeichnis bereinigt und den Server neu gestartet und mein Problem ist behoben.Hoffe, das hilft jemandem
Ich habe dieses Problem in Eclipse behoben, indem ich eine Junit-Testdatei umbenannt habe.
In meinem Eclipse-Arbeitsbereich habe ich ein App-Projekt und ein Testprojekt.
Das Testprojekt hat das App-Projekt als erforderliches Projekt im Build-Pfad.
Es wurde der NoSuchMethodError angezeigt.
Dann wurde mir klar, dass die Klasse im Testprojekt denselben Namen hatte wie die Klasse im App-Projekt.
App/
src/
com.example/
Projection.java
Test/
src/
com.example/
Projection.java
Nach dem Umbenennen des Tests in den korrekten Namen „ProjectionTest.java“ verschwand die Ausnahme.
Ich bin auf ein ähnliches Problem gestoßen, als ich Methodensignaturen in meiner Anwendung geändert habe.Durch das Bereinigen und Neuaufbauen meines Projekts wurde der „NoSuchMethodError“ behoben.
Die obige Antwort erklärt sehr gut. Nur um eine Sache hinzuzufügen, wenn Sie mit Eclipse Strg+Shift+T verwenden und die Paketstruktur der Klasse eingeben (z. B.:Gateway.smpp.PDUEventListener ), finden Sie alle Jars/Projekte, in denen es vorhanden ist.Entfernen Sie unnötige JAR-Dateien aus dem Klassenpfad oder fügen Sie sie oben im Klassenpfad hinzu.Jetzt wird das richtige ausgewählt.
Ich bin auf ein ähnliches Problem gestoßen.
Caused by: java.lang.NoSuchMethodError: com.abc.Employee.getEmpId()I
Schließlich habe ich herausgefunden, dass die Ursache darin liegt, dass sich der Datentyp der Variablen geändert hat.
Employee.java-> Enthält die Variable (EmpId), dessen Datentyp geändert wurdeintZuString.ReportGeneration.java-> Ruft den Wert mit dem Getter ab,getEmpId().
Wir sollen das Glas neu bündeln, indem wir nur die geänderten Klassen einbeziehen.Da es keine Änderung gab ReportGeneration.java Ich habe nur das eingeschlossen Employee.class in der Jar-Datei.Ich musste das mit einbeziehen ReportGeneration.class Datei im JAR, um das Problem zu lösen.
Ich hatte das gleiche Problem.Dies wird auch verursacht, wenn in den Klassen Unklarheiten bestehen.Mein Programm hat versucht, eine Methode aufzurufen, die in zwei JAR-Dateien vorhanden war, die sich am selben Speicherort/Klassenpfad befanden.Löschen Sie eine JAR-Datei oder führen Sie Ihren Code so aus, dass nur eine JAR-Datei verwendet wird.Stellen Sie sicher, dass Sie nicht dasselbe JAR oder verschiedene Versionen desselben JAR verwenden, die dieselbe Klasse enthalten.
DISP_E_EXCEPTION [Schritt] [] [Z-JAVA-105 Java-Ausnahme java.lang.NoSuchMethodError(com.example.yourmethod)]
Um die ursprüngliche Frage zu beantworten.Laut Java-Dokumenten Hier:
„NoSuchMethodError“ Wird ausgelöst, wenn eine Anwendung versucht, eine angegebene Methode einer Klasse (entweder statisch oder Instanz) aufzurufen und diese Klasse keine Definition dieser Methode mehr hat.
Normalerweise wird dieser Fehler vom Compiler abgefangen;Dieser Fehler kann zur Laufzeit nur auftreten, wenn sich die Definition einer Klasse inkompatibel geändert hat.
- Wenn es zur Laufzeit passiert, überprüfen Sie, ob sich die Klasse, die die Methode enthält, im Klassenpfad befindet.
- Überprüfen Sie, ob Sie eine neue JAR-Version hinzugefügt haben und die Methode kompatibel ist.
Meistens wird java.lang.NoSuchMethodError vom Compiler abgefangen, manchmal kann es aber auch zur Laufzeit auftreten.Wenn dieser Fehler zur Laufzeit auftritt, könnte der einzige Grund die Änderung in der Klassenstruktur sein, die zur Inkompatibilität geführt hat.
Beste Erklärung: https://www.journaldev.com/14538/java-lang-nosuchmethoderror
Ich bin auch auf diesen Fehler gestoßen.
Mein Problem war, dass ich die Signatur einer Methode geändert habe, so etwas wie
void invest(Currency money){...}
hinein
void invest(Euro money){...}
Diese Methode wurde aus einem ähnlichen Kontext aufgerufen
public static void main(String args[]) {
Bank myBank = new Bank();
Euro capital = new Euro();
myBank.invest(capital);
}
Der Ersteller hat sich zu Warnungen/Fehlern nicht geäußert, da Kapital sowohl Währung als auch Euro ist.
Das Problem entstand aufgrund der Tatsache, dass ich nur die Klasse kompiliert habe, in der die Methode definiert wurde – Bank, nicht aber die Klasse, von der aus die Methode aufgerufen wird, die die Methode main() enthält.
Dieses Problem tritt möglicherweise nicht allzu häufig auf, da das Projekt in den meisten Fällen manuell neu erstellt oder eine Build-Aktion automatisch ausgelöst wird, anstatt nur die eine geänderte Klasse zu kompilieren.
Mein Anwendungsfall bestand darin, dass ich eine .jar-Datei generierte, die als Hotfix verwendet werden sollte und die App.class nicht enthielt, da diese nicht geändert wurde.Für mich war es sinnvoll, es nicht einzubeziehen, da ich die Basisklasse des ursprünglichen Arguments durch Vererbung beibehalten habe.
Die Sache ist, wenn Sie eine Klasse kompilieren, ist der resultierende Bytecode eine Art statisch, mit anderen Worten, es ist ein harte Referenz.
Der ursprüngliche zerlegte Bytecode (generiert mit dem Javap-Tool) sieht folgendermaßen aus:
#7 = Methodref #2.#22 // Bank.invest:(LCurrency;)V
Nachdem der ClassLoader die neu kompilierte Bank.class geladen hat, wird er eine solche Methode nicht finden, es sieht so aus, als ob sie entfernt und nicht geändert wurde, daher der benannte Fehler.
Hoffe das hilft.
Das Problem bestand in meinem Fall darin, dass sich im Build-Pfad zwei Versionen derselben Bibliothek befanden.Die ältere Version der Bibliothek verfügte nicht über diese Funktion, die neuere jedoch schon.
Ich hatte ein ähnliches Problem mit meinem Gradle-Projekt unter Verwendung von Intelij.Ich habe es gelöst, indem ich das .gradle-Paket (siehe Screenshot unten) gelöscht und das Projekt neu erstellt habe..gradle-Paket
NoSuchMethodError:Ich habe ein paar Stunden damit verbracht, dieses Problem zu beheben, und habe es schließlich durch einfaches Umbenennen des Paketnamens, Bereinigen und Erstellen behoben ...Versuchen Sie es zuerst mit Clean Build. Wenn es nicht funktioniert, versuchen Sie, den Klassennamen oder Paketnamen umzubenennen und Clean Build ... es sollte behoben sein.Viel Glück.
Ich hatte den gleichen Fehler:
Exception in thread "main" java.lang.NoSuchMethodError: com.fasterxml.jackson.core.JsonGenerator.writeStartObject(Ljava/lang/Object;)V
at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:151)
at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:292)
at com.fasterxml.jackson.databind.ObjectMapper._configAndWriteValue(ObjectMapper.java:3681)
at com.fasterxml.jackson.databind.ObjectMapper.writeValueAsString(ObjectMapper.java:3057)
Um es zu lösen, habe ich zunächst überprüft, Modulabhängigkeitsdiagramm (click in your POM the combination -> Ctrl+Alt+Shift+U oder right click in your POM -> Maven -> Show dependencies), um zu verstehen, wo genau der Konflikt zwischen Bibliotheken lag (Intelij IDEA).In meinem speziellen Fall hatte ich verschiedene Versionen von Jackson-Abhängigkeiten.
1) Also habe ich direkt in meinem POM des Projekts explizit die höchste Version – 2.8.7 dieser beiden – hinzugefügt.
In Eigenschaften:
<jackson.version>2.8.7</jackson.version>
Und als Abhängigkeit:
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>${jackson.version}</version>
</dependency>
2) Es kann aber auch mit gelöst werden Abhängigkeitsausschlüsse.
Nach dem gleichen Prinzip wie unten im Beispiel:
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
</exclusions>
</dependency>
Abhängigkeiten von unerwünschten Versionen werden von Ihrem Projekt ausgeschlossen.
Wenn sich Ihr Dateiname vom Klassennamen unterscheidet, der die Hauptmethode enthält, besteht möglicherweise die Möglichkeit, dass dieser Fehler verursacht wird.
