Вопрос

Я получаю NoSuchMethodError ошибка при запуске моей Java-программы.Что не так и как мне это исправить?

Это было полезно?

Решение

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

Посмотрите на трассировку стека ... Если исключение появляется при вызове метода для объекта в библиотеке, вы, скорее всего, используете отдельные версии библиотеки при компиляции и запуске. Убедитесь, что у вас правильная версия в обоих местах.

Если исключение появляется при вызове метода для объектов, созданных созданными вами классами , то процесс сборки кажется неисправным. Убедитесь, что файлы классов, которые вы фактически используете, обновляются при компиляции.

Другие советы

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

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

введите описание изображения здесь

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

введите описание изображения здесь

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

введите описание изображения здесь

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

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

java -verbose:class <other args>

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

...

[Загружен junit.framework.Утверждать из file:/C:/Program%20Files/junit3.8.2/junit.jar]

...

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

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

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

clean install

Это особенно вероятно, если вы написали объект и знаете, что у него есть метод. Работал на меня.

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

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

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

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

например ,

  • tomcat/common/ библиотека
  • mywebapp/ WEB-INF/ библиотека

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

бывший:

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).

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

<Ол>
  • Если вы используете jar, декомпилируйте и проверьте, имеет ли соответствующая версия jar соответствующий класс.
  • Проверьте, правильно ли вы скомпилировали класс из вашего источника.
  • Для меня это произошло потому, что я изменил тип аргумента в функции с Object a на String a. Я мог бы решить это с чистой и построить снова

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

    Попробуйте следующим образом: удалите все файлы .class из каталогов вашего проекта (и, конечно, все подкаталоги). Перестроить.

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

    Просто добавляю к существующим ответам. Я столкнулся с этой проблемой с котом в затмении. Я изменил один класс и сделал следующие шаги,

    <Ол>
  • Очистил и собрал проект в eclpise

  • mvn clean install

  • Перезапущенный кот
  • Тем не менее я столкнулся с той же ошибкой. Затем я очистил tomcat, очистил рабочий каталог tomcat и перезапустил сервер, и моя проблема исчезла. Надеюсь, это поможет кому-то

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

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

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

    После переименования теста на правильное имя " ProjectionTest.java " исключение ушло.

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

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

    Я столкнулся с подобной проблемой.

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

    Наконец, я определил причину изменения типа данных переменной. <Ол>

  • Employee.java - > Содержит переменную ( EmpId ), тип данных которой был изменен с int на String .
  • ReportGeneration.java - > Извлекает значение, используя получатель, getEmpId () .
  • Мы должны восстановить банку, включив только модифицированные классы. Поскольку в ReportGeneration.java не было никаких изменений, я включил в файл Jar только Employee.class . Мне пришлось включить файл ReportGeneration.class в банку, чтобы решить эту проблему.

    У меня была такая же проблема. Это также вызвано тем, что в классах есть неоднозначность. Моя программа пыталась вызвать метод, который присутствовал в двух файлах JAR, находящихся в одном и том же месте / пути к классам. Удалите один файл JAR или выполните свой код так, чтобы использовался только один файл JAR. Убедитесь, что вы не используете один и тот же JAR или разные версии одного и того же JAR, которые содержат один и тот же класс.

      

    DISP_E_EXCEPTION [шаг] [] [Z-JAVA-105 Java-исключение java.lang.NoSuchMethodError (com.example.yourmethod)]

    Чтобы ответить на первоначальный вопрос.Согласно java docs здесь:

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

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

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

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

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

    Я тоже сталкивался с этой ошибкой.

    Моя проблема была в том, что я изменил сигнатуру метода, что-то вроде

    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 ().

    С этой проблемой вы можете столкнуться не слишком часто, поскольку чаще всего проект перестраивается вручную или автоматически запускается действие «Построение», а не просто компилируется один измененный класс.

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

    Дело в том, что когда вы компилируете класс, результирующий байт-код является своего рода статическим , другими словами, это жесткая ссылка .

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

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

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

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

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

    У меня была похожая проблема с моим Gradle Project, использующим Intelij. Я решил это, удалив пакет .gradle (см. Скриншот ниже) и перестроив проект. .gradle Package

    NoSuchMethodError: Я потратил пару часов на исправление этой проблемы, наконец исправил ее, просто переименовав имя пакета, очистив и собрав ... Сначала попробуйте выполнить чистую сборку, если она не работает, попробуйте переименовать имя класса или имя пакета и очистить построить ... это должно быть исправлено. Удачи.

    У меня была такая же ошибка:

      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)
    

    Чтобы решить эту проблему, я проверил, во-первых, Диаграмму зависимостей модулей ( нажмите в своей POM комбинацию - > Ctrl + Alt + Shift + U или щелкните правой кнопкой мыши в POM - > Maven - > Показать зависимости ), чтобы понять, где именно был конфликт между библиотеками (Intelij IDEA). В моем конкретном случае у меня были разные версии зависимостей Джексона.

     введите описание изображения здесь  введите описание изображения здесь

    1) Итак, я прямо добавил в свой POM проекта самую высокую версию - 2.8.7 из этих двух.

    В свойствах:

    <jackson.version>2.8.7</jackson.version>
    

    И как зависимость:

    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <version>${jackson.version}</version>
    </dependency>
    

    2) Но это также можно решить с помощью Исключения зависимостей .

    По тому же принципу, что и в примере ниже:

      <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>
    

    Зависимость от нежелательной версии будет исключена из вашего проекта.

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

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top