As you can imagine, the impact of this change is indeed significant, and it pretty much affects the way we write all Java code from now on. In Java 8 and earlier, you didn't have to think twice about using any Java API. All you had to do is import the types you need into your code. Since the JVM knew where to find rt.jar, the necessary classes were always found by the runtime. That's no longer the case with Java 9. Remember in Chapter 3, Handling Inter-Module Dependencies , when you needed a class in the packt.addressbook module from the packt.sortutil module? You couldn't just import the class in your code and use it. You had to go to the module definition of packt.addressbook and specify the dependency on the module using the requires clause. That's exactly what you'll need to do for native Java platform types too!

Need to use Java SQL APIs? They are in the module java.sql, so in the module where you need them, you need to specify this in the module descriptor:

    module mymodule { 
      requires java.sql; 
    } 

Once you have required the necessary platform module, its APIs are then ready for use in your module. Since the java.sql module is built on the same Java module system that you use to write your code, you can bet that there's code in the module-info file of the java.sql module that exports the java.sql and javax.sql packages that contain the Java SQL API.

This necessity to require modules before using them applies not just to our own modules; it applies to the Java modules too. For example, the java.sql module requires logging functionality (for obvious reasons). And the logging APIs are in the java.logging module. So, there's a requires declaration in java.sql module's module-info.java file specifying this requirement. That's the only way code in the java.sql module can import and use the logging APIs.

This is how the module-info.java of java.sql module should look to enable the configuration we've discussed so far:

    module java.sql { 
      ... 
      requires java.logging; 
      exports java.sql; 
      exports javax.sql; 
      ... 
    }