Есть ли какой-либо Декомпилятор Java, который может правильно декомпилировать вызовы к перегруженным методам? [закрытый]

Плагин JadClipse Eclipse для декомпиляции также предоставляет декомпилятор JODE, который вы можете попробовать. Я использую его, когда Jad сдается.

Также декомпилятор Dava использует Soot, который - в последний раз, когда я смотрел - был очень амбициозен в реконструкции оригинального кода Java. Я не пробовал с вашим примером, но вы можете взглянуть. http://www.sable.mcgill.ca/dava/

Привет, михи,

извиняюсь за поздний ответ. Я копирую свой ответ с http://www.reversed-java.com/fernflower/forum?threadfolder=2_DE

Ваша проблема на самом деле хорошо известна. Посмотрим:

1) Чистый байт-код не содержит никакой информации о типе переменных объекта, поэтому на первом проходе s1 и s2 объявляются как Object.

2) Декомпилятор изо всех сил пытается присвоить каждой переменной наилучший из возможных типов (= «принцип самого узкого типа», реализованный в Fernflower). Таким образом, s1 и s2 правильно определены как экземпляры String.

3) Вызов doPrint дает нам прямую ссылку на правильный метод
private static void doPrint (Object s1)

4) Пока все в порядке, верно? Теперь у нас есть строковая переменная s1, переданная функции, которая ожидает объект. Нам нужно его бросить? Вы можете подумать, что нет, поскольку Object - это супертип String. И все же мы это делаем - потому что в том же классе есть еще одна функция с тем же именем и другой подписью параметра. Поэтому нам нужно проанализировать весь класс, чтобы выяснить, нужно ли приведение.

5) Вообще говоря, это означает, что нам нужно проанализировать ВСЕ классы, на которые есть ссылки, во ВСЕХ библиотеках, включая среду выполнения java. Огромный объем работы! Действительно, эта функция была реализована в какой-то альфа-версии Fernflower, но еще не вошла в производство из-за снижения производительности и памяти. В других упомянутых декомпиляторах эта возможность отсутствует по замыслу.

Надеюсь, я немного прояснил ситуацию :)