This is a Series of Articles on the Latest Features of Java 9. Starting with Why and How of the Java 9 Modules Feature and Moving Forward.

Author: Shazin Sadakath

This is a continuation of Java 9 : Future 1 Post

Modules enforce Strong Encapsulation as we discussed in the previous post. Now a Package is not public by default to all other modules unless it is explicitly exported in the Module Descriptor.

Can Class D from Module A access Class F from Module B?

With the Module Descriptors mentioned below, yes it is possible as Module A has mentioned as it requires Module B and Module B has exports package Z.

Strong Encapsulation

But why Modules again?

Remember packages starting with sun.* or com.* that were available in rt.jar (JVM Runtime) which were only specific for certain JVM Vendor Implementations and not all. Java programmers have been constantly warned not to use these packages as they will break Platform Independence. But up until Java 9 Modules there was no way to completely stop developers from using those packages.


Enter java.base Module

Following is the Module Descriptor for java.base module. With this as you can see only certain packages are exported and com.*/sun.* packages are only available within the module.

module java.base { 
      exports java.lang;  
      exports java.util; 


Every Module in Java 9 implicitly will have require to java.base. Just like every class in Java will automatically import java.lang.*. 

So what does this means?

This means that now there can be a Java Application which is 100% modular with all Jar files being modules. Which means we can't use classpath in those scenarios. 

Enter Module Path

Plus a Java Application can be an hybrid of Modular as well as Backward Compatible Application in those cases there will be both a Module Path and Class Path.


To be continued..

Tags: Java9
Views: 896
Register for more exciting articles


Please login or register to post a comment.

There are currently no comments.