Gibt es einen Java Decompiler, der Aufrufe zu überladenen Methoden korrekt dekompilieren kann?

Krakatau behandelt alle überladenen Methoden korrekt, sogar Methoden, die auf primitive Typen überladen sind, was die meisten Decompiler falsch verstehen. Es werden immer Argumente auf den genauen Typ der aufgerufenen Methode angewendet, so dass der Code möglicherweise unübersichtlicher als nötig ist, aber zumindest ist er korrekt.

Offenlegung: Ich bin der Autor von Krakatau.

Hallo mihi,

Entschuldigung für die späte Antwort. Ich kopiere meine Antwort von Ссылка

Ihr Problem ist eigentlich ein bekanntes Problem. Mal sehen:

1) Reiner Bytecode enthält keine Informationen über den Typ der Objektvariablen, daher werden s1 und s2 im ersten Durchgang als Objekt deklariert.

2) Decompiler bemüht sich, jeder Variablen den bestmöglichen Typ zuzuweisen (= "schmalstes Typsprinzip", implementiert in Fernflower). So werden s1 und s2 korrekt als Instanzen von String identifiziert.

3) Aufruf von doPrint gibt uns einen direkten Link zur richtigen Methode
private static void DoPrint (Objekt s1)

4) Alles in Ordnung soweit, oder? Jetzt haben wir eine String-Variable s1 an eine Funktion übergeben, die ein Object erwartet. Müssen wir es werfen? Nicht als solches würden Sie denken, da Objekt ein Supertyp von String ist. Und dennoch - weil es innerhalb derselben Klasse eine andere Funktion mit demselben Namen und einer anderen Parametersignatur gibt. Also müssen wir die ganze Klasse analysieren, um herauszufinden, ob ein Cast benötigt wird oder nicht.

5) Im Allgemeinen bedeutet dies, dass wir ALLE referenzierten Klassen in ALL-Bibliotheken einschließlich der Java-Laufzeit analysieren müssen. Eine riesige Menge Arbeit! In der Tat wurde dieses Feature in einigen Alpha-Versionen von Fernflower implementiert, hat es aber aufgrund von Performance- und Speicherproblemen noch nicht in die Produktion geschafft. Andere erwähnte Decompiler haben diese Fähigkeit nicht im Design.

Ich hoffe, ich habe die Dinge etwas geklärt:)

Das JadClipse Eclipse-Plugin zum Dekompilieren bietet auch den JODE-Decompiler, den Sie vielleicht ausprobieren möchten. Ich benutze es, wenn Jad aufgibt.

Auch der Dava-Decompiler verwendet Soot, der - beim letzten Mal - sehr ehrgeizig beim Rekonstruieren des ursprünglichen Java-Codes war. Ich habe es nicht mit Ihrem Beispiel versucht, aber Sie möchten vielleicht einen Blick darauf werfen. Ссылка

Procyon sollte überladene Methodenaufrufe korrekt behandeln. Wie bei Krakatau fügt Procyon anfänglich für jedes Methodenargument Umwandlungen ein, die nicht genau mit der Zielmethode übereinstimmen. Die meisten davon werden jedoch in einer späteren Phase der Dekompilierung entfernt, die redundante Umwandlungen identifiziert und eliminiert. Procyon wird nur Umwandlungen von Aufrufargumenten entfernen, wenn es sicherstellen kann, dass dies nicht dazu führt, dass die Aufrufbindung an eine andere Methode erfolgt. Wenn beispielsweise .class die Methode nicht deklarieren kann, wird sie nicht versuchen, die Umwandlungen zu entfernen, weil sie nicht wissen kann, welche Überladungen einen Konflikt verursachen könnten.