OSGi, Java-Modularität und Jigsaw

Also bis gestern Morgen hatte ich keine Ahnung, was OSGi überhaupt war. OSGi war nur ein Schlagwort, das mir immer wieder begegnete, und so nahm ich mir endlich etwas Zeit, um es aufzufrischen.

Es scheint tatsächlich ziemlich cooles Zeug zu sein, also möchte ich damit beginnen (fürs Protokoll), dass ich in keiner Hinsicht gegen OSGi bin, noch ist dies eine Frage zum „OSGi-Bashing“.

Am Ende des Tages scheint es, dass OSGi – im Wesentlichen – angegangen ist JSR 277 on Java Modularity, die erkannte, dass es Mängel bei der gibt JAR Dateispezifikation, die in bestimmten Ausnahmefällen zu Problemen mit der Namensraumauflösung und dem Laden von Klassen führen kann. OSGi macht auch viele andere wirklich coole Sachen, aber soweit ich feststellen kann, ist das seine größte Attraktion (oder eine davon).

Für mich – als ziemlich neuer (seit einigen Jahren) Java EE-Entwickler – ist es absolut verblüffend, dass wir uns im Jahr 2011 befinden und derzeit in der Ära von Java 7 leben und dass diese Classloading-Probleme immer noch vorhanden sind; insbesondere in Unternehmensumgebungen, in denen ein App-Server Hunderte von JARs enthalten kann, von denen viele von verschiedenen Versionen der anderen abhängen und alle (mehr oder weniger) gleichzeitig ausgeführt werden.

Meine Frage:

So interessiert ich auch an OSGi bin und so sehr ich anfangen möchte, darüber zu lernen, um zu sehen, wo/ob es für meine Projekte von Nutzen sein könnte, ich habe einfach nicht die Zeit, mich hinzusetzen und etwas so Großes zu lernen, zumindest jetzt.

Was also sollen Nicht-OSGi-Entwickler tun, wenn diese Probleme auftreten? Was Java (Oracle/Sun/JCP) Lösungen existieren derzeit, falls vorhanden? Warum wurde Jigsaw aus J7 geschnitten? Wie sicher ist die Community, dass Jigsaw nächstes Jahr in J8 implementiert wird? Ist es möglich, Jigsaw für Ihr Projekt zu bekommen, obwohl es noch nicht Teil der Java-Plattform ist?

Ich schätze, was ich hier verlange, ist eine Kombination aus Panik, Intrigen und einem Facepalm. Jetzt, wo ich endlich verstehe, was OSGi ist, verstehe ich einfach nicht, wie es über 20 Jahre gedauert hat, bis etwas wie Jigsaw zum Tragen kam, und wie das dann aus einer Veröffentlichung hätte entfernt werden können. Es scheint einfach grundlegend zu sein.

Und als Entwickler bin ich auch neugierig, was meine Lösungen ohne OSGi sind.

Ebenfalls, Notiz: Ich weiß, das ist kein “reine Programmierung“-Typ-Frage, aber bevor sich einige von Ihnen die Nase verbiegen, wollte ich (noch einmal fürs Protokoll) sagen, dass ich diese Frage absichtlich an SO gestellt habe. Das liegt daran, dass ich nichts als den größten Respekt vor meinem Kollegen habe SOers und ich suchen nach einer Antwort auf architektonischer Ebene von einigen der „Götter der IT“, die ich hier jeden Tag lauern sehe.

Aber für diejenigen unter Ihnen, die absolut pochen dass eine SO-Frage mit einem Codesegment unterstützt wird:

int x = 9;

(Danke an alle, die sich zu diesem OSGi/Jigsaw/classloader/namespace/JAR-Höllenkram äußern können!)

Verstehen Sie zunächst, dass der primäre Anwendungsfall von Jigsaw darin besteht, die JRE selbst zu modularisieren. Als sekundäres Ziel wird ein Modulsystem angeboten, das von anderen Java-Bibliotheken und -Anwendungen verwendet werden kann.

Meine Position ist die etwas wie Jigsaw ist wahrscheinlich nur für die JRE erforderlich, wird aber weitaus mehr Probleme verursachen, als es zu lösen vorgibt, wenn es von anderen Java-Bibliotheken oder -Apps verwendet wird.

Die JRE ist ein sehr schwieriger und spezieller Fall. Es ist über 12 Jahre alt und ein furchtbares Durcheinander, gespickt mit Abhängigkeitszyklen und unsinnigen Abhängigkeiten. Gleichzeitig wird von ungefähr verwendet 9 Millionen Entwickler und wahrscheinlich Milliarden von laufenden Systemen. Daher können Sie die JRE auf keinen Fall umgestalten, wenn diese Umgestaltung zu Breaking Changes führt.

