GoGPT Best VPN GoSearch

Icône de favori OnWorks

clirr - En ligne dans le Cloud

Exécutez clirr dans le fournisseur d'hébergement gratuit OnWorks sur Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS

Il s'agit de la commande clirr 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


clirr - Vérifier la compatibilité source et binaire des bibliothèques Java

SYNOPSIS


crier -o vieux pot -n nouveaujar [Options]

DESCRIPTION


Clirr est un outil qui vérifie la compatibilité binaire et source des bibliothèques Java avec les anciennes
libère. Fondamentalement, vous lui donnez deux ensembles de fichiers jar et Clirr vide une liste de
changements dans l'API publique.

OPTIONS


-a, --show-all-scopes

afficher les cours privés et les forfaits

-f, --fichier de sortie

nom du fichier de sortie

-i, --include-paquet

inclure uniquement les classes de ce package et de ses sous-packages

-n, --nouvelle version

fichiers jar de la nouvelle version

-ncp, --nouveau chemin de classe

Chemin de classe tiers référencé par la nouvelle version

-o, --ancienne version

fichiers jar de l'ancienne version

-ocp, --orig-classpath

Chemin de classe tiers référencé par l'ancienne version

-p, --show-pkg-portée

afficher les classes de portée du package

-s, --style [texte|xml]

style de sortie

MESSAGES


Lorsque clirr génère un message d'ERREUR, d'AVERTISSEMENT ou d'INFO sur un changement dans les pots en cours
comparé, il y a un code de référence de message associé. Ce manuel contient un
explication de la signification de ce message qui peut contenir des informations qui ne
être inséré dans le résumé du message bref.

Les messages sont séparés en trois niveaux de gravité : ERREUR, AVERTISSEMENT et INFO.

Les erreurs se présentent sous deux formes :

Échecs au moment de la liaison, où une exception sera levée dès que le code sera compilé
contre une ancienne version d'une classe et la nouvelle version de la classe est chargée dans
la même hiérarchie de chargeur de classe.

Échecs d'exécution, où une exception est levée lorsque le code est compilé par rapport à l'ancien
version d'une classe tente d'appeler une méthode sur une nouvelle version de la classe, ou vice
versa.

Clirr signale des "erreurs" pour les cas où il est possible d'obtenir un échec d'exécution. Qu'il s'agisse
une se produit réellement peut dépendre de la façon dont la bibliothèque est appelée, c'est-à-dire les changements signalés
car une erreur peut en fait fonctionner lorsqu'elle est utilisée tant que les modèles d'utilisation de la bibliothèque le font
pas déclencher la situation d'échec.

Des avertissements sont émis pour les situations où aucun lien ou exception d'exécution ne se produira, mais
où l'application peut se comporter de manière inattendue en raison des changements qui se sont produits.

Les messages d'information fournissent aux utilisateurs des informations sur les nouvelles fonctionnalités qui ont été
ajouté sans rompre la compatibilité descendante de quelque façon que ce soit.

Lorsque vous utilisez clirr pour signaler les modifications apportées aux éléments qui ont une portée privée ou de package, ces
les changements sont toujours signalés comme des changements de niveau INFO, jamais de niveau AVERTISSEMENT ou ERREUR. Cette
permet aux utilisateurs de clirr de générer des « rapports de modification » à un niveau adapté aux développeurs
sans que certains de ces changements soient marqués (sans pertinence) comme des incompatibilités binaires.

Il ne peut jamais y avoir d'incompatibilités binaires pour les modifications apportées aux classes, méthodes ou
champs car cet accès ne peut se produire qu'à partir de la même classe (c'est-à-dire la même compilation
unité).

