Comment identifier une méthode manquante (compatibilité binaire) dans un fichier JAR statique
-
19-09-2019 - |
Question
Je veux vérifier la compatibilité binaire entre 2 Jarres.
A la suite des suggestions dans ce répondre je jboss tattletale mais il ne peut trouver que des classes manquantes.
Comment puis-je savoir s'il existe des méthodes manquantes? Est-il possible?
par exemple.
"Cela dépend - sur" classe Foo dépend de Bar (comme beaucoup d'autres travailleurs de la classe moyenne)
import org.overlyusedclassnames.Bar
public class Foo{
public void someMethod(){
Bar tender = new Bar();
tender.getJohnnyRedLabel();
tender.getJohnnyBlueLabel(); //this method is new in the Bar class
}
}
classe "A la compilation"
package org.overlyusedclassnames;
/**
* @Since 1992
* Changes: added blue and gold Johnny Walker labels
*/
public class Bar {
public Drink getJohnnyRedLabel(){
return new JohnyWalkerFactory.get(RedLabel.class);
}
public Drink getJohnnyBlackLabel(){
return new JohnyWalkerFactory.get(BlackLabel.class);
}
public Drink getJohnnyGoldLabel(){
return new JohnyWalkerFactory.get(GoldLabel.class);
}
public Drink getJohnnyBlueLabel(){
return new JohnyWalkerFactory.get(BlueLabel.class);
}
}
Maintenant, imaginez un pot Old Bar remplace accedently la barre de temps compilé:
classe "temps d'exécution"
package org.overlyusedclassnames;
/**
* @Since 1909
* Changes: added red and black Johnny Walker labels
*/
public class Bar {
public Drink getJohnnyRedLabel(){
return new JohnyWalkerFactory.get(RedLabel.class);
}
public Drink getJohnnyBlackLabel(){
return new JohnyWalkerFactory.get(BlackLabel.class);
}
}
Y at-il un moyen d'identifier la méthode manquante sans l'exécuter et d'obtenir un NoSuchMethodError
?
Disclaimer : Ceci est un important reformulations de mon propre question relative , qui est ineffaçable. J'ai choisi de poser une nouvelle question parce que le reformulant rendra les 2 réponses actuelles tout à fait sans rapport avec le sujet.
La solution
japi-conformité vérificateur - API en arrière / compatibilité ABI vérificateur pour une bibliothèque Java :
japi-compliance-checker -lib NAME -old OLD.jar -new NEW.jar
sigtest - test de signature SigTest Oracle et l'outil de conformité API
japitools - test de compatibilité entre les API Java
japi-checker - une compatibilité descendante API java qui fonctionne checker au niveau binaire
revapi - Analyse de l'API et changer l'outil de suivi
ou manuellement à l'aide javap decompiler:
javap OLD.class > OLD.txt javap NEW.class > NEW.txt diff -rNau OLD.txt NEW.txt > CHANGES.txt
Autres conseils
Clirr - vérifie les bibliothèques Java pour la compatibilité binaire et de source avec les versions plus anciennes:
java -jar clirr-core-0.6-uber.jar -o OLD.jar -n NEW.jar
Revapi peut faire le travail aussi. Il est facile d'incorporer dans Maven construit, ce qui est votre cas évidemment, mais pourrait intéresser d'autres.
Il peut également vérifier des ensembles de pots arbitraires en utilisant son mode autonome.
japicmp est un autre outil pour vérifier la compatibilité binaire. Il est disponible comme outil de ligne de commande autonome ou comme plug-in Maven.
Il est un outil du nom de animaux Sniffer qui vous permet d'extraire un la signature d'une API. Ensuite, il peut vérifier statiquement que les utilisateurs de l'API collent à la signature, et il peut vérifier statiquement qui ont tout mis en œuvre implementors de l'API. Je pense que cela résoudrait votre problème bien.
Vous pouvez télécharger le pot pour animaux Sniffer du repository de Codehaus: http://repo1.maven.org/maven2/org/codehaus / Mojo / animal renifleur /
Avez-vous besoin d'un pour vérifier une classe spécifique ou un outil générique pour comparer ce pot? Si c'est pour 1 classe, il suffit de charger la classe dans un chargeur de classe personnalisée, vérifiez la signature des méthodes en utilisant la réflexion et c'est tout. Si vous avez besoin pour de nombreuses classes de / JAR ce sera trop de travail.