Frage

Wir haben eine Java EE -App, die der Anbieter nicht mehr existiert (aufgrund von Insolvenz). Leider müssen wir einige Änderungen an der Funktionalität der App vornehmen, und dies bedeutet Reverse Engineering in der Javaee -App.

Wir verwenden JD-GUI, um etwa 70% der App/Klassen umzukehren, und optimieren sie dann manuell, um in Sonnenfinsternis aufzubauen.

Die Pauses sind jedoch nicht so einfach zu bauen, weil sie von Codegeneratoren hergestellt werden? Mit welchen Tools kann ich weiter helfen, um weiter zu helfen?

Bearbeiten:

Dies ist ein Beispiel für die Schwierigkeiten:

return ((SchemaTypeSystem)Class.forName(
    "org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl",
    true,
    class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder.getClassLoader())
        .getConstructor(new Class[] { Class.class })
        .newInstance(new Object[] { TypeSystemHolder.class }));

Es ist schwer zu wissen, was ist

class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder.getClassLoader())

Keine korrekte Lösung

Andere Tipps

Gib Jad (http://www.varaneckas.com/jad) ein Versuch.

Der problematische Code, den Sie zeigen, entspricht Folgendes:

1) Class class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder;
2) ClassLoader loader = class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder.getClassLoader();
3) Class type = Class.forName("org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl", true, loader);
4) Constructor ctor = type.getConstructor(Class.class);
5) Object obj = ctor.newInstance(TypeSystemHolder.class);
6) SchemaTypeSystem result = (SchemaTypeSystem) obj;
7) return result;

Der Teil, mit dem Sie Probleme haben, ist Zeile 1, die eine lokale Variable oder ein Feld darstellt (möglicherweise statisch). Der Java -Compiler wandelt den Ausdruck "Typensysteminhaber" in eine Aufruf von GetClass um und speichert das Ergebnis in einem statischen Feld. Diese Initialisierung erfolgt einmal in jeder Klasse, in der der Typensystem des Typens. Class 'und der Compiler jeden Call -Ort ersetzt, der diesen Ausdruck mit einem Feldzugriff verwendet.

Die meisten Dekompilierer übersetzen diese Redewendung nicht wieder in den ursprünglichen Aufruf an 'typeSystemholder.class', aber Jad verarbeitet dies recht gut. Darüber hinaus gibt es ein Plug-In, das JAD (und andere) in die Eclipse integriert (http://jadclipse.sourceforge.net).

Leider verarbeiten Dekompiler nicht jede von einem Compiler generierte Codesequenz, sodass immer ein manuelles Umschreiben erforderlich ist. Zum Beispiel kann der Java -Compiler Code für einen Ausnahmeberufelblock generieren, der sich mit Code für einen anderen Ausnahmebereichblock überschneidet. Dekompiler können dies nicht wieder in zwei Fangblöcke trennen. In diesem Fall sieht man normalerweise GOTO -Anweisungen im gesamten Code (nicht gültiger Java), oder der Dekompiler gibt diese Methode einfach auf.

Sie haben auch Recht, dass dies generierten Code ist. Insbesondere stammt es aus dem XMLBeans -Compiler, der das XN XML -Schema analysiert und Bindungsklassen für Java erzeugt; Ermöglichen, XML -Dokumente zu serailieren und zu deverialisieren, die diesem Schema entsprechen. Wenn Sie Zugriff auf das Schema haben, wäre es besser, XMLBeans in Ihren Build einzubeziehen, anstatt diese Klassen zu zerlegen.

Sich ansehen Ruß. Es dekompiliert nicht zum Java -Quellcode, verwendet jedoch eine kompilierbare Zwischenschicht. Während es eine weitere Sprache ist zu lernen, erhalten Sie die Flexibilität, die Sie benötigen.

Wenn Sie nur kleine Verbesserungen vornehmen, können Sie nur die Dateien einzeln angreifen und den Rest intakt lassen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top