Класс пользователя бросил исключение: java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.JsonMappingException [duplicate]

Если ваше имя файла отличается от имени класса, которое содержит основной метод, возможно, это может быть причиной этой ошибки.

Я столкнулся с аналогичной проблемой.

Caused by: java.lang.NoSuchMethodError: com.abc.Employee.getEmpId()I

Наконец, я определил, что основной причиной было изменение типа данных переменной.

1. Employee.java -> Содержит переменную (EmpId), тип данных которой изменен с int на String.
2. ReportGeneration.java - -> Извлекает значение с помощью getter, getEmpId().

Мы должны отменить банку, включив только измененные классы. Поскольку изменений в ReportGeneration.java не было, я включил только файл Employee.class в Jar. Мне пришлось включить файл ReportGeneration.class в банку, чтобы решить проблему.

Эти проблемы вызваны использованием одного и того же объекта в тех же двух классах. Добавленные объекты не содержат нового метода, добавлен новый класс объектов.

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$ 

Эти проблемы вызваны сопутствующим 02 аналогичным классом (1 в src , 1 в файле jar здесь gateway.jar)

Если вы пишете webapp, убедитесь, что у вас нет противоречащих друг другу версий jar в каталоге глобальной библиотеки вашего контейнера, а также в вашем приложении. Возможно, вам не обязательно знать, какой jar используется загрузчиком классов.

, например.

• tomcat / common / lib
• mywebapp / WEB-INF / lib

Я чувствую твою боль. Вы можете изучать программирование из книги, но когда дело доходит до работы с Eclipse или Visual Studio, его кошмар a ^ & amp; ^ & amp; n сделать что-то простое, например добавить библиотеку. Все ждут, что вы будете знать, как им пользоваться, и если вы этого не сделаете, вы можете опросить свой вопрос. Проблема в том, что если вы не работаете в офисе или не знаете кого-либо, кто может задавать эти вопросы, то почти невозможно понять это. Во всяком случае ...

У меня была твоя проблема, и именно так я ее исправил. Следующие шаги являются рабочим способом для добавления библиотеки. Я сделал первые два шага вправо, но я не сделал последнего, перетащив файл «.jar» прямо из файловой системы в папку «lib» моего проекта eclipse. Кроме того, мне пришлось удалить предыдущую версию библиотеки как из пути сборки, так и из папки «lib».

Если кто-нибудь знает более подходящий способ добавить / обновить библиотеку, пожалуйста, перезвоните.

Шаг 1 - Добавить .jar для построения пути

[/g4]

Шаг 2 - Связанные источники и javadocs (необязательно)

[/g5]

Шаг 3 - На самом деле перетащите файл .jar в папку «lib» (необязательно)

[/g6]

Я исправил эту проблему в Eclipse, переименовав тестовый файл Junit. В моем рабочем пространстве Eclipse у меня есть проект приложения и тестовый проект. Проект Test имеет проект App как необходимый проект на пути сборки.

Началось получение NoSuchMethodError. Затем я понял, что класс в проекте Test имеет то же имя, что и класс в проекте приложения.

App/  
  src/
     com.example/  
       Projection.java
Test/  
  src/
     com.example/
       Projection.java

После переименования теста на правильное имя «ProjectionTest.java» исключение исчезло.

Это означает, что соответствующий метод отсутствует в классе:

1. Если вы используете jar, тогда декомпилируйте и проверьте, имеет ли соответствующая версия jar соответствующий класс.
2. Проверьте, не скомпилирован ли ваш класс из вашего источника.

Обратите внимание, что в случае отражения вы получаете NoSuchMethodException, а с неотражающим кодом вы получаете NoSuchMethodError. Я, как правило, смотрю в самых разных местах, когда сталкиваюсь с одним против другого.

Если вы используете maven или другую фреймворк, и вы получаете эту ошибку случайно, попробуйте выполнить «чистую установку», особенно если вы написали объект и знаете, что у него есть метод. Работал для меня.

Это обычно возникает при использовании системы сборки, такой как Apache Ant , которая только компилирует java-файлы, когда java-файл является более новым, чем файл класса. Если подписи метода изменяются, а классы используют старую версию, вещи не могут быть скомпилированы правильно. Обычным решением является полная перестройка (обычно «ant clean», затем «ant»).

Иногда это также может быть вызвано при компиляции с одной версией библиотеки, но работает с другой версией.

У меня возникла аналогичная проблема, когда я менял сигнатуры методов в своем приложении. Очистка и восстановление моего проекта разрешили «NoSuchMethodError».

Если у вас есть доступ к изменению параметров JVM, добавление подробного вывода должно позволять вам видеть, какие классы загружаются из JAR.

