Ik krijg een NoSuchMethodError-fout bij het uitvoeren van mijn Java-programma. Wat is er aan de hand en hoe los ik het op?
Antwoord 1, autoriteit 100%
Zonder meer informatie is het moeilijk om het probleem te lokaliseren, maar de hoofdoorzaak is dat u hoogstwaarschijnlijk een klasse hebt gecompileerd tegen een andere versie van de klasse die een methode mist, dan degene die u gebruikt bij het uitvoeren ervan .
Kijk naar de stacktracering … Als de uitzondering verschijnt bij het aanroepen van een methode op een object in een bibliotheek, gebruikt u hoogstwaarschijnlijk afzonderlijke versies van de bibliotheek bij het compileren en uitvoeren. Zorg ervoor dat je op beide plaatsen de juiste versie hebt.
Als de uitzondering verschijnt bij het aanroepen van een methode op objecten die zijn geïnstantieerd door klassen die jeheeft gemaakt, dan lijkt je bouwproces defect te zijn. Zorg ervoor dat de klassenbestanden die u daadwerkelijk uitvoert, worden bijgewerkt wanneer u compileert.
Antwoord 2, autoriteit 46%
Ik had uw probleem en dit is hoe ik het heb opgelost. De volgende stappen zijn een werkende manier om een bibliotheek toe te voegen. Ik had de eerste twee stappen goed gedaan, maar de laatste niet door het “.jar”-bestand rechtstreeks van het bestandssysteem naar de map “lib” op mijn eclipse-project te slepen. Bovendien moest ik de vorige versie van de bibliotheek verwijderen uit zowel het buildpad als de map “lib”.
Stap 1 – .jar toevoegen om pad te bouwen
Stap 2 – Koppel bronnen en javadocs (optioneel)
Stap 3 – Sleep het .jar-bestand daadwerkelijk naar de map “lib” (niet optioneel)
Antwoord 3, autoriteit 32%
Merk op dat je in het geval van reflectie een NoSuchMethodExceptionkrijgt, terwijl je bij niet-reflecterende code NoSuchMethodErrorkrijgt. Ik heb de neiging om op heel verschillende plaatsen te gaan kijken als ik met de een of de ander wordt geconfronteerd.
Antwoord 4, autoriteit 23%
Als je toegang hebt om de JVM-parameters te wijzigen, zou het toevoegen van uitgebreide uitvoer je in staat moeten stellen om te zien welke klassen van welke JAR-bestanden worden geladen.
java -verbose:class <other args>
Wanneer uw programma wordt uitgevoerd, zou de JVM moeten dumpen naar standaard informatie zoals:
…
[Junit.framework.Assert geladen uit bestand:/C:/Program%20Files/junit3.8.2/junit.jar]
…
Antwoord 5, autoriteit 6%
Dit wordt meestal veroorzaakt bij gebruik van een bouwsysteem zoals Apache Antdat alleen Java-bestanden compileert als het Java-bestand nieuwer dan het klassenbestand. Als de handtekening van een methode verandert en klassen de oude versie gebruikten, is het mogelijk dat dingen niet correct worden gecompileerd. De gebruikelijke oplossing is om een volledige rebuild uit te voeren (meestal “ant clean” en dan “ant”).
Soms kan dit ook worden veroorzaakt bij het compileren tegen de ene versie van een bibliotheek, maar tegen een andere versie.
Antwoord 6, autoriteit 6%
Als je Mavenof een ander framework gebruikt en je krijgt deze foutmelding bijna willekeurig, probeer dan een schone installatie zoals…
clean install
Dit werkt vooral als je het object hebt geschreven en je weet dat het de methode heeft.
Antwoord 7, autoriteit 2%
Dit kan ook het gevolg zijn van het gebruik van reflectie. Als je code hebt die reflecteert op een klasse en een methode op naam extraheert (bijv. met Class.getDeclaredMethod("someMethodName", .....)), dan zal elke keer dat die methodenaam verandert, zoals zoals tijdens een refactor, moet u eraan denken om de parameters bij te werken naar de reflectiemethode om overeen te komen met de nieuwe methodehandtekening, of de getDeclaredMethod-aanroep zal een NoSuchMethodExceptiongenereren.
Als dit de reden is, moet de stacktracering het punt aangeven waarop de reflectiemethode wordt aangeroepen, en hoeft u alleen de parameters bij te werken zodat ze overeenkomen met de daadwerkelijke handtekening van de methode.
In mijn ervaring komt dit af en toe voor bij het testen van privémethoden/velden en het gebruik van een TestUtilities-klasse om velden te extraheren voor testverificatie. (Over het algemeen met verouderde code die niet is ontworpen met het testen van eenheden in gedachten.)
Antwoord 8, autoriteit 2%
Als u een webapp schrijft, zorg er dan voor dat u geen conflicterende versies van een jar in de algemene bibliotheekmap van uw container en ook in uw app hebt. Je weet misschien niet per se welke jar wordt gebruikt door de classloader.
bijv.
- tomcat/common/lib
- mijnwebapp/WEB-INF/lib
Antwoord 9, autoriteit 2%
Voor mij gebeurde het omdat ik het argumenttype in de functie veranderde, van Object a, in String a. Ik zou het kunnen oplossen met schoon en opnieuw bouwen
Antwoord 10, autoriteit 2%
In mijn geval had ik een project met meerdere modules en het scenario was alsof com.xyz.TestClassin module Azat en ook in module Ben module Awas afhankelijk van module B. Dus tijdens het maken van een assembly-jar denk ik dat er maar één versie van de klasse is behouden als die niet de aangeroepen methode heeft, dan kreeg ik NoSuchMethodErrorruntime-uitzondering, maar de compilatie was prima.
Gerelateerd: https://reflectoring.io/nosuchmethod/
Antwoord 11
Het betekent dat de betreffende methode niet aanwezig is in de klasse:
- Als je jar gebruikt, decompileer dan en controleer of de respectievelijke versie van jar de juiste klasse heeft.
- Controleer of je de juiste klasse uit je bron hebt gecompileerd.
Antwoord 12
Ik heb deze fout zojuist opgelost door mijn Eclipse opnieuw op te starten en de applicatie uit te voeren.
De reden voor mijn geval kan omdat ik mijn bronbestanden vervang zonder mijn project of eclips te sluiten.
Die verschillende versie van klassen heeft veroorzaakt die ik gebruikte.
13
Deze problemen worden veroorzaakt door het gebruik van hetzelfde object op dezelfde twee klassen.
Gebruikte objecten bevat geen nieuwe methode is toegevoegd dat de nieuwe objectklasse bevat.
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$
Deze problemen worden veroorzaakt door de gelijktijdige 02 vergelijkbare klasse (1 in src, 1 in jar-bestand hier is gateway.jar)
Antwoord 14
Om de oorspronkelijke vraag te beantwoorden. Volgens java-documenten hier:
“NoSuchMethodError” Wordt gegenereerd als een toepassing probeert een opgegeven methode van een klasse (statisch of instantie) aan te roepen en die klasse niet langer een definitie van die methode heeft.
Normaal gesproken wordt deze fout opgevangen door de compiler; deze fout kan alleen optreden tijdens runtime als de definitie van een klasse onverenigbaar is gewijzigd.
- Als het tijdens de uitvoering gebeurt, controleer dan of de klasse die de methode bevat zich in het klassenpad bevindt.
- Controleer of je een nieuwe versie van JAR hebt toegevoegd en of de methode compatibel is.
Antwoord 15
Ik heb dit probleem in Eclipse opgelost door een Junit-testbestand te hernoemen.
In mijn Eclipse-werkruimte heb ik een app-project en een testproject.
Het testproject heeft het app-project als een vereist project op het bouwpad.
Beginnen met het ophalen van de NoSuchMethodError.
Toen realiseerde ik me dat de klas in het testproject dezelfde naam had als de klas in het app-project.
App/
src/
com.example/
Projection.java
Test/
src/
com.example/
Projection.java
Na het hernoemen van de test naar de juiste naam “ProjectionTest.java” verdween de uitzondering.
Antwoord 16
NoSuchMethodError: ik heb een paar uur besteed aan het oplossen van dit probleem, en heb het uiteindelijk opgelost door de naam van het pakket te hernoemen , schoon te maken en te bouwen … Probeer eerst schoon te bouwen als het niet werkt, probeer dan de naam van de klasse of het pakket te hernoemen en schoon te maken bouwen… het zou gerepareerd moeten worden. Veel succes.
Antwoord 17
Ik kwam een soortgelijk probleem tegen toen ik de handtekeningen van methoden in mijn toepassing veranderde.
Het opschonen en opnieuw opbouwen van mijn project loste de “NoSuchMethodError” op.
Antwoord 18
Bovenstaand antwoord legt heel goed uit ..om maar één ding toe te voegen
Als je eclipse gebruikt, gebruik dan ctrl+shift+T en voer de pakketstructuur van de klasse in (bijv. gateway.smpp.PDUEventListener ), je zult alle jars/projecten vinden waar het aanwezig is. Verwijder onnodige jars uit klassenpad of voeg hierboven toe in klassenpad. Nu zal het de juiste oppikken.
Antwoord 19
Ik kwam een soortgelijk probleem tegen.
Caused by: java.lang.NoSuchMethodError: com.abc.Employee.getEmpId()I
Eindelijk heb ik vastgesteld dat de hoofdoorzaak het wijzigen van het gegevenstype van de variabele was.
Employee.java–> Bevat de variabele (EmpId) waarvan het gegevenstype is gewijzigd vanintinString.ReportGeneration.java–> Haalt de waarde op met behulp van de getter,getEmpId().
Het is de bedoeling dat we de pot opnieuw bundelen door alleen de gewijzigde klassen op te nemen. Omdat er geen verandering was in ReportGeneration.java, nam ik alleen de Employee.classop in het Jar-bestand. Ik moest het bestand ReportGeneration.classin de jar opnemen om het probleem op te lossen.
Antwoord 20
Ik heb hetzelfde probleem gehad. Dit wordt ook veroorzaakt wanneer er onduidelijkheid is in klassen. Mijn programma probeerde een methode aan te roepen die aanwezig was in twee JAR-bestanden op dezelfde locatie / klassepad. Verwijder één JAR-bestand of voer uw code zo uit dat er slechts één JAR-bestand wordt gebruikt. Controleer of u niet dezelfde JAR gebruikt of verschillende versies van dezelfde JAR die dezelfde klasse bevatten.
DISP_E_EXCEPTION [stap] [] [Z-JAVA-105 Java-uitzondering java.lang.NoSuchMethodError(com.example.yourmethod)]
Antwoord 21
Meestal wordt java.lang.NoSuchMethodError gevangen als compiler, maar soms kan het tijdens runtime optreden. Als deze fout optreedt tijdens runtime, kan de enige reden de wijziging in de klassenstructuur zijn waardoor deze incompatibel is geworden.
Beste uitleg: https://www.journaldev.com/14538/java- lang-nosuchmethoderror
Antwoord 22
Ik ben deze fout ook tegengekomen.
Mijn probleem was dat ik de handtekening van een methode heb gewijzigd, zoiets als
void invest(Currency money){...}
in
void invest(Euro money){...}
Deze methode is aangeroepen vanuit een context die lijkt op
public static void main(String args[]) {
Bank myBank = new Bank();
Euro capital = new Euro();
myBank.invest(capital);
}
De compiler zweeg over waarschuwingen/fouten, aangezien kapitaal zowel valuta als euro is.
Het probleem is ontstaan doordat ik alleen de klasse heb gecompileerd waarin de methode is gedefinieerd – Bank, maar niet de klasse van waaruit de methode wordt aangeroepen, die de methode main() bevat.
Dit probleem is niet iets dat u al te vaak tegenkomt, aangezien het project meestal handmatig wordt herbouwd of een Build-actie automatisch wordt geactiveerd, in plaats van alleen de ene gewijzigde klasse te compileren.
Mijn usecase was dat ik een .jar-bestand genereerde dat als hotfix moest worden gebruikt, dat de App.class niet bevatte omdat dit niet was gewijzigd. Het was logisch voor mij om het niet op te nemen, omdat ik de basisklasse van het oorspronkelijke argument door overerving bewaarde.
Het punt is dat wanneer je een klasse compileert, de resulterende bytecode een beetje statischis, met andere woorden, het is een hard-reference.
De originele gedemonteerde bytecode (gegenereerd met de javap-tool) ziet er als volgt uit:
#7 = Methodref #2.#22 // Bank.invest:(LCurrency;)V
Nadat de ClassLoader de nieuwe gecompileerde Bank.class heeft geladen, zal deze een dergelijke methode niet vinden, het lijkt alsof deze is verwijderd en niet is gewijzigd, vandaar de genoemde fout.
Hopelijk helpt dit.
Antwoord 23
Het probleem in mijn geval was om twee versies van dezelfde bibliotheek in het buildpad te hebben. De oudere versie van de bibliotheek had de functie niet, en de nieuwere wel.
Antwoord 24
Ik had een soortgelijk probleem met mijn Gradle Project met Intelij.
Ik heb het opgelost door het .gradle-pakket (zie onderstaande schermafbeelding) te verwijderen en het project opnieuw op te bouwen.
.gradle-pakket
Antwoord 25
Ik had hetzelfde probleem. Ik heb het retourtype van één methode gewijzigd en de testcode van die ene klasse uitgevoerd. Op dat moment kreeg ik te maken met deze NoSuchMethodError. Als oplossing heb ik de maven-builds één keer op de hele repository uitgevoerd, voordat ik de testcode opnieuw uitvoerde. Het probleem werd opgelost in de volgende enkele testrun.
Antwoord 26
Een voorbeeld van zo’n geval waarin deze fout optreedt:
Ik heb toevallig een domme fout gemaakt door toegang te krijgen tot privé-statische lidvariabelen op een niet-statische methode. Het wijzigen van de methode naar statisch loste het probleem op.
Antwoord 27
Waarom noemt niemand afhankelijkheidsconflicten? Dit veelvoorkomende probleem kan te maken hebben met meegeleverde afhankelijkheidspotten met verschillende versies.
Gedetailleerde uitleg en oplossing: https://dzone.com/articles/solving-dependency -conflicten-in-maven
Kort antwoord;
Voeg deze maven-afhankelijkheid toe;
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<rules>
<dependencyConvergence />
</rules>
</configuration>
</plugin>
Voer vervolgens deze opdracht uit;
mvn enforcer:enforce
Misschien is dit de oorzaak van uw probleem.