Skip to content

Instantly share code, notes, and snippets.

@nipafx
Last active January 21, 2016 07:04
Show Gist options
  • Save nipafx/2173ff2d64cadaf119e0 to your computer and use it in GitHub Desktop.
Save nipafx/2173ff2d64cadaf119e0 to your computer and use it in GitHub Desktop.
Abstract für JUG-KA-Treffen im März

Mit Project Jigsaw und Java 9 wird die Plattform modular. Das soll Sicherheit, Performance und Skalierbarkeit verbessern.

Aber nicht nur das JDK selbst, sondern auch Bibliotheken und Anwendungen steht der Weg in die Modularisierung offen. Mit dem Verlassen des fragilen Class Path soll der JAR Hell entkommen und die Wartbarkeit großer Anwendungen deutlich verbessert werden.

Die Vorträge zeigen die wichtigsten Features von Project Jigsaw anhand des Beispiels der Modularisierung einer bestehenden Anwendung:

  • Definition von Modulen und Modulgraphen
  • Laufzeitverhalten bei der Verletzung von Modularisierungsregeln
  • Integration von nicht-modularen 3rd-Party-Abhängigkeiten
@nipafx
Copy link
Author

nipafx commented Jan 20, 2016

Änderungsvorschläge von Florian:

-Aber nicht nur das JDK selber sondern auch Bibliotheken und Anwendungen steht der Weg in die Modularisierung offen.
-Mit dem Verlassen des fragilen Class Path soll der JAR Hell entkommen und die Wartbarkeit großer Anwendungen deutlich verbessert werden.
+Aber nicht nur das JDK selbst, sondern auch Bibliotheken und Anwendungen steht der Weg in die Modularisierung offen.
+Mit dem Verlassen des fragilen Classpaths soll der JAR Hell entkommen und die Wartbarkeit großer Anwendungen deutlich verbessert werden.

-Die Vorträge zeigen die wichtigsten Features von Project Jigsaw:
-* Erstellen von Modulen
-* Analysieren und abbilden von Abhängigkeiten
-* Migration einer bestehenden Anwendung
+Die Vorträge zeigen die wichtigsten Features von Project Jigsaw anhand des Beispiels der Modularisierung einer bestehenden Anwendung:
+* Definition von Modulen und Modulgraphen
+* Laufzeitverhalten bei der Verletzung von Modularisierungsregeln
+* Integration von nicht-modularen 3rd-Party-Abhängigkeiten

@nipafx
Copy link
Author

nipafx commented Jan 20, 2016

Ich habe alles übernommen außer "Class Path" ~> "Classpath". State Of The Module System und die Dokumentation verwenden die getrennte Schreibweise.

@ftrossbach
Copy link

Ah ok, dann passt das für mich soweit alles :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment