Convertir JAR en JAVA

Les fichiers source sont nécessaires lorsqu’un JAR est la seule copie disponible d’une bibliothèque ou d’une application Java et que son code doit être inspecté, audité, modifié ou recompilé. La plupart des JAR de version contiennent des fichiers .class compilés ; la récupération des fichiers .java nécessite donc généralement une décompilation plutôt qu’une conversion directe de fichier.

Contenu d’un fichier JAR

Un JAR (Java Archive) est une archive basée sur ZIP utilisée par les développeurs Java, les outils de build et les fournisseurs d’applications pour distribuer des bibliothèques, des plugins et des applications. Il contient généralement des classes compilées, des ressources, des métadonnées de dépendances et META-INF/MANIFEST.MF ; les JAR exécutables peuvent déclarer une classe de démarrage dans ce manifest.

Les outils du JDK, Maven, Gradle, Eclipse et IntelliJ IDEA peuvent créer ou utiliser des JAR. Une archive distincte nommée name-sources.jar contient souvent les fichiers source d’origine et doit être utilisée au lieu de décompiler le JAR compilé.

Qu’est-ce qu’un fichier JAVA ?

Il n’existe pas de format binaire « JAVA » distinct. Un fichier .java est du code source Java en texte brut contenant des classes, des interfaces, des méthodes, des déclarations de packages et des imports. Il peut être modifié et compilé avec javac, à condition que les bibliothèques requises et le niveau de version Java approprié soient disponibles.

Un JAR produit normalement de nombreux fichiers source. Leurs dossiers doivent correspondre aux noms de packages : com.example.Main doit se trouver dans com/example/Main.java. Java exige qu’une classe de niveau supérieur publique utilise le même nom de fichier que cette classe.

Extraire d’abord les sources existantes

Répertoriez le contenu de l’archive avec la commande jar du JDK :

jar tf app.jar

Si la liste contient des fichiers .java, extrayez-les dans un répertoire de travail vide :

mkdir recovered-src
cd recovered-src
jar xf ../app.jar

Si une archive source correspondante est disponible, extrayez-la à la place :

jar xf app-sources.jar

Ne confondez pas les ressources telles que .properties, les fichiers XML, les images ou les définitions de services avec du code source Java. Extrayez-les si le projet en a besoin, mais elles ne peuvent pas être converties en code .java significatif.

Décompiler les classes compilées

Si le JAR contient uniquement des fichiers .class, utilisez un décompilateur Java pour ordinateur. CFR est une option adaptée en ligne de commande et prend généralement mieux en charge le bytecode Java récent que de nombreux décompilateurs plus anciens. Téléchargez CFR depuis le site officiel du projet, puis exécutez :

java -jar cfr.jar app.jar --outputdir recovered-src

CFR écrit les fichiers .java récupérés sous recovered-src. Pour une option graphique, ouvrez le JAR dans JD-GUI et sélectionnez File → Save All Sources ; JD-GUI crée une archive ZIP qui doit être extraite avant l’ouverture des fichiers dans un IDE.

IntelliJ IDEA peut afficher les classes décompilées à des fins d’inspection, mais CFR ou JD-GUI est préférable lorsqu’une arborescence source exportable est nécessaire. Pour les petits exemples publics et non sensibles, des services dans un navigateur tels que Decompiler.com peuvent décompiler des JAR sans installation locale ; vérifiez leurs conditions de conservation et de confidentialité avant d’envoyer quoi que ce soit.

Limites de la compilation et de la récupération

Le résultat décompilé n’est pas le projet source d’origine. Le bytecode ne conserve pas les commentaires, la mise en forme, la plupart des noms de variables locales, les sources des tests, les scripts de build, l’historique du contrôle de version ni certaines informations de type générique. L’obfuscation peut remplacer les noms explicites par des identifiants tels que a et b.

Les fichiers récupérés peuvent ne pas se compiler immédiatement. Ajoutez les dépendances d’origine du JAR, le code généré, les processeurs d’annotations, les ressources et les options du compilateur ; compilez ensuite pour la version Java utilisée par les classes d’origine. Une version de fichier de classe plus récente peut nécessiter un JDK plus récent et un décompilateur prenant en charge cette version.

Les JAR multi-versions peuvent contenir des implémentations de classes alternatives sous META-INF/versions/, et les JAR ombrés peuvent regrouper des dépendances avec le code de l’application. Examinez la structure des packages et le manifest avant de considérer chaque classe récupérée comme faisant partie d’un seul projet source.

Conservez les JAR privés, appartenant à des clients, sous licence ou sensibles du point de vue de la sécurité sur une machine locale plutôt que de les envoyer à un décompilateur en ligne. Ne décompilez que les logiciels dont vous êtes propriétaire ou que vous êtes autorisé à inspecter ; le code récupéré reste soumis à sa licence d’origine et aux conditions relatives aux droits d’auteur.