Descompilar Javaee

Question

Tenemos una aplicación Java EE que ya no existe (debido a la bancarrota). Desafortunadamente, tenemos que hacer algunos cambios en la funcionalidad de la aplicación, y esto significa Ingeniería inversa de la aplicación Javaee.

Usamos JD-GUI para invertir en ingeniería alrededor del 70% de las aplicaciones/clases, y luego los modificamos manualmente para construir en Eclipse.

Sin embargo, los restos no son tan fáciles de construir porque son producidos por generadores de código? ¿Qué herramientas puedo usar para ayudar más?

Editar:

Este es un ejemplo de las dificultades:

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 difícil saber qué es

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

Answer 1

Dale a Jad (http://www.varaneckas.com/jad) un intento.

El código problemático que muestra es equivalente a lo siguiente:

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 la que tiene problemas es la línea 1, que representa una variable local o un campo (posiblemente estático). El compilador Java convierte la expresión 'typesystemholder.class' en una invocación de GetClass almacenando el resultado en un campo estático. Esta inicialización ocurre una vez en cada clase que hace referencia a los typesystemholder.class 'y el compilador reemplaza cada sitio de llamadas que usa esta expresión con un acceso de campo.

La mayoría de los descompiladores no pueden traducir este idioma a la llamada original a 'Typesystemholder.class', pero Jad lo maneja bastante bien. Además, hay un complemento que integra JAD (y otros) en Eclipse (http://jadclipse.sourceforge.net).

Desafortunadamente, los descompiladores no manejan cada secuencia de código generada por un compilador, por lo que siempre se requiere alguna reescritura manual. Por ejemplo, el compilador Java puede generar código para un bloque de manejo de excepciones que se superpone con el código para otro bloque de manejo de excepciones. Los descompiladores no pueden separar esto en dos bloques de captura. En este caso, generalmente se ve declaraciones GOTO llenas de todo el código (no Java válida) o el descompilador simplemente da a ese método.

Además, tiene razón en que este se genera código. Específicamente, es del compilador XMLBeans, que analiza el esquema XML XM y genera clases de unión para Java; Permitir que uno serailice y deserialice documentos XML que se ajusten a ese esquema. Si tiene acceso al esquema, sería mejor incorporar XMLBeans en su construcción en lugar de descomponer estas clases.

Answer 2

Echa un vistazo a Hollín. No se descompila al código fuente de Java, pero usa una capa intermedia que es compilable. Si bien es otro idioma que debe aprender, obtendrá la flexibilidad que necesita.

Además, si solo está haciendo pequeños ajustes, puede atacar archivos individualmente y dejar el resto intacto.