java.lang.SecurityException: class X signer information does not match signer information of other classes in the same package.

Plusieurs classes utilisées dans un même package Java ne proviennent pas de la même librairie Java (fichier Jar) et peuvent créer des effets indésirables.
La machine virtuelle Java à une protection contre ce risque.

Explication

Les fichiers .jars, librairies de classes en Java, sont « signés »
C’est à dire qu’ils sont encodés de manière à être sûre que leur contenu n’a pas été altéré.
Ce qui est une protection qui assure le bon fonctionnement de ces librairies.

Si vous avez ce message d’erreur:
java.lang.SecurityException: class X signer information does not match signer information of other classes in the same package
avec X est votre classe.
C’est que vous avez une erreur dans vos librairies.

En décomposant le message d’erreur on peu se douter du problème :

• java.lang.SecurityException => Une Protection contre une opération malsaine
• class X => concerne une classe particulière
• signer information => le problème concerne la signature du fichier .class
• does not match signer information of … => une autre classe rentre en conflit de signature
• of other classes in the same package => Notre problème concerne le package de la classe X

Exemple fréquent

Le classpath est un argument de la ligne de commande Java qui permet d’inclure les classes de votre projet à un processus java.
Le classpath peu contenir des fichier .class (une classe java) ou des fichiers .jar (libraries) ou même des répertoires qui contiennent les fichier précédemment cités)

Dans ce classpath, vous avez deux libraries :
ma_librarie_v1.jar et ma_librarie_v2.jar
Qui sont les même libraries, mais deux versions différentes

ma_librairie_v1.jar contiens : org.montest.Class1
ma_librairie_v2.jar contiens : org.montest.Class1 et org.montest.Class2

vous les ajoutés au classpath dans l’ordre 1 , puis 2. :
-classpath « ma_librarie_v1.jar;ma_librarie_v2.jar »

Java prend en compte les classes au fur et à mesure qu’il les lit dans le classpath.
Donc dans ce cas Java aura en mémoire :
class1.class de la librarie v1 et class2.class de la librarie v2.

Tant que vous n’utiliserez que la Class1, vous fonctionnerez uniquement avec la librairie v1 et vous n’aurez aucun problème.

Par contre quand vous utiliserez la Class2, Java va essayer de lire le contenu de la classe.
Il va regarder dans quel package cette classe ce trouve (org.montest.) et il va bien trouver org.montest.Class2.
Il va alors vérifier sa signature… qui se trouve etre différente de org.montest.Class1.
Une signature est propre à un seul fichier jar, Java a donc détecter que pour un même package, 2 classes viennent de 2 jar différents ce qui crée cette erreur.

Java a raison d’agir comme cela, car vous alliez sans vous en rendre compte utiliser Class1 qui n’est certainement pas compatible avec Class2.

Votre programme n’aurai surement pas fonctionné, ou son comportement aurai été sujet à des bugs.

Généralisation

Attention, l’exemple précédent est un cas d’école, car v1 et v2 sont facile à identifier.
Certaines entreprises développent de célèbre librairies ayant le même nom.
Exemple: Sun et Ibm développent chacun leur jdk/Jre (c’est à dire l’ensemble des classe de base de java)
Mais ce ne sont pas les seuls, Microsoft et bien d’autre peuvent être de la partie
Et donc 2 jars dont le noms sont bien différents, peuvent contenir des classes communes et d’autre qui diffèrent.
Heureusement cette erreur n’est pas fréquente et Google vous aidera.
Je vous conseil surtout de parcourir le contenu de chacun de vos packages et de repérer les doublons.

Autre possibilité d’apparition du probléme

Quelqu’un à créer un mauvais fichier .jar que vous utilisez (un mainteneur du projet ?)
Il est possible d’accumuler dans un même fichier jar le contenu de plusieurs fichiers jars.
Dans ce cas vous n’avez pas le choix, il vous faut changer cette librairie, par une version plus récente, qui en général corrige ce problème.