У меня есть собственное приложение, которое запускает JVM и взаимодействует с ним через API JNI.Нативное приложение создает (сложный) объект JVM и передает его в качестве параметра при вызове метода.Проблема заключается в том, что в некоторых случаях при определенных входных данных JVM дает сбой во время выполнения метода с помощью:
Exception in thread "Thread-1" java.lang.IncompatibleClassChangeError
Я узнал, что это исключение выдается JVM, когда были сделаны некоторые несовместимые двоичные измененияк классу, используемому клиентом, который не знает об изменениях.Однако я не понимаю, как это могло произойти: в моем случае у JVM есть только одна толстая банка в пути к классам.Я не могу найти дублирующиеся классы в нем, и клиентский код всегда компилируется для создания толстого фляги.
On " Что вызывает java.lang.IncompatibleClassChangeError? " Я обнаружил, что тамдругая потенциальная причина: метод, вызываемый через JNI с объектами неправильного типа, например, в неправильном порядке.Итак, я добавил динамические проверки с IsInstanceOf, чтобы проверить тип любого объекта, переданного в JVM.К сожалению, все проверки успешны.
Как я могу отладить это?Исключение не имеет сообщения (например, нет сообщения типа «Ожидаемое нестатическое поле ChildClass.message»).Это может указывать на то, что это проблема, вызванная JNI, а не «более распространенным» случаем несовместимого двоичного изменения в библиотеке.
Я пытался -verbose:class, но я не вижу ничего странного вжурнал.Последний загруженный класс кажется обычной лямбда-функцией Scala, ничего странного:
[Loaded a.b.c.FastPrettyPrinter$$$Lambda$457/868352876 from a.b.c.FastPrettyPrinter$]
Существует ли исчерпывающий список или объяснение того, что может вызвать IncompatibleClassChangeError при вызове методов JVM через JNI ?