Por qué 'jardiff' no se publicará como binario: el código fuente como herramienta de uso

Fuentes: If I release it, you won’t get the same experience I get

El desarrollador conocido como 'quat' comparte en su blog por qué decidió no empaquetar como binario independiente su herramienta 'jardiff', un comparador de archivos Java más flexible que diffoscope. La utilidad compara dos ficheros o directorios: si son directorios, verifica que contengan los mismos archivos y desciende recursivamente; también examina el contenido de archivos .zip y .jar; reformatea los .json antes de diffearlos; y, en el caso de los .class, los pasa por el desensamblador objectweb asm textifier para evitar el inútil mensaje 'Binary files differ'. El autor implementó a mano el algoritmo de diff de Meyers.

Durante una refactorización de su sistema de construcción en Codeberg, 'jardiff' le permitió detectar que tres mods se compilaban desde un sourceset compatible con Java 8, mientras que el nuevo sistema compilaba las clases pegadas con Java 25, una diferencia visible en el número de versión del bytecode. Decidió que el cambio era aceptable y, en lugar de añadir flags de configuración, modificó directamente el código del desensamblador para que ignorara esa diferencia.

El artículo desarrolla una tesis sobre la ergonomía del software: cuando el código fuente de la herramienta está abierto en el editor, el usuario puede adaptar el comportamiento sobre la marcha —añadir un ClassVisitor personalizado, decidir si importa el orden de entradas en un zip, ignorar o amplificar diferencias— sin pasar por opciones configurables. Empaquetar como binario, argumenta, 'congela en ámbar' la herramienta y establece una relación de poder entre desarrollador y usuario basada en quién controla el lenguaje real frente al DSL. Termina sugiriendo, con ironía, copiar y pegar las dos clases desde Codeberg.