java -verbose:class <other args>

Когда ваша программа запущена, JVM должна сбрасывать к стандартной информации, такой как:

...

[Загружено junit.framework.Assert из файла: / C: /Program%20Files/junit3.8.2/junit .jar]

...

Я тоже столкнулся с этой ошибкой.

Моя проблема заключалась в том, что я изменил подпись метода, например

void invest(Currency money){...}

в

void invest(Euro money){...}

Этот метод был вызван из контекста, подобного

public static void main(String args[]) {
    Bank myBank = new Bank();

    Euro capital = new Euro();
    myBank.invest(capital);
}

. Компилятор молчал в отношении предупреждений / ошибок, поскольку капитал - это как валюта, так и евро.

Проблема возникла из-за того, что я только скомпилировал класс, в котором был определен метод - Bank, но не класс, из которого вызывается метод, который содержит метод main ().

Эта проблема не является чем-то, с чем вы можете столкнуться слишком часто, так как чаще всего проект перестраивается вручную или автоматически запускается действие Build, вместо того, чтобы просто компилировать один модифицированный класс.

Мое заявление состояло в том, что я создал .jar, который должен был использоваться как исправление, которое не содержало App.class, поскольку это не было изменено. Мне было разумно не включать его, поскольку я сохранил наследование базового класса исходного аргумента.

Дело в том, что при компиляции класса полученный байт-код является видом static , другими словами, это hard-reference .

Оригинальный дизассемблированный байт-код (сгенерированный с помощью инструмента javap) выглядит следующим образом:

 #7 = Methodref          #2.#22         // Bank.invest:(LCurrency;)V

После того, как ClassLoader загружает новый скомпилированный Bank.class, он не найдет такого метода, он выглядит так, как будто он был удален и не изменен, поэтому именованная ошибка.

Надеюсь, это поможет.

Выше ответ объясняет очень хорошо. Просто добавьте одно. Если вы используете использование eclipse, используйте ctrl + shift + T и введите структуру пакета класса (например: gateway.smpp.PDUEventListener), вы найдете все банки / проекты где он присутствует. Удалите ненужные банки из classpath или добавьте выше в путь класса. Теперь он подберет правильный.

Это также может быть результатом использования отражения. Если у вас есть код, который отражает класс, и извлекает метод по имени (например: с Class.getDeclaredMethod("someMethodName", .....)), то в любое время, когда имя метода изменяется, например, во время рефакторинга, вам нужно будет помнить, чтобы обновить параметры до метода отражения для соответствия новой сигнатуре метода, или вызов getDeclaredMethod вызовет NoSuchMethodException.

. Если это причина, то трассировка стека должна показывать точку, в которой используется метод отражения, и вы Вам просто нужно обновить параметры, чтобы они соответствовали фактической сигнатуре метода.

По моему опыту это иногда возникает при модульном тестировании частных методов / полей и использовании класса TestUtilities для извлечения полей для проверки теста. (Как правило, с устаревшим кодом, который не был разработан с учетом модульного тестирования.)

Я только что решил эту ошибку, перезапустив мой Eclipse и запустив applcation. Причина моего случая может быть связана с тем, что я заменяю исходные файлы без закрытия моего проекта или Eclipse. Это вызвало разную версию классов, которые я использовал.

В большинстве случаев java.lang.NoSuchMethodError пойман компилятором, но иногда это может произойти во время выполнения. Если эта ошибка возникает во время выполнения, единственной причиной может быть изменение структуры класса, которое сделало ее несовместимой.

Лучшее объяснение: https://www.journaldev.com/ 14538 / Java-Ланг-NoSuchMethodError

Для меня это произошло потому, что я изменил тип аргумента в функции, от Object a, до String a. Я мог бы решить это с чистой и построить снова

Чтобы ответить на исходный вопрос. В соответствии с java docs здесь :

«NoSuchMethodError» Брошено, если приложение пытается вызвать указанный метод класса (статический или экземпляр), а этот класс no более длинное определение этого метода.

Обычно эта ошибка улавливается компилятором; эта ошибка может возникнуть только во время выполнения, если определение класса несовместимо изменилось.

1. Если это происходит во время выполнения, проверьте, что класс, содержащий этот метод, находится в пути к классу.
2. Проверьте, добавлена ​​ли новая версия JAR, и метод совместим .

Попробуйте этот путь: удалите все .class файлы в ваших каталогах проектов (и, конечно же, все подкаталоги). Rebuild.

Иногда mvn clean (если вы используете maven) не очищает файлы .class, созданные вручную javac. И эти старые файлы содержат старые подписи, что приводит к NoSuchMethodError.