Ich möchte in der Lage sein, zwei Versionen einer Klasse / Bibliothek zu vergleichen, um festzustellen, ob es irgendwelche Änderungen gegeben hat, die den Code, der sie aufruft, brechen könnten. Betrachten wir zum Beispiel eine Klasse Foo mit einer Methode in Version a:
%Vor%und in Version b wird die Methode:
%Vor%oder etwas ähnliches im Falle eines Feldes:
%Vor%Ich möchte ein Werkzeug, das diese Änderungen als mögliche Inkompatibilitäten markiert (aber im Idealfall nicht umgekehrt, d. h. die Sichtbarkeit einer Methode erhöht). Jetzt weiß ich, dass ich dies über Reflexionen tun kann, oder indem ich die Ausgabe von javap analysiere, aber es scheint, dass es ein existierendes Werkzeug geben sollte (vorzugsweise nicht-kommerziell). Also wollte ich sehen, ob irgendjemand etwas empfehlen kann, bevor ich den Fehler mache, mein eigenes Rad zu rollen / das Rad unnötig neu zu erfinden.
Guava verwendet JDiff , um Versionsänderungen , vielleicht finden Sie es auch nützlich?
Ich verstehe die Frage vielleicht nicht, aber ist nicht der Compiler das genaue Werkzeug, das dieses Problem lösen könnte?
Das erneute Kompilieren der Klassen, die Foo für die neue Version von Foo verwenden, leuchtet sehr schnell auf, wenn Inkompatibilitäten auftreten.
Hier ist die Antwort, die Sie nicht wollten, aber ich denke, es ist eine gültige Antwort:
Das erste Problem bei der Neukompilierung von allem Clientcode besteht darin, dass dies möglicherweise nicht möglich ist. Der Code gehört möglicherweise nicht dir; Es könnte sich um benutzerdefinierten Code handeln, den einer Ihrer Kunden geschrieben hat und der Ihnen nicht zur Verfügung steht.
Das zweite Problem bei der Neukompilierung von Client-Code besteht darin, dass Sie manchmal nicht einmal einen Kompilierungsfehler erhalten, da der aufrufende Code nicht geändert werden muss. Ich bin einmal auf ein Problem gestoßen. Ich hatte eine API-Methode wie folgt:
%Vor%mit Code, der dagegen verlinkt. Ich wollte das ändern:
%Vor% Also habe ich das gemacht und neu kompiliert. Es gab keine Fehler, da der Code, der die erste Version von doSomething() aufgerufen hat, automatisch erneut mit der neuen Version verknüpft wurde (wobei der Rückgabewert verworfen wurde, der in Java gültig ist). Wenig wusste ich jedoch, dass es den Bytecode der externen Klasse änderte, als ich neu kompilierte. Wir haben Fehler bei der Aktualisierung der API erhalten, aber der Code, der sie verwendet, wurde nicht neu kompiliert.
Also, anstatt nach Fehlern zu suchen, hätte ich auch nachsehen müssen, bei welchen externen Dateien sich der Bytecode geändert hat. An diesem Punkt würde ich sagen, dass Sie für diesen Zweck nur Komponententests verwenden sollten, da Sie sie sowieso schreiben sollten.
Tags und Links java field compatibility method-signature