New Keywords in Java 9

Question

One of Java 9's largest features will be a module system defined by Project Jigsaw. When reading slides from the Project Jigsaw: Under the Hood at JavaOne 2015, I noticed the following source code:

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

What is interesting here to me is that the file ends in .java and seems to use two new keywords: module, and exports. What other keywords will be introduced in Java 9? How will backwards compatibility be dealt with (i.e. functions or variables named module)?

Crackbrained

I think at some point we're also going to get ref and any. – Student

@PaulBoddington certainly not in Java 9 for any keyword. That is Valhalla, ie. 10 or later. – Monoceros

"How will backwards compatibility be dealt with", presumably the same as always: you have to compile affected files with an older source version – Handley

Answer 1

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

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 other keywords listed here, it will continue to compile.

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

Eroto

Do you have any information on view and permits, just for history/documentation porpuses? – Landlord

Seems like transitive is missing to the list? – Gaiser

Restricted keywords are such an awesome idea. I wish they'd be used more often. – Bolero

open and opens are missing too. – Cypsela

"as of release 9, '_' is a keyword, and may not be used as an identifier" This is a breaking change. – Cancer

"Simplified out of existence". What a graceful way to say that something has been removed :) – Parvis

Answer 2

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.

Barracoon

I know of the class Optional<T> but they are really considering making that a keyword? Do you have JEP on that one? – Crackbrained

Not to mention... with and to are very commonly used as variable names. I hope that the keywords are only relevantly used within a module definition! – Crackbrained

Hopefully! I can't find good official sources, but Jigsaw Project documentation seems to suggest that they are "modifiers" rather than keywords... Hopefully they aren't reserved when used out of context of module. – Barracoon

Answer 3

*

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.

Papillose

Answer 4

moduleis a new keyword introduced to define the interdependencies between packages. Why we need modules? Because earlier

1. the encapsulation was not immaculate. With the help of reflection and with similar techniques we could access even the private field.

2. All classes in all jars were publicly accessible.

3. If the Classloader does not get the class it had to look into a lot of areas and load a lot of related files and even after that if the Class is not found, it would throw NoClassDefFoundErrors at run time.

   So for all the above reasons we need a mechanism which lets JVM to know this at runtime. For implementing module, you need to define module-info.java. in that package

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

In some other package,

module com.consume {
    requires com.a;
}

Other attributes used are "exports" and "requires" for making an inter dependency(transitive dependency only), "provides" and "with" for exposing interface and mentioning implementation. So it a strong encapsulation, may be, that is why java 9 is more inclined to better Object Oriented feature.

Bainbrudge

Answer 5

For the backward compatibility part of the question.

I think JAVA9/project jigsaw is a paradigm shift in the Java technology. so that java9 will not be backward compatible, but you can easily transform your non-modular dependency with the modular version of the same library. concept of "No-Pain , No-Gain" will work here. Everyone has to upgrade/transform to take advantage of the new modular java. IDE developer, plugin developer, Build System and of course groud level java developer need to understand new java systems.

JAVA9 advocates for clean dependency. it also provide a brand new way to secure your code by private modules. even reflection can not access the modules not exposed by the library/API owner.

There are two approach to use non-modular LIB/APIs.

1. Top-Down approach
2. Bottom-Up approach (lot of pain here to implement)

second approach make a very clean module dependency hierarchy.

Redcap

“so that java9 will not be backward compatible…” Incorrect. If your program defines no modules, it will work exactly like it does in Java 8. – Dispend

Your program will work the same unless you access internal api or try to use reflection on anything in a module. – Heliogravure