Frage

Dies ist ein häufiges Problem. Ich benutze 2 Bibliotheken Angelehnt und B.Jar und diese hängen von verschiedenen Versionen desselben Glass ab.
Nehmen wir an, ich brauche zur Laufzeit This.xxxjar

MY.jar   
     -> A.jar -> THIS.1.0.0.jar
     -> B.jar -> C.jar -> THIS.5.0.0.jar

Ich kann das spezifische Glas (A.Jar/B.Jar) gegen seine Abhängigkeit kompilieren, aber zur Laufzeit lade ich nur 1 Version. Welcher?
Das Laden von nur 1 Abhängigkeit (die neueste Version) bedeutet, dass mein Code wahrscheinlich Runtime -Ausnahmen auslöst, wenn die Bibliotheken nicht rückwärtskompatibel sind (gibt es da draußen rückwärts kompatible Bibliotheken?).

Wie auch immer, ich weiß, dass so etwas wie OSGI dieses Problem beheben kann.
Ich frage mich, was der alte Weg ist, um diese Art von Problemen zu beheben ...

Danke vielmals

War es hilfreich?

Lösung

"Old Way", das Sie erwähnt haben (und das OSGI verwendet sicherlich unter der Haube), Ihren eigenen Klassenloader für beide Zweige Ihrer Abhängigkeiten zu installieren. So können Anwendungsserver beispielsweise sowohl ältere als auch neuere Versionen derselben Anwendung innerhalb desselben JVM ausführen.

Lesen Sie mehr über die Classloader -Hierarchie.

In Ihrem Setup ist der schwierige Teil der gemeinsame Punkt, an dem sich Klassen aus beiden Zweigen treffen. Keine der Zweige können Klassen verwenden, die in einen anderen geladen sind. Die Möglichkeit, es zum Laufen zu bringen, besteht darin, sicherzustellen, dass nur Klassen, die vom Boot Classloader (JRE -Klassen) oder Klassenloader von my.jar geladen werden, an beide Zweige weitergegeben werden.

Andere Tipps

OSGI kann dieses Problem beheben. Ein OSGI -Bundle ist nichts anderes als ein Glas mit zusätzlichen Metadaten -Detailversionen. Ein Bundle hat eine Versionsnummer und detailliert Versionsnummern (oder Bereiche) von abhängigen Gläser.

Sich ansehen Dieser einführende JavaRld -Artikel für mehr Informationen.

Um dies ohne OSGI zu lösen, müssen Sie manuell sicherstellen, dass Sie kompatible Gläser kompilieren und ausführen. Wie Sie festgestellt haben, ist dies nicht unbedingt eine triviale Aufgabe. Da Gläser ihre Versionen nicht unbedingt identifizieren, ist der einzige Weg, um dies zu tun, um Prüfsummen oder Unterschriften aufzuzeichnen/zu vergleichen.

Viele Bibliotheken sind rückwärtskompatibel. Aber nicht alles..


Der alte Weg besteht darin, zu versuchen, nur von einer Version abhängig zu sein.

Es ist wahrscheinlich sicherer, beide mit derselben Version zu kompilieren (neueste).
Zumindest erhalten Sie Kompilierungszeitfehler anstelle von Laufzeitfehlern.

Bei Bedarf können Sie Ihre Bibliothek ein wenig ändern, die mit der alten Abhängigkeit funktioniert ...
Dies würde Zugriff auf die Quelle erfordern ...


Bitte beachten Sie, dass Kompatibilität für Kompilierzeiten auch nicht das korrekte Laufzeitverhalten garantiert. Es ist ein Schritt, dann können Sie:

  • Lesen Sie die WhatsNew -Datei für die neue Version des Glass
  • Sehen Sie sich im Internet nach Benutzern, die Kompatibilitätsprobleme melden
  • Schreiben Sie Jungits
  • Vergleichen Sie die Codes in beiden Gläser

Wie von KLE erwähnt, ist der Standardansatz von der neueren Version abhängig. Es gibt keine Garantie, aber die meiste Zeit funktioniert dies. Wahrscheinlich ist der beste Weg (während ein aufgeblähtes) OSGI verwendet, um darüber hinwegzukommen.

Um eine grundlegende "Oldway" -implementierungskasse zu verweisen https://github.com/atulsm/elasticsearchClassloader

Dies bietet einen Ansatz, um nicht rückwärts kompatible Versionen der Nutzung von Elasticsearch-Kunden zu verarbeiten.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top