Я получаю:
NoSuchMethodError: com.foo.SomeService.doSmth()Z
Я правильно понимаю, что этот 'Z' означает, что возвращаемый тип doSmth() является логическим? Если true, то такого метода действительно не существует, потому что этот метод возвращает некоторую коллекцию. Но, с другой стороны, если я вызываю этот метод, я не назначаю его возвращаемое значение для любой переменной. Я просто вызываю этот метод следующим образом:
service.doSmth();
Любые идеи, почему эта ошибка возникает? Все необходимые файлы JAR существуют, и все остальные методы из этого класса, похоже, существуют.
Похоже, что метод существует в пути к классам во время компиляции, но не во время запуска вашего приложения.
Я не думаю, что тип возврата - проблема. Если бы это было так, это не скомпилировалось бы. Компилятор выдает ошибку, когда вызов метода неоднозначен, и это происходит, когда два метода отличаются только возвращаемым типом.
Обычно эта ошибка улавливается компилятором; эта ошибка может возникнуть только во время выполнения, если определение класса несовместимо изменилось.
Вкратце - файл класса /jar во время выполнения - это не то же самое, что вы использовали во время компиляции.
Это, вероятно, разница между вашим пути времени компиляции и вашим путём класса времени выполнения.
Вот что происходит:
doSmth(), возвращающий логическое значение. Байт-код относится к методу doSmth()Z.doSmth()Z не найден. Вместо этого найден метод, возвращающий коллекцию.Чтобы исправить эту проблему, проверьте путь к классу (время компиляции).
В текущем ответе просто скажу вам, почему происходит сбой. Обычно даже лучше узнать, как исправить проблемы. Как уже упоминалось, обычно проблема заключается в том, что вы создали свою программу, но при ее запуске или ее экспорте библиотека не включена. Таким образом, решение...
Если вы работаете, проверьте конфигурацию запуска Выберите вкладку "Выполнить" → "Выполнить конфигурации" → Выберите конфигурацию, в которой вы работаете, → "Проверить вкладку" Класс "- > Убедитесь, что библиотеки, которые вам нужны,
Если вы экспортируете (например, файл войны), выполните следующие действия: Выберите проект → Выбрать свойства → Выбрать сборку развертывания → Нажмите Добавить → Выбрать записи пути Java Build → Выберите библиотеки, которые вы хотите включить в экспортированный файл (например, военный файл)
В обоих случаях убедитесь, что библиотека, на которую вы ссылаетесь, включена.
Другими частыми проблемами для этой ошибки являются неправильный тип параметров или видимость, но затем компилятор обнаружит ошибку перед запуском. В этом случае просто проверьте документацию в соответствии с видимостью функции и пакета и убедитесь, что библиотека найдена в Java Build Path в ваших свойствах проекта.
Я заметил эту проблему при тестировании некоторых экспериментальных изменений в нескольких связанных проектах после обновления их из SVN в Eclipse.
В частности, я обновил все проекты из SVN и вернул файл .classpath, а не редактировал его вручную, чтобы все было просто.
Затем я снова добавил связанные проекты к пути, но забыл удалить связанные банки. Так возникла проблема для меня.
Таким образом, очевидно, что время выполнения использовало файл jar, в то время как компилятор использовал файлы проекта.
Может быть, все-таки может помочь кто-то, но это исключение может произойти и тогда, когда у вас есть на пути к классу два класса в разных файлах jar, которые имеют одинаковую точную подпись, но у них нет одинаковых общедоступных методов.
Например:
В файле mylibrary1.jar у вас есть класс com.mypackage.mysubpackage.MyClass с методом doSmth()
В файле mylibrary2.jar у вас есть класс com.mypackage.mysubpackage.MyClass без метода doSmth()
При поиске класса загрузчик классов может найти первый mylibrary2.jar в зависимости от приоритета пути, но не может найти метод в этом классе.
Убедитесь, что у вас нет одного класса пакетов + в двух разных файлах.
Другим способом это может случиться и трудно найти:
Если подпись метода во внешней банке изменяется так, что в среде IDE отсутствует ошибка, поскольку она по-прежнему совместима с тем, как вы ее называете, класс не может быть повторно скомпилирован.
Если ваша сборка проверяет файлы на наличие изменений и только затем перекомпилирует их, класс не может быть перекомпилирован в процессе сборки.
Поэтому, когда вы его запускаете, это может привести к этой проблеме. Хотя у вас есть новая банка, ваш собственный код ожидает еще старого, но никогда не жалуется.
Чтобы сделать это сложнее, это зависит от jvm, если он может обрабатывать такие случаи. Так что в худшем случае он работает на тестовом сервере, но не на реальном компьютере.