Comment vérifier si des binaires sont construits à partir de sources particulières

Je suggère un processus multi-étapes:

Appliquez le Jardiff précédemment suggéré ou similaire à voir s'il existe des différences d'API. Si possible, choisissez un outil qui a une option pour signaler des méthodes privées, etc. Dans la pratique, tout changement substantiel de mise en œuvre de Java est susceptible de modifier certaines méthodes et classes, même si l'API publique est inchangée.

Si vous avez une correspondance API, compilez quelques fichiers sélectionnés au hasard avec le compilateur indiqué, décompilez le résultat et les fichiers de classe d'origine, et comparez les résultats. S'ils correspondent, appliquez le même processus à des organes de code plus gros et plus grands jusqu'à ce que vous trouviez une inadéquation ou avez vérifié tout.

Les diffses de code décompilé sont plus susceptibles de vous donner des indices sur la nature des différences et sont plus faciles à filtrer pour des différences non significatives que les fichiers de classe actuels.

Si vous obtenez une inadéquation, analysez-le. Cela peut être dû à quelque chose que vous ne vous souciez pas. Si tel est le cas, essayez de construire un script qui supprimera cette forme de différence et reprendre le processus de compil et de comparaison. Si vous obtenez des incompatibles généralisées, expérimentez des paramètres de compilateur tels que l'optimisation. Si les ajustements des paramètres du compilateur éliminent les différences, continuez avec la comparaison en vrac. L'objectif de cette phase est de trouver une combinaison de paramètres du compilateur et de filtres de code décompilés qui produisent une correspondance sur les fichiers échantillons et les appliquent à la comparaison en vrac de la bibliothèque.

Si vous ne pouvez pas obtenir une correspondance raisonnablement étroite dans le code décompilé, vous n'avez probablement pas le bon code source. Malgré tout, si vous avez un match d'API, il peut être intéressant de construire votre système et d'exécuter vos tests en utilisant le résultat de la compilation. Si vos tests fonctionnent au moins aussi à la version que vous avez construite à partir de la source, continuez à utiliser le travail en l'utilisant.

Pour les signatures de méthode, utilisez un outil comme Jardiff.

Pour la similitude de la mise en œuvre, vous devez revenir à une supposition sauvage. La comparaison du bytecode sur le niveau de fonctionnement peut être dépendante du compilateur et conduire à un grand nombre de faux négatifs. Si tel est le cas, vous pouvez revenir à la comparaison des méthodes d'une classe à l'aide de la for forte> linenumbertable forte>. P>

Cela vous donne une liste de numéros de ligne pour chaque méthode (tant que Le fichier de classe a été compilé avec le drapeau de débogage, qui manque souvent dans des bibliothèques très anciennes ou commerciales). p>

Si deux fichiers de classe sont compilés à partir du même code source, puis au moins les numéros de ligne de chaque La méthode doit correspondre exactement. p>

Vous pouvez utiliser une bibliothèque telle que Apache Bcel pour récupérer la liste de linge de lecture: P>

  // import org.apache.bcel.classfile.ClassParser;
  JavaClass fooClazz = new ClassParser( "Foo.class" ).parse();
  for( Method m : fooClazz.getMethods() )
  {
     LineNumberTable lnt = m.getLineNumberTable();
     LineNumber[] tab = lnt.getLineNumberTable();
     for( LineNumber ln : tab )
     {
        System.out.println( ln.getLineNumber() );
     }
  }