Procyon: Dekompilieren bestimmter Klassen von Glas

Question

Ich versuche, bestimmte Klassen aus einer Jar-Datei mit dem com.strobel.decompiler.Decompiler Decompiler aus der Procyon-Bibliothek zu dekompilieren.

Dies ist mein aktueller Ansatz:

// jar file containing foo.class and bar.class 
JarFile myJar = new JarFile("my.jar"); 
// creating decompiler settings 
DecompilerSettings settings = new DecompilerSettings(); 
// set type loader to jar file 
settings.setTypeLoader(new JarTypeLoader(myJar)); 

StringWriter foo = new StringWriter(); 
Decompiler.decompile("com.myjar.foo", new PlainTextOutput(foo), settings); 
System.out.print(foo.toString()); 

Aber das macht nur Druck: !!! ERROR: Failed to load class com.myjar.foo.

Ich bin ziemlich sicher, ich etwas für das Laden von Klassen aus my.jar die Klassen verpaßt. (Dachte, dies würde getan werden, indem man den Typ loader setzt).

Die eigentliche Frage: Wie dekompiliere ich eine bestimmte Klasse aus einer JAR-Datei mit dem Procyon Decompiler? (Was ich falsch in meinem Ansatz getan habe?)

Greets, NopMind.

Answer 1

Die Antwort ist einfach: Klassen-Namespaces werden nicht mit . dann mit / vorangestellt.

So funktioniert nur ersetzen Decompiler.decompile("com/myjar/foo", ...) funktioniert gut. Sorry

Answer 2

Sie können Procyon dazu bringen, mit Klassennamen fehlerverzeihender zu werden. Alles, was Sie tun müssen, ist Ihr primäres Ladeprogramm in eine InputTypeLoader einzupacken.

settings.setTypeLoader(new InputTypeLoader(new JarTypeLoader(myJar))); 

Die InputTypeLoader wird zunächst versuchen, Klassen zu finden, Ihren primären Typ Loader, und wenn es keine Übereinstimmung gefunden wird, wird es versuchen, ‚Massage‘ der Klassenname. Es wird vom Befehlszeilen-Decompiler verwendet, in dem Benutzer versuchen können, ein alternatives Formular zu verwenden, z. B. . anstelle von / oder $. Wenn zum Beispiel eine Klasse com/jar/Foo existiert und der Benutzer versucht, com.jar.Foo zu dekompilieren, sollte es in der Lage sein, dies zu lösen. Es sollte auch für innere Klassen funktionieren, z. B. kann com.jar.Foo.Bar verwendet werden, um com/jar/Foo$Bar zu lokalisieren. Es liegt an dir, ob du das benutzen willst.

Ich habe eine Empfehlung für Sie, aber: Sie wollen wahrscheinlich nicht eine JarTypeLoader als primären Typ Loader werden. Wenn Sie das tun, wird Procyon nur nach Klassen in Ihrem spezifischen Glas suchen. Das mag klingen mögen, was Sie wollen, aber es ist wahrscheinlich nicht.

Sehen Sie, es gibt einige Optimierungen, die Procyon nur ausführen kann, wenn es die Abhängigkeiten einer Klasse auflösen und analysieren kann. Wenn zum Beispiel ein Methodenaufruf dekompiliert wird, fügt Procyon anfänglich Umwandlungen vor jedem Argument ein, das nicht exakt die Parametertypen der Zielmethode entspricht. Dies muss für die Korrektheit getan werden, da die Methode Überladungen haben könnte, und das Entfernen dieser Umwandlungen könnte dazu führen, dass der Aufruf an die falsche Methode gebunden wird. Wenn jedoch Procyon die Klasse finden kann, die die Methode und deklariert hat, kann sie alle ihre Vorfahrklassen finden, dann kann sie herausfinden, welche Abbilder sicher entfernt werden können, während sie noch an die richtige Methode binden. Dann werden diese überflüssigen Umwandlungen entfernt, was zu einer saubereren Ausgabe führt. Das ist nur ein Beispiel - es gibt auch andere.

Hier ist, was ich empfehlen würde mit:

settings.setTypeLoader(
    new InputTypeLoader(    // allow more relaxed type names 
     new CompositeTypeLoader(
      new JarTypeLoader(myJar), // search your specific jar first 
      new ClasspathTypeLoader() // fall back to your classpath 
     ) 
    ) 
); 

Dies gibt die Möglichkeit, Procyon Suche nach Abhängigkeiten in der JRE und überall dort, wo in Ihrem Classpath sein geschieht.