New Keywords in Java 9

The keywords added for module declarations in Java 9 are summarized in§3.9 of the Java Language Specification, Java SE 9Edition:

A further ten character sequences are restricted keywords: open, module, requires, transitive, exports, opens, to, uses, provides, and with. These character sequences are tokenized as keywords solely where they appear as terminals in the ModuleDeclaration and ModuleDirective productions (§7.7). They are tokenized as identifiers everywhere else, for compatibility with programs written prior to Java SE 9. There is one exception: immediately to the right of the character sequence requires in the ModuleDirective production, the character sequence transitive is tokenized as a keyword unless it is followed by a separator, in which case it is tokenized as an identifier.

If you presently have a method named module, or any of the otherkeywords listed here, it will continue to compile.

(view and permits were keywords in an early Jigsaw prototype, butthey were simplified out of existence long ago.)

This is likely not a complete list, and none of this has been finalized to the best of my knowledge, but I found a few.

We also have module, exports, provides, uses, with, to, and requires; explained here:

The module system could identify uses of services by scanning the class files in module artifacts for invocations of the ServiceLoader::load methods, but that would be both slow and unreliable. That a module uses a particular service is a fundamental aspect of that module’s definition, so for both efficiency and clarity we express that in the module’s declaration with a uses clause:

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

The module system could identify service providers by scanning module artifacts for META-INF/services resource entries, as the ServiceLoader class does today. That a module provides an implementation of a particular service is equally fundamental, however, so we express that in the module’s declaration with a provides clause:

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

Also view and permits:

In large software systems it is often useful to define multiple views of the same module. One view can be declared for general use by any other module, while another provides access to internal interfaces intended only for use by a select set of closely-related modules.

For example with JNDI we want that com.sun.jndi.toolkit.url be visible only for cosnaming and kerberos modules, as specified in the module declaration.

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

}

This way we have more flexibility to define module boundaries.

I've also heard mention of optional.

*

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

*Check it out it may help you.