OSGi ist ein Modulsystem, das Ihnen hilft (oder sogar Kräfte Sie) Software zu erstellen, die modular ist. Sie können Modularität nicht einfach auf eine bestehende nicht-modulare Codebasis streuen. Um eine nicht-modulare Codebasis in eine modulare umzuwandeln, ist zwangsläufig ein gewisses Refactoring erforderlich: Verschieben von Klassen in das richtige Paket, Ersetzen der direkten Instanziierung durch die Verwendung von entkoppelten Diensten und so weiter.

Dies macht es schwierig, OSGi direkt auf die JRE-Codebasis anzuwenden, aber wir müssen die JRE immer noch in separate Teile oder “Module” aufteilen, damit abgespeckte Versionen der JRE geliefert werden können.

Ich betrachte Jigsaw daher als eine Art “extreme Maßnahme“, um den JRE-Code beim Aufteilen am Leben zu erhalten. Das tut es nicht Hilfecode modularer werden, und ich bin überzeugt, dass dies tatsächlich den Wartungsaufwand erhöhen wird, der erforderlich ist, um eine Bibliothek oder Anwendung weiterzuentwickeln, die ihn verwendet.

Schließlich: OSGi existiert, während Jigsaw noch nicht existiert und vielleicht nie existieren wird. Die OSGi-Community verfügt über 12 Jahre Erfahrung in der Entwicklung modularer Anwendungen. Wenn Sie ernsthaft daran interessiert sind, modulare Anwendungen zu entwickeln, ist OSGi das einzige Spiel in der Stadt.

Es ist ganz einfach, wenn Sie heute echte komponentenbasierte Entwicklung in Java durchführen wollen, dann ist OSGi das einzige Spiel in der Stadt.

Meiner Meinung nach ist Jigsaw eine Kombination aus einem Kompromiss zwischen dem, was im JDK machbar ist, und einer früheren schlechten Beziehung zwischen SUN und den OSGi-Jungs. Vielleicht wird es mit Java 8 ausgeliefert, aber wir müssen abwarten und sehen.

OSGi ist kein Allheilmittel, wenn Sie in einer typischen Unternehmensumgebung arbeiten, und Sie müssen sich damit vertraut machen, wie das Laden von Klassen funktioniert, da eine Reihe bekannter Bibliotheken (sieh dich an, Hibernate) Annahmen über die Klassensichtbarkeit getroffen haben, die nicht mehr gültig sind innerhalb von OSGi.

Ich mag OSGi, aber ich würde nicht versuchen, es in einem bestehenden System nachzurüsten. Ich würde auch die Vor- und Nachteile in Bezug auf die Entwicklung auf der grünen Wiese abwägen – ich würde empfehlen, sich die Apache- oder Eclipse-Produkte anzusehen, die das Leben für OSGi vereinfachen, und nicht alles selbst zu machen.

Wenn Sie nicht mit OSGi arbeiten, haben Sie Pech, wenn Sie ein System entwickelt haben, das Abhängigkeiten von verschiedenen Versionen derselben Bibliothek aufweist – alles, was Sie tun können, ist zu versuchen, das Problem zu vermeiden, obwohl Sie mehrere Versionen von a benötigen Bibliothek erscheint mir wie ein Architektur-„Geruch“.

Ich finde es toll, dass Sie den Ausdruck „Eckfälle“ verwenden, um die aktuelle Situation zu beschreiben.

Es gibt Mängel bei der JAR-Dateispezifikation, die in bestimmten Ausnahmefällen zu Problemen mit der Namespace-Auflösung und dem Laden von Klassen führen können

Wie auch immer, ich interessiere mich seit vielen Jahren für Werkzeuge und Techniken, die die Erstellung und, noch besser, die Durchsetzung von Code unterstützen, der sauberer, entkoppelter, kohärenter und wartbarer ist als das, was wahrscheinlich ohne sie das Ergebnis gewesen wäre. Test Driven Design und Junit waren so eine Kombination.

Nachdem wir einige Monate damit verbracht haben, einen wesentlichen Teil unserer Codebasis auf OSGi umzustellen, würde ich sagen, dass OSGi in dieser Hinsicht ein noch besseres Werkzeug ist. Und das ist wirklich ein Grund genug, zu OSGi zu wechseln. Auf lange Sicht spart es Ihnen viel Geld.

Und als Bonus gibt es dir die Chance, viele coole Sachen zu machen. Stellen Sie sich vor, während einer Demo das Authentifizierungsmodul nahtlos und ohne Verkehrsverlust zu aktualisieren, um OAuth zu unterstützen … es ist plötzlich wieder eine Freude, Dinge zu erstellen!