Also ich bin hier ein alter Mann und verstehe noch nicht wo mir diese Neuerung helfen soll (und bleibt gefaelligst von meinem Rasen unten!). Etwas ernster, ich sehe gerade keinen Anwendungsfall bei dem Module eine Verbesserung bringen, kann aber gut sein dass ich nicht die Zielgruppe bin oder einfach nicht in der richtigen Ecke dafuer. Ich weisz das Module eigentlich den Klassenpfad abloesen sollten, aber dann doch irgendwie was aehnliches geworden sind (Stichwort Versionen von Abhaengigkeiten). Als die beiden Argumente fuer Module hoere ich immer "explizite und klare Abhaengigkeiten" und "Kapselung". Ich fange vielleicht mal damit an wo ich bei meinem Anwendungsfaellen keine Verbesserung sehe.
Beim ausliefern Desktop-Applikationen sehe ich keine Aenderungen ob nun ein Modul oder nicht. Das endgueltige Paket wird von mir gebaut, damit spielt sind Abhaengigkeiten mein Problem, nicht das des Nutzer. Die Laufzeit-Umgebung kontrolliere ich nicht, die Kontrolle ueber das Paket welches ausgefuehrt wird gebe ich genauso ab. Also ob nun eine starke Kapselung erzwungen wird oder nicht kann ich nicht bestimmen. Fuer Desktop Applikationen gibt es dann noch das Argument von Native Images, welchem ich ebenfalls relativ kritisch gegenueber stehe da ich Java verwende weil "Build once, run anywhere", und wenn ich eine Applikation als Native Image ausliefere, ich fuer jedes Zielsystem ein eigenes Paket bauen muss (ich muss dann auch alle testen, theoretisch, und es sind keine Pakete fuer "exotische" oder neue Plattformen verfuegbar, weil die muss man erst bauen). Ist aber ein anderes Thema. (Ja, ich weisz, "Java am Desktop ist tot lolroflmao das macht niemand mehr auf der ganzen Welt rofl!1")
Wenn ich eine Server-Applikation habe, sind die Abhaengigkeiten ebenfalls mein Problem, nicht dass des Admins, spielen also keine Rolle. Die Laufzeit-Umgebung hingegen kontrolliere ich (oder halt der Admin), also was dort passiert liegt bereits unter meiner Kontrolle. Selbiges gilt fuer Servlets und aehnliche. Auch hier sehe ich keine unmittelbare Verbesserung.
Wenn ich eine Bibliothek bereitstelle, wird es hingegen interessanter. Die expliziten Abhaengigkeiten klingen hier nach einer guten Hilfe, da aber weder Versionen noch Repositories inkludiert sind, muss ich erst wieder auf Ivy/Maven/Gradle zurueck fallen um diese zu verwalten. Ebenfalls interessant klingt im ersten Moment die Kapselung, ich kann also einem Benutzer meiner Bibliothek verbieten in das Paket "x.y.z" zu greifen...nur dass mir das nichts nuetzt und ist genauso erzwingbar wie wenn ich das Paket "x.y.impl.z" nennen wuerde. Ich habe eine zeitlang mit ein paar GUI-Bibliotheken zu tun gehabt welche
Wenn ich eine Bibliothek verwende, ist es natuerlich interressant zu sehen dass diese wirklich nur diese Klassen aus dem Paket dort verwendet, ich kann mich aber nicht erinnern dass mich das jemals interessiert hat. Wenn die Bibliothek "A" API "B" implementiert aber in Wahrheit von "C" Implementierungsdetails zieht, habe ich so oder so verloren als Benutzer von "A", egal ob Module oder nicht. Klar, "C" koennte das mit einem Modul verhindern, aber zum einen "A" einen Grund dafuer haben, und zum anderen kann "A" ja einfach d'rum herum arbeiten und es wieder umgehen.
So wie ich die Beschreibungen des Modul-Systems bis jetzt verstanden habe, klingt der Anwendungsfall nach Embedded. So etwas wie Android, nur noch zugesperrter, wo man mehrere unbekannte Module in die selbe Laufzeitumgebung laedt und diese so gut von einander trennen will wie man kann.
Kann mich hier jemand aufklaeren was genau ich uebersehe?
Beim ausliefern Desktop-Applikationen sehe ich keine Aenderungen ob nun ein Modul oder nicht. Das endgueltige Paket wird von mir gebaut, damit spielt sind Abhaengigkeiten mein Problem, nicht das des Nutzer. Die Laufzeit-Umgebung kontrolliere ich nicht, die Kontrolle ueber das Paket welches ausgefuehrt wird gebe ich genauso ab. Also ob nun eine starke Kapselung erzwungen wird oder nicht kann ich nicht bestimmen. Fuer Desktop Applikationen gibt es dann noch das Argument von Native Images, welchem ich ebenfalls relativ kritisch gegenueber stehe da ich Java verwende weil "Build once, run anywhere", und wenn ich eine Applikation als Native Image ausliefere, ich fuer jedes Zielsystem ein eigenes Paket bauen muss (ich muss dann auch alle testen, theoretisch, und es sind keine Pakete fuer "exotische" oder neue Plattformen verfuegbar, weil die muss man erst bauen). Ist aber ein anderes Thema. (Ja, ich weisz, "Java am Desktop ist tot lolroflmao das macht niemand mehr auf der ganzen Welt rofl!1")
Wenn ich eine Server-Applikation habe, sind die Abhaengigkeiten ebenfalls mein Problem, nicht dass des Admins, spielen also keine Rolle. Die Laufzeit-Umgebung hingegen kontrolliere ich (oder halt der Admin), also was dort passiert liegt bereits unter meiner Kontrolle. Selbiges gilt fuer Servlets und aehnliche. Auch hier sehe ich keine unmittelbare Verbesserung.
Wenn ich eine Bibliothek bereitstelle, wird es hingegen interessanter. Die expliziten Abhaengigkeiten klingen hier nach einer guten Hilfe, da aber weder Versionen noch Repositories inkludiert sind, muss ich erst wieder auf Ivy/Maven/Gradle zurueck fallen um diese zu verwalten. Ebenfalls interessant klingt im ersten Moment die Kapselung, ich kann also einem Benutzer meiner Bibliothek verbieten in das Paket "x.y.z" zu greifen...nur dass mir das nichts nuetzt und ist genauso erzwingbar wie wenn ich das Paket "x.y.impl.z" nennen wuerde. Ich habe eine zeitlang mit ein paar GUI-Bibliotheken zu tun gehabt welche
final
und package-private
sehr, sehr freizuegig verwendet haben um ihre Vorstellungen von Kapselung durchzusetzen. Das Ergebnis am Ende war dass ich die entsprechenden Dateien in mein Projekt kopiert, gepatcht und einfach im Klassenpfad zuerst gesetzt habe um die Funktionalitaet zu erzielen welche ich haben musste. Ja, der "korrekte" Weg waere ein Ticket zu oeffnen am besten mit MR...ich brauche die Funktionalitaet aber *jetzt* nicht in sechs Monaten nach wochenlanger Diskussion wieso ich das will. Also ist es ein interessanter Mechanismus, aber nicht erzwingbar und damit in etwa der gleiche Wert wie wenn ich es im Javadoc vermerke (die Javadoc Notiz haette fuer den Benutzer sogar den Vorteil dass dieser nicht erst durch Reifen springen muss wenn er es doch machen will).Wenn ich eine Bibliothek verwende, ist es natuerlich interressant zu sehen dass diese wirklich nur diese Klassen aus dem Paket dort verwendet, ich kann mich aber nicht erinnern dass mich das jemals interessiert hat. Wenn die Bibliothek "A" API "B" implementiert aber in Wahrheit von "C" Implementierungsdetails zieht, habe ich so oder so verloren als Benutzer von "A", egal ob Module oder nicht. Klar, "C" koennte das mit einem Modul verhindern, aber zum einen "A" einen Grund dafuer haben, und zum anderen kann "A" ja einfach d'rum herum arbeiten und es wieder umgehen.
So wie ich die Beschreibungen des Modul-Systems bis jetzt verstanden habe, klingt der Anwendungsfall nach Embedded. So etwas wie Android, nur noch zugesperrter, wo man mehrere unbekannte Module in die selbe Laufzeitumgebung laedt und diese so gut von einander trennen will wie man kann.
Kann mich hier jemand aufklaeren was genau ich uebersehe?