Decompilar Javaee

Question

Temos um aplicativo Java EE que o fornecedor não existe mais (devido à falência). Infelizmente, temos que fazer algumas alterações na funcionalidade do aplicativo, e isso significa engenharia reversa do aplicativo Javaee.

Usamos o JD-GUI para reverter a engenheira de cerca de 70% do aplicativo/classes e depois ajustá-los manualmente para construir no Eclipse.

No entanto, os restos não são tão fáceis de serem construídos porque são produzidos pelos geradores de código? Que ferramentas posso usar para ajudar mais?

Editar:

Este é um exemplo das dificuldades:

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

É difícil saber o que é

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

Answer 1

Dê Jad (http://www.varaneckas.com/jad) uma tentativa.

O código problemático que você mostra é equivalente ao seguinte:

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;

A parte com a qual você está tendo problemas é a linha 1, que representa uma variável local ou um campo (possivelmente estático). O compilador Java converte a expressão 'Typeystemholder.class' em uma invocação de getclass armazenando o resultado em um campo estático. Essa inicialização ocorre uma vez em cada classe que faz referência ao 'Typeystemholder.class' e o compilador substitui cada site que usa essa expressão por um acesso de campo.

A maioria dos decompiladores não consegue traduzir esse idioma de volta à chamada original para 'Typeystemholder.class', mas Jad lida muito bem com isso. Além disso, há um plug-in que integra o JAD (e outros) ao Eclipse (http://jadclipse.sourceforge.net).

Infelizmente, os decompiladores não lidam com todas as seqüências de código geradas por um compilador, de modo que sempre é necessária alguma reescrita manual. Por exemplo, o compilador Java pode gerar código para um bloco de manuseio de exceção que se sobrepõe ao código para outro bloco de manuseio de exceção. Os decompiladores não conseguem separar isso em dois blocos de captura. Nesse caso, geralmente se vê declarações de goto espalhadas por todo o código (não válido Java) ou o decompilador simplesmente desiste desse método.

Além disso, você está certo de que este é o código gerado. Especificamente, é do compilador XMLBeans, que analisa o esquema XN XML e gera classes de ligação para Java; permitindo que alguém se reailize e desserialize os documentos XML em conformidade com esse esquema. Se você tiver acesso ao esquema, seria melhor incorporar XMLBeans em sua construção em vez de descompilar essas classes.

Answer 2

Dar uma olhada em fuligem. Não decompile para o código -fonte Java, mas usa uma camada intermediária que é compilável. Embora seja mais um idioma para aprender, você obterá a flexibilidade necessária.

Além disso, se você estiver fazendo apenas pequenos ajustes, poderá apenas atacar arquivos individualmente e deixar o restante intacto.