Neue Schlüsselwörter in Java 9

Question

Eines der größten Features von Java 9 wird ein von Project Jigsaw definiertes Modulsystem sein. Wenn Folien aus der Project Jigsaw: Under the Hood auf der JavaOne 2015 zu lesen, bemerkte ich den folgenden Quellcode:

// src/java.sql/module-info.java 
module java.sql { 
    exports java.sql; 
    exports javax.sql; 
    exports javax.transaction.xa; 
} 

Was mir hier interessant ist, ist, dass die Datei in .java endet und scheint zwei neue Keywords zu verwenden: module und exports. Welche anderen Schlüsselwörter werden in Java 9 eingeführt? Wie wird die Rückwärtskompatibilität gehandhabt (d. H. Funktionen oder Variablen mit dem Namen module)?

Answer 1

Die für Moduldeklarationen in Java 9 hinzugefügten Schlüsselwörter sind in §3 zusammengefasst.9 der Java Language Specification, Java SE 9 Edition:

Weitere zehn Zeichensequenzen sind eingeschränkt Stichwort: open, module, requires, transitive, exports, opens, to, uses, provides und with. Diese Zeichenfolgen werden als Schlüsselwörter ausschließlich in den Fällen, in denen sie in den ModuleDeclaration und ModuleDirective-Produktionen (§7.7) als Schlüsselwörter erscheinen, in Tokens umgewandelt. Sie werden an anderer Stelle als Bezeichner für Kompatibilität mit Programmen geschrieben, die vor Java SE 9 geschrieben wurden. Es gibt eine Ausnahme: sofort der Zeichenfolge erfordert in der ModuleDirective-Produktion, die Zeichenfolge transitives wird als a tokenisiert Schlüsselwort, sofern nicht auf ein Trennzeichen folgt, in diesem Fall wird es als -Kennung in Tokens umgewandelt.

Wenn Sie derzeit eine Methode namens module haben oder eine der anderen Schlüsselwörter hier aufgeführt, wird es kompilieren fortzusetzen.

(view und permits waren Schlüsselwörter in einem frühen Jigsaw Prototyp, aber sie aus der Existenz vereinfacht wurden vor langer Zeit.)

Answer 2

Dies ist wahrscheinlich keine vollständige Liste, und nichts davon wurde nach meinem besten Wissen abgeschlossen, aber ich habe ein paar gefunden.

Wir haben auch module, exports, provides, uses, with, to und requires; here erklärt:

Das Modulsystem Nutzung der Dienste durch Scannen der Klassendateien in Modul Artefakte für Anrufungen der ServiceLoader :: load Methoden identifizieren kann, aber das würde sowohl langsam und unzuverlässig sein. Dass ein Modul einen bestimmten Dienst verwendet, ist ein wesentlicher Aspekt dieser Moduls Definition, so dass für beide Effizienz und Klarheit wir, dass in dem Modul Erklärung äußern mit einem uses-Klausel:

module java.sql { 
    requires public java.logging; 
    requires public java.xml; 
    exports java.sql; 
    exports javax.sql; 
    exports javax.transaction.xa; 
    uses java.sql.Driver; 
} 

Das Modulsystem könnte Service Provider durch Scannen identifizieren Modul-Artefakte für META-INF-/services-Ressourceneinträge, wie die ServiceLoader-Klasse heute tut. Dass ein Modul eine Implementierung eines bestimmten Dienst bereitstellt, ist ebenso von grundlegender Bedeutung, aber, so dass wir ausdrücken, dass in der Erklärung des Moduls mit einer Klausel sieht vor:

module com.mysql.jdbc { 
    requires java.sql; 
    requires org.slf4j; 
    exports com.mysql.jdbc; 
    provides java.sql.Driver with com.mysql.jdbc.Driver; 
} 

...

module java.base { 
    ... 
    exports sun.reflect to 
     java.corba, 
     java.logging, 
     java.sql, 
     java.sql.rowset, 
     jdk.scripting.nashorn; 
} 

Auch view und permits:

In großen Softwaresystemen ist es oft nützlich, mehrere Ansichten derselben zu definieren Modul. Eine Ansicht kann von jedem anderen Modul zur allgemeinen Verwendung deklariert werden, während eine andere Ansicht Zugriff auf interne Schnittstellen bietet, die nur für die Verwendung durch eine Auswahl eng verwandter Module bestimmt sind.

Zum Beispiel möchten wir mit JNDI, dass com.sun.jndi.toolkit.url nur für Cosnaming- und Kerberos-Module sichtbar ist, wie in der Moduldeklaration angegeben.

view jdk.jndi.internal { 
    exports com.sun.jndi.toolkit.url.*; 
    exports sun.net.dns.*; 
    permits jdk.cosnaming; 
    permits jdk.kerberos; 

}

So können wir mehr Flexibilität Modulgrenzen zu definieren.

Ich habe auch Erwähnung von optional gehört.

Answer 3

Für die Rückwärtskompatibilität Teil der Frage.

Ich denke, JAVA9/Projekt Puzzle ist ein Paradigmenwechsel in der Java-Technologie. , so dass Java9 nicht abwärtskompatibel ist, aber Sie können Ihre nicht-modulare Abhängigkeit leicht mit der modularen Version derselben Bibliothek transformieren. Konzept von "No-Pain, No-Gain" wird hier funktionieren. Jeder muss upgraden/umwandeln, um das neue modulare Java zu nutzen. IDE Entwickler, Plugin Entwickler, Build System und natürlich Groove Level Java Entwickler müssen neue Java Systeme verstehen.

JAVA9 befürwortet saubere Abhängigkeit. bietet es auch eine brandneue Möglichkeit, Ihren Code durch private Module zu sichern. selbst die Reflektion kann nicht auf die Module zugreifen, die nicht vom Bibliotheks-/API-Besitzer verfügbar gemacht wurden.

Es gibt zwei Ansätze, um nicht modulare LIB/APIs zu verwenden.

1. Top-Down-Ansatz
2. Bottom-Up-Ansatz (starke Schmerzen hier zu implementieren)

zweiter Ansatz macht eine sehr saubere Modul Abhängigkeitshierarchie.

Answer 4

Modul ist ein neues Schlüsselwort eingeführt, um die Abhängigkeiten zwischen Paketen zu definieren. Warum brauchen wir Module? Weil früher

1. die Kapselung war nicht einwandfrei. Mit Hilfe von Reflektion und mit ähnlichen Techniken konnten wir sogar auf den privaten Bereich zugreifen.
2. Alle Klassen in allen Gläsern waren öffentlich zugänglich.

3. Wenn der Classloader die Klasse nicht bekommt, musste er in viele Bereiche schauen und eine Menge verwandter Dateien laden. Selbst wenn die Klasse nicht gefunden wird, würde NoClassDefFoundErrors zur Laufzeit ausgelöst.

   Aus all den oben genannten Gründen benötigen wir einen Mechanismus, der JVM dies zur Laufzeit wissen lässt. Für das Implementierungsmodul müssen Sie module-info.java definieren. in that package

   module com.exporter{ 
   
       exports com.a; 
       provides com.b.M; 
        with com.b.MImpl; } 
   

In einem anderen Paket,

module com.consume { 
    requires com.a; 
} 

Andere Attribute verwendet werden, sind "Exporte" und "erfordert" zur Herstellung einer inter Abhängigkeit (transitive Abhängigkeit nur) " bietet "und" mit "für die Belichtung Schnittstelle und Erwähnung der Implementierung. Also eine starke Einkapselung, vielleicht, deshalb ist Java 9 eher zum objektorientierten Feature geneigt.