Il s'agit de la commande japicompat qui peut être exécutée dans le fournisseur d'hébergement gratuit OnWorks en utilisant l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS
PROGRAMME:
Nom
japicompat - Testez les API Java pour la compatibilité descendante binaire.
SYNOPSIS
japonaiscompat [-svqhtjw4] [-ou fichier de sortie] [-je ignorer les fichiers]
DESCRIPTION
japonaiscompat fait partie de japitools, conçu pour tester la compatibilité entre les API Java.
Ils ont été conçus à l'origine pour tester les implémentations libres de Java lui-même pour
compatibilité avec le JDK de Sun, mais ils peuvent également être utilisés pour tester la rétrocompatibilité
entre les versions de n'importe quelle API.
Les outils sont japize et japicompat. Japize est un programme Java qui émet une liste d'un
API dans un format lisible par machine. Japicompat prend ensuite deux de ces listes et compare
pour la compatibilité binaire, comme défini par Sun dans la spécification du langage Java.
OPTIONS
-s désactiver les vérifications de compatibilité binaire supplémentaires (ne faire que les vérifications définies par le JLS).
-v activer les contrôles pour les problèmes de compatibilité mineurs.
Vérification SerialVersionUID : japicompat signale une erreur mineure si une classe Serializable
a un SerialVersionUID différent entre les deux versions.
Vérification de la dépréciation : japicompat signale une erreur mineure si une classe ou un membre a été
obsolète dans l'API d'origine mais n'est pas obsolète dans l'API en cours de vérification.
-q désactive les rapports de progression.
-h génère une sortie au format HTML. Les fichiers HTML produits dépendent du japi.css
fichier pour obtenir une présentation attrayante.
-t génère une sortie au format texte. C'est la valeur par défaut.
-j génère une sortie sous forme brute lisible par machine. Le format produit est appelé
format "japio", et par convention doit être enregistré avec une extension de fichier ".japio".
Les utilitaires autonomes japiotext et japiohtml peuvent être utilisés pour convertir ce format
en html ou en texte (en fait, japicompat appelle japiotext ou japiohtml en interne si
les indicateurs -h ou -t sont utilisés). Les fichiers Japio peuvent également être utilisés avec l'indicateur -i pour
prend en charge l'ignorance des erreurs causées par des incompatibilités entre les versions du JDK.
-w désactiver les avertissements pour l'exécution contre les anciens fichiers japi bogués. Par défaut japicompat
produira des avertissements s'il est exécuté sur des fichiers japi générés à l'origine par les anciens
versions de japitools qui avaient des bogues connus que japifix ne peut pas éliminer.
-4 utilisez le mode compatible 1.4. Cela fonctionne tant que les API à comparer ne contiennent pas
Éléments 1.5 uniquement.
-o
Envoyer la sortie à au lieu de stdout. Le format de ce fichier dépend de
les indicateurs -h, -t et -j.
-i
Supposons que vous essayez d'implémenter l'API Java. Vous avez (à peu près)
couverture complète des premières versions du JDK (1.0 et 1.1) mais a encore quelques
distance pour atteindre une couverture complète de 1.4 (il s'agit d'une description précise de tous
Implémentations Java de logiciels libres au moment de la rédaction). Utiliser japicompat pour
comparer votre implémentation avec JDK 1.4 donne des résultats précis, mais vous pouvez également
voulez montrer votre couverture des versions antérieures.
Malheureusement, Sun n'a pas suivi ses propres règles de compatibilité binaire entre JDK
releases, sans parler des règles étendues que japicompat teste. Ainsi, lorsque vous exécutez un
comparaison entre JDK 1.1 et votre implémentation, vous obtiendrez une erreur parasite
signale quand vous êtes compatible avec 1.4 mais pas 1.1.
Évidemment, ce que vous voulez vraiment, c'est ignorer les erreurs comme celle-ci, et japicompat
fournit un moyen de le faire. Tout d'abord, exécutez une comparaison entre 1.1 et 1.4 en utilisant le -j
changer. Ensuite, exécutez la comparaison entre 1.1 et votre implémentation, en passant le
Option "-i" avec la sortie de l'exécution précédente. Par exemple:
$ japicompat -jo ignore-11-14.japio jdk11.japi.gz jdk14.japi.gz
$ japicompat -ho jdk11-myimpl.html -i ignore-11-14.japio jdk11.japi.gz
monimpl.japi.gz
Vous pouvez également obtenir le même effet en exécutant :
$ japicompat -ho jdk11-monimpl.html -i jdk14.japi.gz jdk11.japi.gz monimpl.japi.gz
C'est évidemment plus simple et plus rapide à taper, mais nécessite la comparaison entre
jdk11 et jdk14 à exécuter à chaque fois. La création manuelle du fichier japio permet
pour qu'il soit sauvegardé et réutilisé la prochaine fois, ce qui permet à japicompat de courir
deux fois plus vite.
Les fichiers japi correspondant aux API à comparer.
japicompat teste spécifiquement que le deuxième argument est rétrocompatible
avec le premier. Par conséquent, une implémentation parfaite de JDK 1.1 ne produirait aucun
erreurs quel que soit l'ordre des arguments, mais une implémentation parfaite de
JDK1.1 ainsi que des parties de JDK1.2 doivent être testés comme suit :
$ japicompat jdk11.japi.gz monimpl.japi.gz
$ japicompat myimpl.japi.gz jdk12.japi.gz
Il est probablement impossible de faire une implémentation qui passe ces deux tests,
puisque le propre JDK1.2 de Sun produit de nombreuses erreurs lorsqu'il est testé avec JDK1.1. Voir le
discussion sur l'option -i ci-dessus pour trouver un moyen de faire face à cette situation.
Des fichiers compressés (.japi.gz) ou non (.japi) peuvent être transmis à
japicompat : l'extension de fichier est utilisée pour déterminer s'il faut ou non diriger l'entrée
via gzip ou non.
Utiliser japicompat en ligne en utilisant les services onworks.net
