Decompila Javaee

Question

Abbiamo un'app Java EE che il fornitore non esiste più (a causa del fallimento). Sfortunatamente dobbiamo apportare alcune modifiche alla funzionalità dell'app, e questo significa reverse ingegneria dell'app Javaee.

Usiamo JD-GUI per ingegnere inversa circa il 70% dell'app/lezioni, quindi modificarli manualmente per costruire in Eclipse.

Tuttavia, i resti non sono così facili da costruire perché sono prodotti dai generatori di codice? Quali strumenti posso usare per aiutare ulteriormente?

Modificare:

Questo è un esempio delle difficoltà:

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

È difficile sapere cosa è

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

Answer 1

Dare jad (http://www.varaneckas.com/jad) un tentativo.

Il codice problematico che mostri è equivalente a quanto segue:

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 parte con cui hai problemi è la linea 1, che rappresenta una variabile locale o un campo (possibilmente statico). Il compilatore Java converte l'espressione "TypeStemHolder.class" in un'invocazione di GETCLASS che memorizza il risultato in un campo statico. Questa inizializzazione si verifica una volta in ogni classe che riferisce "TypeSystemHolder.class" e il compilatore sostituisce ogni callite che utilizza questa espressione con un accesso a campo.

La maggior parte dei decompilatori non riesce a tradurre questo idioma nella chiamata originale a "typesystemholder.class", ma Jad lo gestisce abbastanza bene. Inoltre, esiste un plug-in che integra Jad (e altri) in Eclipse (http://jadclipse.sourceforge.net).

Sfortunatamente, i decompilatori non gestiscono ogni sequenza di codice generata da un compilatore, quindi è sempre richiesta una riscrittura manuale. Ad esempio, il compilatore Java può generare codice per un blocco di gestione delle eccezioni che si sovrappone al codice per un altro blocco di gestione delle eccezioni. I decompilatori non sono in grado di separarlo in due blocchi di cattura. In questo caso, di solito si vedono le dichiarazioni GOTO disseminate in tutto il codice (non valido Java) o il decompilatore si arrende semplicemente su quel metodo.

Inoltre, hai ragione che questo è un codice generato. In particolare, proviene dal compilatore XMLBeans, che analizza lo schema XML XN e genera classi di legame per Java; permettendo a uno di sereizzare e deserializzare i documenti XML conformi a tale schema. Se hai accesso allo schema, sarebbe meglio incorporare XMLBeans nella tua build invece di decompilare queste classi.

Answer 2

Date un'occhiata al fuliggine. Non si decompila con il codice sorgente Java, ma utilizza un livello intermedio compilabile. Mentre è ancora un'altra lingua da imparare, otterrai la flessibilità di cui hai bisogno.

Inoltre, se stai facendo solo piccole modifiche, puoi semplicemente attaccare i file individualmente e lasciare il resto intatto.