Bytecode eines Methodenaufrufs

[Mario_H]

Hallo.

Ich ein Programm schreiben um zu überprüfen, ob in gegebenen .java-Dateien bestimmte Methoden aus anderen, ebenfalls gegeben, .java-Dateien aufgerufen werden.

Den Vollqualifizierten Namen der Methoden kann ich schon ermitteln, das Problem ist, einen Methodenaufruf zu qualifizieren:
Die zu einem aufrufenden Objekt gehörigen Klassen müssen anhand des Objektnamens, dem Rückgabewert einer Methode, etc. ermittelt werden. (Um Namensgleichheiten der Methoden auszuschließen. z.B. toString())
Die Verschiedenen Dateien eines Packages sowie die Imports müssen ebenfalls ausgewertet werden. Und zu guter letzt kommt noch die Vererbung dazu.
(Kurz gesagt.)


Meine Idee war, dem Compiler die ganze 'Zuordnungsarbeit' zu überlassen und anstelle der .java-Dateien den erzeugten Bytecode auszuwerten.
Da aber das einzige, das ich über Bytecode (in diesem Zusammenhang) weiß ist, dass Methoden und Klassennamen im Klartext dargestellt werden, muss ich leider um Hilfe bitten, wie denn ein so ein Methodenaufruf im Bytecode genau aussieht, und wie ich die zugehörige Klasse ermitteln kann.


Vielen Dank im Voraus.

Gruß Mario.

 

[Mario_H]

Ich habe auch noch eine alternative Idee.

Es geht darum, dass ich besagte Methoden aus dem Code entferne, wenn ich keine Datei finde, in denen sie aufgerufen werden.


Der andere Ansatz ist, ich entferne sie vorher, kompiliere, werte die Kompiler Errors aus und stell die Methoden ggf. wieder her.
Vorraussetzung ist, dass der Kompiler-Error aussagekräftig genug ist, um die Datei wiederzufinden, in der eine Methode wiederhergestellt werden muss.


Hat jemand ein bisschen ne Ahnung, welche Meldungen in dem Fall ausgegeben werden und/oder eine Referenz über die Compilerfehler?


Danke.

 

[sparrow]

Das klingt ein wenig so als wenn du den Code "verbessern" möchtest, also aufräumen und optimieren.

Das klingt nach einem Obfuscator von denen du hier eine ganze Liste für Java findest.

Ich habe früher viel damit gearbeitet, allerdings nicht um das Decompilieren schwerer zu machen sondern weil ich Programme und Spiele für Handys geschrieben habe, und ein Obfuscator führt zu einer kleineren Klasse, das tut er unter anderem indem:

- Sämtliche Kommentare Kommentare und Debugging-Informationen gelöscht werden
- Methoden und Klassen umbenannt werden, und zwar in sehr kurze Namen (a, b, c...)
- Methoden auf Effektivität geprüft werden und nicht verwendete Methoden kurzerhand gelöscht werden.


Beste Grüße
Sparrow

 

[Mario_H]

Danke für den Tipp.

Ein Obfuscator war auch meine erste Idee.

Aber es geht darum als @deprecated deklarierte Methoden zu entfernen, sofern nicht doch noch gebraucht werden.
Und das in dem Code, mit dem auch später weitergearbeitet wird, also von wegen Kommentaren etc.

Das Auffinden und entfernen steht schon, das Problem war das erkennen ob so eine Methode nicht doch noch gebraucht wird.

Aber ich arbeite gerade an einem vielversprechenden Ansatz.
Ich lass mit vom Compiler mittels "-deprecation" sagen, welche deprecated-Methoden noch verwendet werden, alle anderen können raus. Ich denke das wird klappen.

 

[SamHotte]

Wenn du die ganzen Quelltexte hast, lässt sich das doch bspw. in Eclipse einfach über die Suche lösen ...

 

[Mario_H]

Nein, diese Möglichkeiten hab ich im Vorfeld schon geprüft u.a. mit Hilfe dieses Forums.

Es dreht sich um mehrere Tausend .java-Dateien und Sinn meines Tools ist es eben nicht 'von Hand' jede Datei einzeln durchsuchen, Anfang finden, Ende Finde, <Entf.> drücken ;-) zu müssen..

 

[Wildcard]

- Methoden auf Effektivität geprüft werden und nicht verwendete Methoden kurzerhand gelöscht werden.

Welcher Obfuscator macht den sowas? Ziemlich ungünstig wenn man Reflection verwendet.... :autsch:

 

[sparrow]

- Methoden auf Effektivität geprüft werden und nicht verwendete Methoden kurzerhand gelöscht werden.

Welcher Obfuscator macht den sowas? Ziemlich ungünstig wenn man Reflection verwendet.... :autsch:

Jeder Obfuscator der den Code auch auf Größe trimmt.
Gerade bei Handys wo teileise die .jar-Archive nur wenige kb groß sein dürfen ist es ganz hilfreich durch so etwas Größe zu sparen.

Methoden die als public deklariert sind werden natürlich ausgenommen, diese werden auch nicht umbenannt.