Clirr ne signale pas d'AVERTISSEMENTS ou d'ERREURS d'incompatibilité binaire pour les éléments à portée de package
soit, car les packages Java sont destinés à être des "unités de version", c'est-à-dire toutes les classes au sein
un package sont compilés ensemble (garantissant la compatibilité) puis publiés en tant qu'unité. Le seul
le moment où les incompatibilités de portée de paquet pourraient éventuellement être un problème, c'est lorsque les utilisateurs d'un
bibliothèque écrivent leurs propres classes en utilisant une déclaration de package appartenant à des
bibliothèque, ou lorsqu'un sous-ensemble de classes mises à jour (par exemple une seule classe) d'un package est utilisé
pour remplacer certaines classes d'une version précédente de la bibliothèque. Ces deux
les situations sont considérées comme de très mauvaises pratiques par la convention de programmation Java.

Dans les sections suivantes, le terme « ancien » est utilisé pour désigner une classe, une interface, une méthode
ou champ de l'ensemble de pots qui représentent l'ancienne/précédente/version originale/de base
de la bibliothèque inspectée. Le terme « nouveau » est utilisé pour désigner une classe, une interface,
méthode ou champ de l'ensemble de pots qui représentent la nouvelle/actuelle/dernière version du
bibliothèque en cours d'inspection.

Dans les sections suivantes, le terme « type » est utilisé pour désigner quelque chose qui peut être
soit une classe ou une interface.

1000 - Surface de définition of classe

Gravité : INFO

Le type spécifié existe dans les deux versions, mais son spécificateur d'accès déclaré a
modifié pour assouplir les restrictions sur les autres codes pouvant y accéder.

