web-dev-qa-db-fra.com

Nouveaux mots clés dans Java 9

L'une des principales fonctionnalités de Java 9 sera un système de modules défini par Project Jigsaw. Lors de la lecture des diapositives de Project Jigsaw: Under the Hood à JavaOne 2015, j'ai remarqué code source suivant:

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

Ce qui m'intéresse ici, c'est que le fichier se termine par .Java et semble utiliser deux nouveaux mots clés: module et exports. Quels autres mots clés seront introduits dans Java 9? Comment la compatibilité descendante sera-t-elle traitée (c'est-à-dire les fonctions ou variables nommées module)?

javasyntaxjava-9jigsaw
37
Will Sherwood

Les mots clés ajoutés pour les déclarations de module dans Java 9 sont résumés au §3.9 de la Java Language Specification, Java SE 9 Edition :

Dix autres séquences de caractères sont des mots clés restreints: open, module, requires, transitive, exports, opens , to, uses, provides et with. Ces séquences de caractères sont symbolisées en tant que mots clés uniquement lorsqu'elles apparaissent en tant que terminaux dans les productions ModuleDeclaration et ModuleDirective (§7.7). Ils sont symbolisés comme identifiants partout ailleurs, pour des raisons de compatibilité avec les programmes écrits avant Java SE 9. Il y a une exception: immédiatement à droite de la séquence de caractères nécessite dans la production ModuleDirective, la séquence de caractères transitive est symbolisé en tant que mot clé à moins qu'il ne soit suivi d'un séparateur, auquel cas il est symbolisé en tant qu'identifiant.

Si vous disposez actuellement d'une méthode nommée module, ou de l'un des autres mots clés répertoriés ici, elle continuera à être compilée.

(view et permits étaient des mots-clés dans un premier prototype de Jigsaw, mais ils ont été simplifiés depuis longtemps.)

65
Mark Reinhold

Ce n'est probablement pas une liste complète, et rien de tout cela n'a été finalisé à ma connaissance, mais j'en ai trouvé quelques-uns.

Nous avons également module, exports, provides, uses, with, to et requires; expliqué ici :

Le système de modules pourrait identifier les utilisations des services en analysant les fichiers de classe dans les artefacts de module pour les appels des méthodes ServiceLoader :: load, mais cela serait à la fois lent et peu fiable. Le fait qu'un module utilise un service particulier est un aspect fondamental de la définition de ce module, donc pour l'efficacité et la clarté, nous exprimons cela dans la déclaration du module avec une clause uses:

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

Le système de modules pourrait identifier les fournisseurs de services en analysant les artefacts de module pour les entrées de ressources META-INF/services, comme le fait la classe ServiceLoader aujourd'hui. Le fait qu'un module fournisse une implémentation d'un service particulier est également fondamental, cependant, nous exprimons cela dans la déclaration du module avec une clause provides:

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

view et permits également:

Dans les grands systèmes logiciels, il est souvent utile de définir plusieurs vues du même module. Une vue peut être déclarée pour une utilisation générale par tout autre module, tandis qu'une autre donne accès à des interfaces internes destinées uniquement à être utilisées par un ensemble sélectionné de modules étroitement liés.

Par exemple, avec JNDI, nous voulons que com.Sun.jndi.toolkit.url soit visible uniquement pour les modules cosnaming et kerberos, comme spécifié dans la déclaration du module.

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

}

De cette façon, nous avons plus de flexibilité pour définir les limites des modules.

J'ai également entendu parler de optional.

5
Will

*

module mainModule @ 2.0 {

    requires A @ >= 3.0 ;   // Use version 3 or above  

    //scope:compilation,execution,reflection
    requires B for compilation optional execution;

    requires optional service S1; 
    requires static E; // need at compile time but optional at runtime 

    // let mmm requires mainModule then S2 will automatically be there for mmm
    requires transitive S2; 

    provides MI @ 2.0; 
    provides service MS with C; // provide service with impelemented class C

    exports  pack;  
    exports  pack.abc to D; //qulified export

    permits  MF;
    class    MMain;

    /*
     syntax for creating view
     view ModuleName {
         {ProvidesDir|ExportsDir|PermitsDir|EntrypointDir}
     }
   */

    view N {

        provides service NS with AD;
        exports  MA;
        permits  MB;
        class    Main;

     }
}

* Vérifiez-le, cela peut vous aider.

0
Abhishek Bansal