Wat zijn de mogelijke oorzaken voor abstractmethoderror?
Uitzondering in draad “Pool-1-thread-1” Java.lang.abStractmethodError:
org.apache.thrift.ProcessFunction.isOneway()Z
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:51)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at com.gemfire.gemstone.thrift.hbase.ThreadPoolServer$ClientConnnection.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Antwoord 1, Autoriteit 100%
Het eenvoudige antwoord is dit: een code probeert een methode te bellen die wordt verklaard abstract. Abstracte methoden hebben geen lichaam en kunnen niet worden uitgevoerd. Omdat je zo weinig informatie hebt verstrekt, kan ik niet echt meer uitspreken over hoe dit kan gebeuren, omdat de compiler meestal dit probleem vangt – Zoals hier beschreven, betekent dit dat de klasse moet zijn gewijzigd bij runtime.
Antwoord 2, Autoriteit 217%
Het betekent meestal dat u een oude versie gebruikt van een interface-implementatie die een nieuwe interfacemethode mist. Bijvoorbeeld Java.SQL.Connection-interface kreeg een nieuwe getchema-methode in 1.7. Als u 1,6 JDBC-stuurprogramma en oproepaansluiting hebt .GetSchema krijgt u abstractmethoderror.
Antwoord 3, Autoriteit 24%
Van documentation van abstractmethoderror
Gegooid wanneer een toepassing een abstracte methode probeert aan te roepen. Normaal gesproken,
deze fout wordt opgevangen door de compiler; deze fout kan alleen optreden tijdens run
tijd als de definitie van een klasse sindsdien onverenigbaar is veranderd
de momenteel uitgevoerde methode is het laatst gecompileerd.
Antwoord 4, autoriteit 7%
Een soort speciaal geval van het bovenstaande antwoord.
Ik had deze fout, omdat ik een spring-boot-starter-parentgebruikte (bijv. 2.1.0.RELEASEgebruikt spring-versie: 5.1.2.RELEASE) maar ik heb ookeen BOMtoegevoegd, die ook enkele veerafhankelijkheden definieerde, maar in een oudere versie (bijv. 5.0.9.RELEASE).
Dus een ding dat u kunt doen, is uw dependency treecontroleren (in Eclipse kunt u bijvoorbeeld de afhankelijkheidshiërarchie gebruiken) als u dezelfde versies gebruikt.
Een oplossing zou dus kunnen zijn dat u de lente-afhankelijkheden in uw BOMupgradet, een andere oplossing zou kunnen zijn dat u ze uitsluit (maar afhankelijk van het bedrag kan dit lelijk zijn).
Antwoord 5, autoriteit 3%
Als u een zipbestand van een project downloadt, nadat u het uitgepakt en geïmporteerd heeft in Android Studio, kunt u het project niet uitvoeren omdat deze fout is opgetreden.
Ik heb het probleem verholpen door mijn Android Studio te verwijderen en vervolgens de nieuwe versie te downloaden en te installeren.
Ik hoop echt dat het helpt.
Antwoord 6
Als je deze foutmelding krijgt op de geïmplementeerde methoden, zorg er dan voor dat je je afhankelijkheden correct hebt toegevoegd, zoals vermeld in deze thread.
Antwoord 7
Zoals Damian citeerde:
Normaal gesproken wordt deze fout opgevangen door de compiler; deze fout kan alleen
optreden tijdens runtime als […]
Ik had dezelfde fout die niet door de compiler werd opgevangen, maar tijdens runtime. Om het op te lossen heb ik alleen opnieuw gecompileerd zonder de code te wijzigen.
Antwoord 8
Als je deze fout krijgt op een verkleinde build die Proguard gebruikt, controleer dan of de klasse een POJO-klasse is en zo ja, sluit deze dan uit van de Proguard met behulp van de onderstaande regel:
-keep class your.application.package.pojo.** {*;}
Antwoord 9
Ik had dezelfde fout toen ik een eclipse-project importeerde in intellij ide.. Ik probeerde het te importeren zonder .iml-bestand en toen was mijn probleem opgelost