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 f

Answer 1

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.

Answer 2

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.)

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.

Answer 4

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.

Answer 5

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.