изменение возвращаемого типа метода дает java.lang.NoSuchMethodError

Question

Я изменил тип возврата одного метода в интерфейсе библиотеки. Ранее это было недействительным, и я изменил его, чтобы вернуть объект. Я не изменил код в моем модуле, так как я не хотел ничего делать с возвращенным объектом (это было для другого модуля) Я скомпилировал свой модуль с новой библиотечной флягой и запустил модульные тесты, которые работали нормально, но когда я толкнул флягу вместе с флягой библиотеки в производство и запустил модуль, я получаю java.lang.NoSuchMethodError для метода, который я изменил в интерфейсе. Я изменил как интерфейс, так и реализацию, оба находятся в библиотеке jar, и я использую аннотации Spring для добавления объекта реализации в мой модуль. Какова возможная причина этой проблемы?

Answer 1

Похоже, вы не все перекомпилировали или не отправили все перекомпилированные файлы jar в prod.

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

Answer 2

В байт-коде Java возвращаемый тип метода является частью сигнатуры метода, и он различает два метода с одинаковым именем и одинаковыми параметрами (это то, что вы не можете сделать в языке Java). Итак, ваш код, который вызывает этот метод, каким-то образом не был перекомпилирован, и он все еще пытается вызвать метод, который возвращает void.

Answer 3

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

Answer 4

Мы всегда настраиваем наш производственный (и QA) процесс сборки для очистки всех классов и перекомпиляции именно из-за подобных проблем. Иногда эвристика зависимостей компилятора ошибается (особенно когда у вас есть статическое конечное поле, определенное как константа, где компилятор просто оптимизирует всю зависимость).

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

Answer 5

Вы очистили свою рабочую среду развертывания, так как кажется, что сигнатура старого метода все еще где-то висит?