Les types de niveau supérieur (c'est-à-dire ceux qui ne sont pas imbriqués dans une autre classe) peuvent n'avoir que
accessibilité « forfaitaire » ou « publique ». Les types imbriqués peuvent prendre n'importe lequel des quatre
valeurs d'accessibilité disponibles.

Que l'objet soit de niveau supérieur ou imbriqué, un changement d'accessibilité
de gauche à droite de la séquence private->package->protected->public toujours
garantit que tout le code qui pouvait auparavant accéder à ce type peut toujours accéder à ce
taper. Par conséquent, un tel changement est toujours binaire et compatible avec le code source.

A noter que la déclaration "protected" donne accès à la fois au code dérivé du
taper et coder au sein d'un même package, c'est-à-dire que l'accessibilité "protégée" implique également
l'accessibilité des paquets.

1001 - Diminution définition of classe

Gravité : ERREUR

Le type spécifié existe dans les deux versions, mais son spécificateur d'accès déclaré a
modifié pour resserrer les restrictions sur les autres codes pouvant y accéder.

Les types de niveau supérieur (c'est-à-dire ceux qui ne sont pas imbriqués dans une autre classe) peuvent n'avoir que
accessibilité « forfaitaire » ou « publique ». Les types imbriqués peuvent prendre n'importe lequel des quatre
valeurs d'accessibilité disponibles.

Que le type soit de niveau supérieur ou imbriqué, un changement d'accessibilité
de gauche à droite de la séquence public->protected->package->private peut provoquer
code existant qui pouvait auparavant accéder au type pour ne plus pouvoir le faire.

La section 13.4.3 de la spécification du langage Java stipule explicitement qu'un
IllegalAccessError devrait se produire si un binaire préexistant essaie d'accéder à un type
lorsque l'accessibilité de type a été changée en quelque chose qui provoquerait un
erreur de compilation. Cependant, cela ne semble pas être appliqué dans la pratique, à
moins dans les JVM actuelles. Néanmoins, cela devrait être une erreur, et clirr rapporte
ce changement comme une ERREUR de compatibilité binaire.

2000 - Changé grâce au classe à interface

Gravité : ERREUR

La classe spécifiée est devenue une interface dans la nouvelle version. Ce changement est
toujours une incompatibilité binaire et code source, pour des raisons évidentes.

2001 - Changé grâce au interface à classe

Gravité : ERREUR

L'interface spécifiée est devenue une classe dans la nouvelle version. Ce changement est
toujours une incompatibilité binaire et code source, pour des raisons évidentes.

3001 - Supprimé finale modificateur grâce au classe

Gravité : INFO

La classe spécifiée a été déclarée finale dans l'ancienne version, mais n'est plus finale
dans la nouvelle version.

3002 - Ajouté finale modificateur à de manière efficace finale classe

Gravité : INFO

La classe spécifiée n'était pas déclarée finale dans l'ancienne version, mais est maintenant déclarée
final. Normalement, il s'agirait d'une incompatibilité car des dérivés préexistants
les classes ne seraient plus valides lorsqu'elles étaient utilisées avec la nouvelle version de cette classe.
Cependant, dans ce cas, l'ancienne version de classe n'avait pas de constructeurs publics ou protégés,
il n'était donc pas possible pour les classes dérivées d'exister même pour l'ancienne version de
la bibliothèque. Changer une telle classe en finale ne peut donc pas casser une classe existante
code.

3003 - Ajouté finale modificateur à classe

Gravité : ERREUR

La classe spécifiée n'était pas déclarée finale dans l'ancienne version, mais est maintenant déclarée
final. Toutes les classes préexistantes qui ont été déclarées comme sous-classes de cette classe
ne sera donc pas valable avec la nouvelle version de la bibliothèque.

Une VerifyError est levée par le chargeur de classe lorsqu'une tentative est faite pour charger un
sous-classe d'une classe finale.

Notez qu'une classe Y est chargée par le chargeur de classe standard uniquement lorsque le premier
une tentative est faite pour créer une instance de Y, ou pour référencer directement la classe
objet pour la classe Y. Si une autre classe X a la classe Y en tant que membre déclaré, ou en tant que
paramètre à une méthode, le chargement de la classe X n'entraîne pas le chargement de la classe Y.

3004 - Supprimé résumé modificateur grâce au classe

Gravité : INFO

L'ancienne version de cette classe était déclarée classe abstraite. La nouvelle version
n'est pas abstrait, permettant aux utilisateurs de créer des instances de la classe.

3005 - Ajouté résumé modificateur à classe

Gravité : ERREUR

L'ancienne version de cette classe n'était pas déclarée abstraite. La nouvelle version est
abstrait. Le code préexistant qui crée des instances de cette classe n'est plus
valable avec la nouvelle version.

4000 - Ajouté interface à le set of mis en œuvre interfaces

Gravité : INFO

La nouvelle version du type implémente désormais une interface supplémentaire. Cela ne
invalider tout code existant (source ou binaire), et est complètement
changement rétrocompatible.

Notez que ce message peut être signalé sans qu'aucun changement ne se produise dans le
type spécifié ; une modification de l'ensemble des interfaces supportées par un type entraînera
ce message doit être signalé pour chaque descendant de ce type.

4001 - Supprimé interface grâce au le set of mis en œuvre interfaces

Gravité : ERREUR

L'ancienne version de ce type déclarait implémenter une interface que le
la nouvelle classe ou interface ne le fait pas. Code existant qui convertit explicitement ou implicitement
objets de ce type à l'interface désormais manquante n'est plus valide.

Notez que ce message peut être signalé sans qu'aucun changement ne se produise dans le
type spécifié ; une modification de l'ensemble des interfaces supportées par un type entraînera
ce message doit être signalé pour chaque descendant de ce type.

5000 - Ajouté classe à le set of superclasses

Gravité : INFO ou AVERTISSEMENT

La nouvelle version de la classe a une classe dans sa hiérarchie d'héritage que l'ancienne
version ne l'a pas fait, soit parce que son parent direct est maintenant une classe différente, soit
car l'une de ses classes parentes a modifié sa hiérarchie d'héritage.

Si la classe spécifiée a java.lang.Throwable comme ancêtre, alors ce changement est
signalé comme un AVERTISSEMENT, car ce changement de classe peut changer la capture d'exception
comportement des programmes qui utilisent cette classe.

Notez que ce message peut être signalé sans qu'aucun changement ne se produise dans le
classe spécifiée ; une modification de l'ensemble des superclasses d'une classe ancêtre
ce message sera signalé pour chaque classe descendante.

5001 - Supprimé classe grâce au le set of superclasses

Gravité : ERREUR

L'ancienne version de cette classe a une classe dans sa hiérarchie d'héritage que le
la nouvelle version ne le fait pas, soit parce que son parent direct est maintenant une classe différente, soit
car l'une de ses classes parentes a modifié sa hiérarchie d'héritage.

Code existant qui transpose explicitement ou implicitement des objets de ce type vers le maintenant
le type de classe manquant n'est plus valide.

Notez que ce message peut être signalé sans qu'aucun changement ne se produise dans le
classe spécifiée ; une modification de l'ensemble des superclasses d'une classe ancêtre
ce message sera signalé pour chaque classe descendante.

Notez également que si cette classe a Throwable dans son ascendance, alors la classe
le changement de hiérarchie peut également entraîner des changements dans le comportement de détection des exceptions de
programmes utilisant cette classe.

6000 - Ajouté champ

Gravité : INFO

La nouvelle classe a un membre statique ou instance supplémentaire. Ce changement est
complètement rétrocompatible.

6001 - Supprimé champ

Gravité : ERREUR

La nouvelle classe a supprimé un champ présent dans l'ancienne version. Code préexistant
qui accède directement à ce champ ne sera plus valide.

6002 - Valeur of champ aucune plus long a lors de la compilation constant

Gravité : AVERTISSEMENT

Le code compilé par rapport à l'ancienne version de la classe était autorisé à « intégrer » le
valeur de ce champ car il s'agissait d'une constante de compilation. Par conséquent, existant
le code binaire continuera à utiliser l'ancienne valeur de ce champ, au lieu de la nouvelle
valeur (qui ne peut pas être inline).

6003 - Valeur of lors de la compilation constant a a changé

Gravité : AVERTISSEMENT

Le code compilé par rapport à l'ancienne version de la classe était autorisé à « intégrer » le
valeur de ce champ car il s'agissait d'une constante de compilation. Par conséquent, existant
le code binaire continuera à utiliser l'ancienne valeur de ce champ, au lieu de la nouvelle
valeur.

6004 - Champ type a changé

Gravité : ERREUR

Le type associé au membre statique ou d'instance spécifié du membre spécifié
la classe a changé. Un code préexistant qui accède directement à ce champ peut ne pas
plus valable, et il s'agit donc d'un changement incompatible.

6005 - Champ maintenant non final

Gravité : INFO

Le champ était auparavant définitif et ne l'est plus. Cela signifie que le champ
La valeur peut désormais être modifiée pendant la durée de vie de la classe ou de l'instance.

Le fait qu'une valeur d'un champ ait pu être précédemment « inline » dans d'autres classes est un
problème traité par les messages 6002 et 6003, pas ce message.

6006 - Champ maintenant finale

Gravité : ERREUR

Le champ ne peut plus être modifié pendant la durée de vie de la classe ou de l'instance.
Le code qui modifiait auparavant ce champ n'est donc plus valide.

6007 - Champ maintenant non statique

Gravité : ERREUR

Le champ est désormais une variable d'instance plutôt qu'une variable de classe. Code qui
accédé précédemment à ce champ via la classe plutôt qu'une instance de la classe
n'est plus valable.

6008 - Champ maintenant statique

Gravité : ERREUR

Le champ est désormais une variable de classe plutôt qu'une variable d'instance.

Pour une raison quelconque (probablement des problèmes d'implémentation internes), la norme Java
déclare que ce changement n'est pas compatible binaire, et qu'un
IncompatibleClassChangeError sera renvoyé si le code est compilé avec "l'ancien"
version d'une classe est utilisée avec une "nouvelle" version pour laquelle un champ est maintenant
statique.

Parce que le code source est autorisé à accéder aux variables de classe via des instances de ce
classe, cela devrait être un changement compatible avec le code source. Cependant actuellement
CLIRR signale cela comme une ERREUR pour la compatibilité du code source également.

6009 - Champ Plus Accessible

Gravité : INFO

Dans la nouvelle version, le champ spécifié est accessible à plus de code qu'il ne l'était
précédemment.

6010 - Champ Moins Accessible

Gravité : ERREUR

Dans la nouvelle version, le champ spécifié est accessible à moins de code qu'il ne l'était
précédemment. Par conséquent, le code existant peut ne plus être valide.

6011 - Supprimé Constante Champ

Gravité binaire : AVERTISSEMENT

Gravité de la source : ERREUR

La nouvelle classe a supprimé un champ présent dans l'ancienne version. Source préexistante
code qui accède directement à ce champ ne sera plus valide.

Auparavant, cependant, le champ était final et était initialisé avec une valeur constante.
Par conséquent, le code compilé par rapport à la version précédente de la classe aura inline
cette constante et continuera à fonctionner, en utilisant la valeur précédente de ce champ. UNE
un avertissement est émis car ce comportement n'est souvent pas souhaitable. Cependant ce n'est pas un
incompatibilité binaire.

7000 - Méthode maintenant in Superclasse

Gravité : INFO

L'ancienne classe avait une méthode nommée X. La nouvelle classe n'a plus cette méthode, mais une
la classe parent définit cette méthode, donc aucune incompatibilité binaire ou source n'a
est produite.

Notez que ce changement peut avoir pour effet de forcer la nouvelle classe à devenir
'abstrait'. Si tel est le cas, ce changement est alors déclaré séparément.

7001 - Méthode maintenant in Interface

Gravité : INFO

L'ancienne classe ou interface avait auparavant une méthode nommée X. La nouvelle classe ou
l'interface n'a plus cette méthode, mais une interface parent la définit
méthode, donc aucune incompatibilité binaire ou source ne s'est produite.

Notez que ce changement peut avoir pour effet de forcer la nouvelle classe à devenir
'abstrait'. Si tel est le cas, ce changement est alors déclaré séparément.

7002 - Méthode Supprimé

Gravité : ERREUR

L'ancienne classe ou interface avait une méthode nommée X. La nouvelle classe ou interface non
n'a plus cette méthode, et cette méthode n'est définie sur aucune classe parente ou
interface.

Le fait qu'une erreur se produise réellement au moment de l'exécution pour ce changement dépend de l'utilisation
motifs. La classe modifiée peut être utilisée avec du code existant tant que cela
le code existant ne tente pas d'appeler la méthode supprimée. Si un appel aux disparus
méthode est créée, une exception NoSuchMethodError est générée lorsque la méthode
l'invocation se produit.

7003 - Méthode Remplacer Supprimé

Gravité : INFO

La méthode spécifiée sur l'ancienne classe ou interface remplaçait une méthode héritée
définition. La nouvelle classe ou interface n'a plus explicitement cette méthode
déclaré dessus, mais il hérite toujours d'une définition donc il n'y a pas de binaire
incompatibilité. 7004 - Le nombre d'arguments de méthode a été modifié

Gravité : ERREUR

La méthode spécifiée a eu des arguments ajoutés ou supprimés. Cela signifie que le code qui
précédemment invoqué, il n'invoquera plus la même méthode.

S'il existe une définition de méthode héritée avec l'ancien prototype, alors il n'y a pas
incompatibilité binaire ; code qui a été compilé avec l'ancienne version de ce
class va maintenant appeler l'implémentation héritée. Dans cette situation, clirr devrait
afficher un message INFO plutôt qu'une erreur. Cependant à la date actuelle, clirr
ne vérifie pas cette situation.

S'il n'y a pas de définition de méthode héritée avec l'ancien prototype, la modification
est une incompatibilité binaire.

7005 - Méthode Argument Type a changé

Gravité binaire : INFO ou ERREUR

Gravité de la source : ERREUR

La méthode spécifiée a vu le type d'un ou plusieurs de ses arguments modifié.
Cela signifie que le code compilé avec l'ancienne version de la classe ne sera plus
invoquer la même méthode. Cependant exactement le même vieux code source, une fois compilé
contre la nouvelle version de classe peut invoquer cette méthode si les types d'arguments sont
compatible avec l'affectation.

S'il existe une définition de méthode héritée avec l'ancien prototype, alors il n'y a pas
incompatibilité binaire ; code qui a été compilé avec l'ancienne version de ce
class va maintenant appeler l'implémentation héritée. A la date actuelle, clirr ne
pas vérifier cette situation.

S'il n'y a pas de définition de méthode héritée avec l'ancien prototype, la modification
est une incompatibilité binaire.

Si les types de paramètres modifiés étaient tous remplacés par des supertypes de leurs précédents
types déclarés, ou pour les types de paramètres primitifs s'ils ont été modifiés en "plus grands"
types dans tous les cas, alors le nouveau code est compatible avec le code source précédent
release même s'il n'est pas compatible binaire. Notez que dans cette situation,
la recompilation du code qui utilise la bibliothèque peut changer son comportement en appelant un
méthode héritée pour appeler une méthode sur la classe qui a une valeur légèrement différente
prototype. A la date actuelle, clirr ne vérifie pas cette situation.

7006 - Méthode Retour Type a changé

Gravité binaire : ERREUR

Gravité de la source : INFO ou ERREUR

Le type de retour déclaré de la méthode spécifiée a été modifié. Qu'il s'agisse d'un problème
se produit en fait au moment de l'exécution lors de l'utilisation de code compilé avec l'ancienne version de ce
bibliothèque dépend des modèles d'utilisation. L'ancien code peut appeler d'autres méthodes sur cette classe.
Cependant, toute tentative d'appel de la méthode dont le type de retour a changé entraînera
une NoSuchMethodError est levée lorsque la méthode est invoquée, car le retour
type fait partie de la « signature de la méthode ».

La modification est compatible avec le code source si et seulement si le nouveau type de retour est
attribuable à l'ancien type de retour. Cela signifie que:

si l'ancien type de retour était un type primitif, le nouveau type de retour doit être
plus étroit que l'ancien type.
si l'ancien type de retour était une interface, le nouveau type de retour doit être un
classe ou interface qui implémente l'ancien type de retour.
si l'ancien type de retour était une classe, le nouveau type de retour doit être une sous-classe
du type précédemment retourné.

Clirr ne vérifie pas actuellement la compatibilité du code source pour les changements de méthode
types de retour ; actuellement, ceux-ci sont simplement signalés comme une ERREUR.

7007 - Méthode a était Obsolète

Gravité : INFO

La méthode spécifiée a été déclarée comme "obsolète". C'est toujours un
un changement compatible binaire ainsi qu'un changement compatible avec le code source.

7008 - Méthode a était Non obsolète

Gravité : INFO

La méthode spécifiée a été déclarée "obsolète" dans la version précédente, mais n'est pas
plus obsolète dans la version actuelle. Bien que légèrement inhabituel, c'est
permis. Ce changement est toujours un changement binaire compatible ainsi qu'un
changement compatible avec le code source.

7009 - Méthode is maintenant Moins Accessible

Gravité : ERREUR

Les autorisations d'accès associées à la méthode spécifiée ont été resserrées pour
autoriser moins de code utilisateur pour accéder à la méthode.

Que ce changement soit un problème de compatibilité du code source ou non dépend de
modèles d'utilisation.

Ce changement devrait être une incompatibilité binaire. Notez, cependant, que les JVM actuelles ne
pas valider cela. Le code compilé par rapport à une version précédente d'une classe peut
invoquer avec succès des méthodes pour lesquelles ils n'ont plus les droits d'accès.
Néanmoins, la spécification du langage Java indique qu'il s'agit d'une erreur, donc
clirr signale ce changement comme une incompatibilité binaire.

7010 - Méthode is maintenant Plus Accessible

Gravité : INFO

Les autorisations d'accès associées à la méthode spécifiée ont été assouplies pour
autoriser plus de code utilisateur pour accéder à la méthode. C'est toujours un code binaire et source
changement compatible.

7011 - Méthode Ajouté

Gravité : INFO

Une méthode non abstraite a été ajoutée à la classe spécifiée. C'est toujours un
changement compatible binaire.

Il s'agit également d'un changement compatible avec le code source.

Q : si la nouvelle méthode remplace une méthode héritée, alors quelle version code
compilé contre l'ancien appel de bibliothèque ?

7012 - Méthode Ajouté à Interface

Gravité binaire : ERREUR

Gravité de la source : ERREUR

Une déclaration de méthode a été ajoutée à l'interface spécifiée. C'est toujours
signalé comme une erreur de compatibilité binaire, mais en pratique, la classe modifiée peut
être utilisé avec succès avec du code compilé avec l'ancienne interface en fonction de
modèles d'utilisation.

Ancien code qui invoque des méthodes sur du code compilé par rapport au nouveau (développé)
l'interface continuera à fonctionner sans problème. Et l'ancien code qui implémente le
l'ancienne version de l'interface continuera également à fonctionner correctement tant qu'aucun
code tente d'invoquer l'une des méthodes nouvellement ajoutées sur cette instance. Mais
code qui invoque (validement) l'une des nouvelles méthodes de l'interface contre un
objet qui implémente uniquement l'ancienne version de l'interface provoquera un
AbstractMethodError à lever au moment où l'invocation de la méthode est tentée.

L'ajout d'une méthode à une interface est toujours signalé comme une ERREUR, car les classes
qui implémentent cette interface doit maintenant être modifiée pour implémenter le
méthode.

7013 - Abstract Méthode Ajouté à Classe

Gravité binaire : ERREUR

Gravité de la source : ERREUR

Une déclaration de méthode abstraite a été ajoutée à la classe spécifiée. C'est
toujours signalé comme une erreur de compatibilité binaire, mais en pratique la classe modifiée
peut être utilisé avec succès avec du code compilé avec l'ancienne classe en fonction de
modèles d'utilisation.

Si des instances d'objets compilés par rapport à l'ancienne classe sont créées, alors leur
méthodes peuvent être invoquées sans problème. Mais si la méthode abstraite nouvellement ajoutée est
jamais invoqué, alors une AbstractMethodError est levée au moment où la méthode
l'invocation est tentée.

7014 - Méthode maintenant finale

Gravité : ERREUR

La méthode était auparavant non définitive et est maintenant définitive. Sous-classes de cette classe
ne sera plus compilé ni exécuté.

Lorsque l'ancienne classe contenant cette méthode était définitive (explicitement ou en fournissant uniquement
constructeurs privés), alors les sous-classes ne peuvent pas exister. Clirr ne vérifie pas actuellement
pour cette situation, cela déclenchera donc une fausse alarme dans certains cas extrêmes.

7015 - Méthode maintenant non final

Gravité : INFO

La méthode était auparavant définitive et est maintenant non définitive. C'est toujours un
changement compatible binaire.

8000 - Classe Ajouté

Gravité : INFO

La nouvelle version de la bibliothèque a une classe qui n'était pas présente dans l'ancienne
version.

8001 - Classe Supprimé

Gravité : ERREUR

La nouvelle version de la bibliothèque ne contient plus la classe spécifiée.

EXEMPLES


Vérifier la compatibilité d'une librairie avec une version précédente :

clirr -o foo-1.0.jar -n foo-2.0.jar

Vérifiez la compatibilité descendante d'une nouvelle bibliothèque en fonction d'Apache Commons Logging :

clirr -o foo-1.0.jar -n foo-2.0.jar -ocp /usr/share/java/commons-logging.jar -ncp
/usr/share/java/commons-logging.jar

HOME


http://clirr.sourceforge.net

Novembre 2013 CLIR(1)

Utilisez clirr en ligne en utilisant les services onworks.net


Serveurs et postes de travail gratuits

Télécharger des applications Windows et Linux

Commandes Linux

Ad




×
Publicité
❤ ️Achetez, réservez ou achetez ici — gratuitement, contribue à maintenir la gratuité des services.