Décompiler Javaee

Question

Nous avons une application Java EE que le fournisseur n'existe plus (en raison de la faillite). Malheureusement, nous devons apporter quelques modifications à la fonctionnalité de l'application, ce qui signifie rétro-ingénierie de l'application Javaee.

Nous utilisons JD-GUI pour rétro-ingénieur environ 70% de l'application / classes, puis les ajuster manuellement pour construire dans Eclipse.

Cependant, les autres ne sont pas si faciles à construire car ils sont produits par des générateurs de code? Quels outils puis-je utiliser pour aider davantage?

Éditer:

Ceci est un exemple des difficultés:

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 }));

Il est difficile de savoir ce qui est

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

Answer 1

Donnez Jad (http://www.varaneckas.com/jad) un essai.

Le code problématique que vous montrez est équivalent à ce qui suit:

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;

La partie avec laquelle vous rencontrez des problèmes est la ligne 1, qui représente une variable locale ou un champ (peut-être statique). Le compilateur Java convertit l'expression 'TypeSystemHolder.class' en une invocation de GetClass stockant le résultat dans un champ statique. Cette initialisation se produit une fois dans chaque classe qui fait référence à «TypeSystemHolder.class» et le compilateur remplace chaque site d'appel qui utilise cette expression par un accès sur le terrain.

La plupart des décompilateurs ne parviennent pas à traduire cet idiome à l'appel d'origine vers «TypeSystemHolder.class», mais JAD gère cela assez bien. De plus, il existe un plug-in qui intègre JAD (et d'autres) dans Eclipse (http://jadclipse.sourceforge.net).

Malheureusement, les décompilateurs ne gèrent pas chaque séquence de code générée par un compilateur, donc une réécriture manuelle est toujours requise. Par exemple, le compilateur Java peut générer du code pour un bloc de gestion d'exception qui chevauche le code pour un autre bloc de traitement des exceptions. Les décompilateurs ne sont pas en mesure de séparer cela en deux blocs de capture. Dans ce cas, on voit généralement des instructions GOTO jonchées dans tout le code (non valide Java) ou le décompilateur abandonne simplement cette méthode.

En outre, vous avez raison de dire que ce code est généré. Plus précisément, il provient du compilateur XMLBeans, qui analyse le schéma XML XN et génère des classes de liaison pour Java; Permettre à un de sermer et désérialiser les documents XML se conformant à ce schéma. Si vous avez accès au schéma, il serait préférable d'incorporer des XMLBeans dans votre construction au lieu de décomposer ces classes.

Answer 2

Jeter un coup d'œil à suie. Il ne décompile pas en code source Java, mais utilise une couche intermédiaire compilable. Bien que ce soit encore une autre langue à apprendre, vous obtiendrez la flexibilité dont vous avez besoin.

De plus, si vous ne faites que de petits ajustements, vous pouvez simplement attaquer les fichiers individuellement et laisser le reste intact.