Contexto

Se necesitaba comparar dos archivos EAR para saber qué había cambiado entre dos versiones.

Un EAR es esencialmente un contenedor ZIP que puede incluir:

  • JAR;
  • WAR;
  • XML;
  • properties;
  • recursos;
  • clases compiladas;
  • librerías.
Una comparación binaria del EAR completo aporta poco valor.

Decisión: comparar estructura lógica, no únicamente hashes globales

El proceso correcto es:

text
EAR A                 EAR B
  |                     |
  v                     v
extraer                extraer
  |                     |
  +-------- compare -----+

La comparación debe detectar:

  • fichero solo en A;
  • fichero solo en B;
  • mismo path con contenido diferente.

Archivos anidados

Un WAR dentro de un EAR vuelve a ser un ZIP.

Por tanto, la comparación debe ser recursiva.

mermaid
flowchart TD
    A[EAR] --> B[entries]
    B --> C[JAR]
    B --> D[WAR]
    B --> E[config]
    C --> F[recursive compare]
    D --> G[recursive compare]

Decisión: tratamiento diferente para texto y binario

Para archivos textuales:

  • diff línea a línea;
  • normalización opcional;
  • contexto.
Para binarios:
  • tamaño;
  • hash;
  • presencia;
  • tipo.
Para .class, una extensión natural es decompilar a Java antes de comparar.

Esto hace que el informe responda a una pregunta humana:

"¿Qué lógica cambió?"

y no únicamente:

"¿Qué bytes cambiaron?"

Riesgos

La decompilación tiene limitaciones:

  • nombres optimizados;
  • bytecode generado;
  • diferencias de compilador;
  • pérdida de comentarios;
  • estructura no idéntica al fuente.
Por eso una comparación decompilada debe presentarse como ayuda diagnóstica, no como fuente original.

---