Je veux mesurer l'évolution de l'API pour un projet Java donné, en particulier des classes neuves / renommées, de nouvelles méthodes, des méthodes nouvellement obsolètes, etc. Y a-t-il un outil qui détecte de tels changements?
Retour en 2007, un Google GSOC Project a été initié, cependant, je ne trouve pas le travail final.
6 Réponses :
J'utiliserais CLIRR pour cela, un vérificateur de compatibilité binaire. Du site Web Clrir:
Qu'est-ce que c'est?
CLIRR est un outil qui vérifie Java Bibliothèques pour binaire et source Compatibilité avec des versions plus anciennes. Fondamentalement, vous lui donnez deux séries de bocal Fichiers et CLIRR désignent une liste de changements dans l'API publique. Le cligne Tâche ANT peut être configuré pour casser la construction si elle détecte incompatible changements d'API. Dans un continu Processus d'intégration CLIRR CAN empêcher automatiquement accidentelle Introduction de binaire ou de source Problèmes de compatibilité.
...
Caractéristiques
- signaler toutes les modifications de l'API (actuellement uniquement implémenté partiellement)
- Évaluez chaque changement WRT. Compatibilité binaire et source
- Support Texte brut et XML Rapports
- Manipulation de défaillance flexible (avertissements vs erreurs, casser la construction ou l'ensemble Propriété d'erreur)
CLIRR semble très obsolète à partir de 2018. Je ne pense pas que cela fonctionne même avec les fichiers JAR compilés Java 8.
Le dernier binaire est de 2005
BTW Il semble y avoir un checker API dans le code source GWT, je ne sais pas si c'est le produit du projet GSOC mentionné.
GWTJAVAApicompatibilityChecker est également utilisé dans < Un href = "http://google-web-toolkit.googlecode.com/svn/trunk/build.xml" rel = "nfollow Noreferrer"> build.xml
C'est le projet réel que je faisais réfédié!
JDIff vaut peut-être aussi une mention de mention.
JDIff est un docuté Javadoc qui génère un rapport HTML de tous les Forfaits, classes, constructeurs, méthodes et champs qui ont été enlevé, ajouté ou changé de quelque manière que ce soit, y compris leur documentation, quand Deux API sont comparées. C'est très utile pour décrire exactement ce qui a changé entre deux versions d'un produit. Seulement l'API (application Interface de programmation) de chaque version est comparé. Il ne comparent pas quoi Le code source fait lorsqu'il est exécuté.
Comme je l'ai compris, il fonctionne sur le bordereau de l'ancienne version et génère un fichier XML. La même chose pour le fichier source avec la nouvelle version. Que les deux sorties XML sont comparées et une centrale compilée. Dans le style HTML-Javadoc-API
JDiff court sur le Javadoc du code, pas sur le code. C'est un bon compagnon de clignoter (si vous pouvez faire confiance à la Javadoc) et il est mentionné dans les projets associés ( clirr.sourceforge.net/related.html ). Mais je préfère quelque chose qui fonctionne au niveau du code.
Il y a aussi un nouvel outil de vérification de l'évolution de l'API appelé revapi
C'est un outil génial !!
Essayez JAPI-Conformité-Checker Outil. C'est open-source. L'outil affiche les modifications de l'API et détecte les problèmes de compatibilité des sources en arrière (SC) et de la BRINABLE (BC) entre deux archives JAR: échantillon de rapports pour log4j: http://abi-laboratory.pro/java/tracker/timeline/log4j/ < p> Vous pouvez trouver la classification des problèmes de compatibilité trouvés par niveau de gravité dans les rapports de versions de bibliothèque particulières: 
Question liée: Stackoverflow.com/Questtions/2040693/...