JAR (archive Java) : fichier .jar

Le JAR (Java ARchive) regroupe les fichiers .class compilés d’un programme Java, ses ressources et un manifeste décrivant notamment le point d’entrée du programme, dans un unique fichier distribuable et exécutable via java -jar.

Structurellement, c’est une archive ZIP standard : sa signature de tête est identique à celle du ZIP générique, seule la présence du dossier META-INF/ contenant le fichier MANIFEST.MF confirme sa nature d’archive Java plutôt qu’un simple ZIP de fichiers quelconques.

Le manifeste peut aussi porter une signature numérique du JAR, garantissant que son contenu n’a pas été modifié depuis sa publication, un mécanisme utilisé notamment pour les applets Java signées et pour certains plugins nécessitant un niveau de confiance élevé.

Le format sert également de base à des variantes spécialisées : le WAR pour les applications web Java (Servlet/JSP) et l’EAR pour des applications d’entreprise complètes, tous deux de simples JAR portant une arborescence et un descripteur de déploiement différents.

Introduit avec le JDK 1.1 en 1997, le JAR répondait à un besoin concret : avant lui, distribuer une applet Java multipliait les requêtes HTTP, une par fichier .class, ce qui ralentissait fortement le chargement dans un navigateur. Un attribut Class-Path du manifeste permet en outre à un JAR de référencer d’autres archives comme dépendances, mais cette résolution reste relative et fragile : c’est ce qui a poussé l’écosystème vers les JAR dits « fat » ou « uber », produits par des outils comme Maven Shade ou Gradle Shadow, qui regroupent une application et toutes ses dépendances dans un seul fichier autoportant.

Depuis Java 9, le format admet aussi les JAR “multi-version” (JEP 238) : un même fichier peut embarquer plusieurs versions d’une même classe, rangées dans une arborescence META-INF/versions/<numéro-de-version-Java>/ en plus de la version de base. Une JVM récente charge automatiquement la version la plus adaptée à sa propre version, tandis qu’une JVM antérieure à Java 9 ignore ce dossier et retombe sur la classe de base, ce qui permet à une même bibliothèque de tirer parti de fonctionnalités récentes sans casser la compatibilité avec d’anciens environnements d’exécution.