Nuove parole chiave in Java 9

Question

Una delle principali funzionalità di Java 9 sarà un sistema di moduli definito da Project Jigsaw. Durante la lettura di diapositive dal Project Jigsaw: Under the Hood a JavaOne 2015, ho notato il seguente codice sorgente:

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

Ciò che è interessante qui per me è che il file termina in .java e sembra usare due nuove parole chiave: module e exports. Quali altre parole chiave saranno introdotte in Java 9? Come verrà gestita la retrocompatibilità (cioè funzioni o variabili denominate module)?

Answer 1

Le parole chiave aggiunte per le dichiarazioni modulo in Java 9 sono riepilogate in §3.9 del Java Language Specification, Java SE 9 Edition: parole

Altri dieci sequenze di caratteri sono limitate: open, module, requires, transitive, exports, opens, to, uses, provides e with. Queste sequenze di caratteri vengono tokenizzate come parole chiave solo dove appaiono come terminali nelle produzioni ModuleDeclaration e ModuleDirective (§7.7). Vengono tokenizzati come identificatori ovunque, per compatibilità con i programmi scritti precedenti a Java SE 9. Esiste un'eccezione: immediatamente a destra della sequenza di caratteri richiede nella produzione ModuleDirective, la sequenza di caratteri transitoria viene tokenizzata come parola chiave a meno che non sia seguito da un separatore, nel qual caso viene tokenizzato come identificatore .

Se attualmente si dispone di un metodo denominato module, o uno qualsiasi degli altri chiavi elencate qui, continuerà a compilare.

(view e permits erano le parole chiave in un primo prototipo Jigsaw, ma sono stati semplificati di esistere molto tempo fa.)

Answer 2

Questa probabilmente non è una lista completa, e nessuna di queste è stata finalizzata per quanto ne so, ma ne ho trovate alcune.

Abbiamo anche module, exports, provides, uses, with, to e requires; ha spiegato here:

Il sistema di modulo potrebbe identificare usi di servizi attraverso la scansione dei file di classe in manufatti di moduli per le invocazioni dei metodi ServiceLoader :: carico, ma che sarebbe sia lento e inaffidabile. Che un modulo utilizza un particolare servizio è un aspetto fondamentale della definizione di quel modulo, quindi sia per l'efficienza e chiarezza esprimiamo che nella dichiarazione del modulo con un utilizza clausola:

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; 
} 

Il sistema modulare in grado di identificare i fornitori di servizi mediante scansione risorse del modulo per le voci di risorse META-INF/servizi, come fa oggi la classe ServiceLoader. Che un modulo fornisce un'implementazione di un particolare servizio è altrettanto fondamentale, tuttavia, in modo esprimiamo che nella dichiarazione del modulo con una clausola di fornisce:

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; 
} 

anche view e permits:

Nei sistemi software di grandi dimensioni è spesso utile definire più viste della stessa modulo. Una vista può essere dichiarata per uso generale da qualsiasi altro modulo, mentre un'altra fornisce l'accesso alle interfacce interne destinate esclusivamente all'uso di un insieme selezionato di moduli strettamente correlati.

Ad esempio con JNDI vogliamo che com.sun.jndi.toolkit.url sia visibile solo per i moduli cosnaming e kerberos, come specificato nella dichiarazione del modulo.

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

}

In questo modo abbiamo più flessibilità per definire i confini del modulo.

Ho anche sentito parlare di optional.

Answer 3

Per la parte retrocompatibilità della questione.

Penso che JAVA9/project jigsaw sia un cambio di paradigma nella tecnologia Java. in modo che java9 non sia compatibile con le versioni precedenti, ma è possibile trasformare facilmente la dipendenza non modulare con la versione modulare della stessa libreria. concetto di "No-Pain, No-Gain" funzionerà qui. Ognuno deve aggiornare/trasformare per sfruttare il nuovo java modulare. Sviluppatore IDE, sviluppatore plug-in, sistema di compilazione e, naturalmente, sviluppatore Java di livello groud devono comprendere i nuovi sistemi java.

JAVA9 difende la dipendenza pulita. fornisce anche un nuovo modo per proteggere il codice con moduli privati. anche il reflection non può accedere ai moduli non esposti dal proprietario della libreria/dell'API.

Esistono due metodi per utilizzare le librerie/API non modulari.

1. approccio top-down
2. approccio bottom-up (molto dolore qui per implementare)

secondo approccio fare una gerarchia di dipendenze dei moduli molto pulito.

Answer 4

modulo è un nuovo parola introdotto per definire le interdipendenze tra pacchetti. Perché abbiamo bisogno di moduli? Perché in precedenza

1. l'incapsulamento non era immacolato. Con l'aiuto della riflessione e con tecniche simili potremmo accedere anche al campo privato.
2. Tutte le classi in tutti i barattoli erano accessibili al pubblico.

3. Se il Classloader non ottiene la classe, ha dovuto esaminare molte aree e caricare molti file correlati e anche in seguito, se la classe non viene trovata, genera NoClassDefFoundErrors in fase di esecuzione.

   Quindi, per tutti i motivi di cui sopra, abbiamo bisogno di un meccanismo che permetta a JVM di sapere questo in fase di esecuzione. Per l'implementazione del modulo, è necessario definire module-info.java. in that package

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

In qualche altro pacchetto,

module com.consume { 
    requires com.a; 
} 

Altri attributi utilizzati sono "esportazioni" e "richiede" per fare un inter dipendenza (solo la dipendenza transitiva), " fornisce "e" con "per esporre l'interfaccia e menzionare l'implementazione. Quindi può essere un forte incapsulamento, ecco perché java 9 è più incline a una migliore funzione orientata agli oggetti.