OSGi, Java Modularity und Jigsaw

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

Eigentlich scheint es ziemlich cool zu sein, also möchte ich zunächst (für die Aufzeichnung) sagen, dass ich in keiner Hinsicht gegen OSGi bin, und dies ist auch keine "OSGi-Bashing" -Frage.

Letztendlich scheint es, dass OSGi - im Wesentlichen - angesprochen hat JSR 277 über Java-Modularität befasst zu haben, das erkannte, dass es Mängel bei der JARDateispezifikation gibt, die in bestimmten Eckfällen zu Problemen bei der Auflösung von Namespaces und beim Laden von Klassen führen können. OSGi macht auch viele andere wirklich coole Sachen, aber soweit ich das beurteilen kann, ist das die größte Auslosung (oder eine davon).

Für mich - als ziemlich neuer (seit einigen Jahren) Java EE-Entwickler ist es absolut umwerfend, dass wir uns im Jahr 2011 befinden und derzeit in der Ära von Java 7 leben und dass diese Probleme beim Laden von Klassen immer noch vorhanden sind. Insbesondere in Unternehmensumgebungen, in denen auf einem App-Server Hunderte von JARs installiert sein können, von denen viele von verschiedenen Versionen abhängen und alle (mehr oder weniger) gleichzeitig ausgeführt werden.

Meine Frage:

So interessiert ich mich für OSGi bin und so sehr ich anfangen möchte, etwas 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 können Nicht-OSGi-Entwickler tun, wenn diese Probleme auftreten? Welche Java- Lösungen (Oracle / Sun / JCP) gibt es 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 erhalten, obwohl es noch nicht Teil der Java-Plattform ist?

Ich denke, was ich hier frage, ist eine Kombination aus Panik, Intrigen und einer Gesichtspalme. Jetzt, da ich endlich verstehe, was OSGi ist, "verstehe" ich einfach nicht, wie so etwas wie Jigsaw mehr als 20 Jahre gebraucht hat, um Früchte zu tragen, und wie das aus einer Veröffentlichung hätte stammen können. Es scheint nur grundlegend.

Und als Entwickler bin ich auch neugierig auf meine Lösungen ohne OSGi.

Auch Anmerkung : Ich weiß , dass dies keine „ist reine Programmierung “ -Typ Frage, aber bevor einige von Ihnen Ihre Nasen bekommen gebogen aus der Form, wollte ich in dem Zustand (wieder, für die Aufzeichnung) , dass ich absichtlich diese Frage stelle auf SO. Das liegt daran, dass ich nichts anderes als den größten Respekt vor meinen SO-Kollegen habe und nach einer Antwort auf architektonischer Ebene von einigen der "Götter der IT" suche, die hier jeden Tag herumlungern.

Aber für diejenigen unter Ihnen, die absolut darauf bestehen, dass eine SO-Frage mit einem Codesegment hinterlegt wird:

int x = 9;

(Vielen Dank an alle, die dieses OSGi / Jigsaw / Classloader / Namespace / JAR-Höllenzeug abwägen können!)

Verstehen Sie zunächst, dass der Hauptanwendungsfall 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.

Mein Standpunkt ist, dass so etwas wie Jigsaw wahrscheinlich nur für die JRE notwendig ist, aber dass es weit mehr Probleme verursacht, als es zu lösen behauptet, wenn es von anderen Java-Bibliotheken oder Apps verwendet wird.

Die JRE ist ein sehr schwieriger und besonderer Fall. Es ist über 12 Jahre alt und ein schreckliches Durcheinander, voller Abhängigkeitszyklen und unsinniger Abhängigkeiten. Gleichzeitig wird es von rund 9 Millionen Entwicklern und wahrscheinlich Milliarden laufender Systeme genutzt. Daher können Sie die JRE absolut nicht umgestalten, wenn dieses Umgestalten wichtige Änderungen verursacht.

OSGi ist ein Modulsystem, mit dem Sie modulare Software erstellen (oder sogar dazu zwingen ) können. Sie können Modularität nicht einfach über eine vorhandene nicht modulare Codebasis streuen. Um eine nicht modulare Codebasis in eine modulare zu verwandeln, ist zwangsläufig eine Umgestaltung erforderlich: Verschieben von Klassen in das richtige Paket, Ersetzen der direkten Instanziierung durch die Verwendung entkoppelter Dienste usw.

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

Ich betrachte Jigsaw daher als eine Art " extreme Maßnahme ", um den JRE-Code am Leben zu erhalten, während er aufgeteilt wird. Es hilft nicht, dass Code modularer wird, und ich bin überzeugt, dass es tatsächlich die Wartung erhöht, die erforderlich ist, um eine Bibliothek oder Anwendung zu entwickeln, die es verwendet.

Schließlich: OSGi existiert, während Jigsaw noch nicht existiert und möglicherweise nie existiert. Die OSGi-Community verfügt über 12 Jahre Erfahrung in der Entwicklung modularer Anwendungen. Wenn Sie ernsthaft an der Entwicklung modularer Anwendungen interessiert sind, ist OSGi das einzige Spiel in der Stadt.

Es ist ganz einfach: Wenn Sie heute eine echte komponentenbasierte Entwicklung in Java durchführen möchten, 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-Leuten. 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 sich mit der Funktionsweise des Ladens von Klassen vertraut machen müssen, da eine Reihe bekannter Bibliotheken (Sie betrachten, Ruhezustand) Annahmen über die Sichtbarkeit von Klassen getroffen haben, die nicht mehr gültig sind in OSGi.

Ich mag OSGi, aber ich würde nicht versuchen, es auf ein vorhandenes 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 tun.

Wenn Sie OSGi nicht ausführen, haben Sie Pech, wenn Sie ein System entwickelt haben, das von verschiedenen Versionen derselben Bibliothek abhängig ist. Sie können lediglich versuchen, das Problem zu vermeiden, obwohl Sie mehrere Versionen von a benötigen Bibliothek scheint mir ein Architekturgeruch zu sein.

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

Die JAR-Dateispezifikation weist Mängel auf, die in bestimmten Eckfällen zu Problemen bei der Auflösung von Namespaces und beim Laden von Klassen führen können

Jedenfalls habe ich mich seit vielen Jahren für Tools und Techniken interessiert, die die Erstellung und noch bessere Durchsetzung von Code unterstützen, der sauberer, entkoppelter, kohärenter und wartbarer ist als das, was ohne sie wahrscheinlich das Ergebnis gewesen wäre. Test Driven Design und Junit waren eine solche Kombination.

Nachdem ich einige Monate damit verbracht habe, 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 ausreichender Grund, zu OSGi zu wechseln. Auf lange Sicht sparen Sie viel Geld.

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