Monday, July 13, 2015

JDK 9 Module System Jigsaw 2 from N - JEP 200

This post is about the JEP 200, I will be bringing to you an explanation about what is JEP  200 and what is the importance of this JEP 200 for the java community and the java platform.

JEP 200 or the Modular JDK,is a Java Enhancement Proposal, that define a modular structure for the JDK, Make minimal assumptions about the module system that will be used to implement the structure. This is the first JEP that we have to start the process of modularity of the JVM and the Java platform, with this JEP we have the goal to divide the JDK in a set of modules, that can be used in compile time, build time, install time and run-time.  


The Module Graph


The below image represent the module graph of the Java Platform, this image has a transitive reduction of all the modules relationship, this with the purpose to make easy to understand and see the relationship between modules. 



From the previous image you can define that:



  • Orange is for standard modules.
  • Blue is for non standard modules.
  • When a module re-export the context of another module, the edge is darker otherwise the edge is lighter. 
  • Base module does not depend of any other module. 
  • There are aggregators modules like the java.se, and the aggregator module is a module that re-export the content of other modules and does not contains any content. 
  • The Module Graph is considering a new kind of API and will be maintained and evolved by the Java standardization process.  


No Standard Module is implemented, and is not a goal of this JEP to implement it. 


As we know the goal of this JEP is to make the JDK ready for modularization and the Java platform, and this means that any error, or previous part of the JDK that was not coded or build with the modularity concept in mind has to be fixed, as example we have: the API changes to the locale data, that will be make in a separate module for each locale.

The modularization process will produce a new way to test, compile, deploy and run, because each part of the JVM will be affected and this means that is not a simple process. 

Moreover, as we know we do not have any implementation of the module system at this point, and someone can ask, how the developers of Oracle will start the process to moduralize the JDK? The answers is simple, they use a simple XML document to define the module structure of the modules. See the below xml for an example of how the modules will be made coded for modularization: 

  java.security.sasl
  java.base
  java.logging
  
    javax.security.sasl
  

  
  
    com.sun.security.sasl.util
    java.security.jgss
  

Important definitions from the previous XML:  


Export: define what are the packages that you can be exported, moreover you can define what are the modules that can see the public content of your module, for example the java.security.sasl module can only export the com.sun.security.sasl.util package to the java.security.jgss module
Depend: mark the dependencies that a module has to another module, for example every module depends upon java.base module.
Re-Exports: let you export the public content of an existing module is used with a depended module. 

As you can see right now we are able to export, and mark a depended module, but this is only a xml that will be replaced with a compiler and run-time support, so this means that in the final definition of the module system we will have more options, as options to mark what are the services that a module has, or the ability make OAT (Ahead of time compilation). 

Conclusions:

First we saw that the JEP 200 define the start of the modular JDK, and is related to the structure of the new JDK modules, Second, this define some important concepts like export, depend, re-exports, Third, all this will be used by the module implementation, and we saw that the new modular JDK will have a module graph that will be used like an API, and it will be standardized, finally if you join all of these things you can see the importance of this JEP from the standardization to the module structure definition and for what this JEP is very important.  

For more information, JEP 200, openjdk.java.net.

I hope that you like this post, In the near future I will be making a post related to JEP 220: Modular Run-Time Images, please let your comments and enjoy!!!

Previous Post: 

JDK 9 Module System Jigsaw 1 from N

The Images presented in this post are property of his respective owners.

No comments:

Post a Comment

Revolutionizing Stream Pipelines with Custom Intermediate Operations JEP 473: Stream Gatherers (Second Preview)

Introduction In the ever-evolving scene of Java improvement, the Stream API has been a foundation of utilitarian programming paradigms sin...