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.

JDK 9 Module System Jigsaw 1 from N

The goal of this first post is to give the places in which you can see information related to JDK9 module System aka Jigsaw, and to see some of the problems that java has today without using a module system.

Java as platform does not have a module system defined and this is causing a lot of problems as jar, and classpath hells, version problems, from 7to 8 years ago Java is trying to implement a module system that can fix the previous problems from the JSR 277, 294 until nowadays, we do not have any solution to this problems, but for Java 9, Oracle is implementing the Jigsaw module system into the runtime of the Oracle Java implementation.

First of all, what are the problems that we have:

Jar hell, is when you have to version of the same jar file in your runtime and your application is using the wrong version for example you have jar A.1, and A.2 in your classpath, and your application use A.2, the classloading mechanism only see the first jar file that the runtime loads, and ends loading A.1, this cause that your application will be running with the wrong jar file.

Classpath hell, the classpath hell, are all the problems that you have with the classpath as the no standard way to have your jar files, no standard way to define the place in which you want to put your classpath, this can produce indirectly the jar file hell, because you can define a jar file in any place of your classpath without know when a secondary jar file is located.

Project Jigsaw comes with a solution, and with a Standard module system file format to give a solution for the Jar and classpath hells.

Websites and internet pages in which you can see Jigsaw information: 

First, you can find information in the project page: http://openjdk.java.net/projects/jigsaw/
See the JDK9 project source code: http://hg.openjdk.java.net/jdk9

JEPs page information for JDK 9 module system:

1. JEP 200: The Modular JDK
2. JEP 201: Modular Source Code
3. JEP 220: Modular Run-Time Images

JSR 376 in OpenJDK: http://openjdk.java.net/projects/jigsaw/spec/
JSR 376 in JCP website: https://jcp.org/en/jsr/detail?id=376
System Requirement for Java Platform Module System.

Conclusions:

As we saw in this post, we touched commons problems that Java has today as the classpath and jar file hells, and finally some links were provided with additional information. I hope that you find this post interesting, and please give your feedback, and comments, finally do not forget the next post that I will be done related to JDK9 module system in which I will cover the JEP 200.

Netbeans IDE JDK9 branch build

Today I have a good news for all the Netbeans user, and the news is that the branch build for JDK9 started.

In this build you can test some experimental options for Jigsaw module system this build is in early stage and it is made available to test and send feedback related to Netbeans. .

For download the Netbeans JDK9 branch click the following link.

If you want more information see the wiki page for JDK9Support

Enjoy!!!

CDI 2.0 Early Draft

CDI 2.0 is posting an Early Draft that you can read and make feedback.

The topics that were covered in this draft were:

CDI in Java Standard Edition, that open a lot of possibilities not only for desktop application.
Asynchronous Events, that is one of the most waited changes for CDI 2.0.

If you want to read more and participate into the community that is making CDI 2.0, follow the next link: https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html

Enjoy!!!

Oracle Batch Process for JDBC

Today will talk about the Oracle Batch process for JDBC.

When we talk about batch process, we talk about the way in which you can send transaction in a batch when you are making java database applications, this means that instead of send one transaction at the time you will be sending a batch of 10, 30 or more transactions or statements. From the Oracle documentation we can see that the best batch size is between 10 and 30 transactions or statements by batch.

In JDBC one can define an statement a delete, insert, or update SQL statement.

The Oracle JDBC driver has two implementations for batching SQL statements, the first one is the Standard JDBC batching mechanism and the second one is the proprietary Oracle implementation.

As you saw the first is the standard JDBC way and is used in all the JDBC classes as Statement, PreparedStatement and CallebleStatement. The java.sql.Statement work in a different way than the PreparedStatement and CallebleStatment, because you can add different kind of SQL statement to the java.sql.Statement batch, but for the PreparedStatement and CallebleStatement you only can add the same SQL statement to the batch, before we go to the example is good to remember that all batch process need to be in a transaction, so before start a batch process please set the AutoCommit flag of the JDBC connection to false.

For Example:

In a java.sql.Statement you can have a batch composed of insert and update statements or any statements that you want to add to the batch:

String sql = "insert into demoTable (demoName, demoAge) values ('Demo Name', 20)";

String sql1 = "updatre demoTable set demoName = 'Demo Update' where demoAge = 20";


stmt.addBatch(sql);

stmt.addBatch(sql1);


int results[] = stmt.executeBatch();

But in a PreparedStatement or CallableStatement you only can have the same statement, this means the same insert or update, but not both combined, see the example below:

String sql = "insert into demoTable (demoName, demoAge) values (?, ?)";

PreparedStatemen pstmt = conn.prepareStatement(sql);

conn.setAutoCommit(false);

pstmt.setInt( 1, "Demo Name");
pstmt.setString( 2, 20 );
pstmt.addBatch();

pstmt.setInt( 1, "Demo Name1");
pstmt.setString( 2, 21 );
pstmt.addBatch();

int[] count = stmt.executeBatch();

You only can use the same statement in a PreparedStatement because in precompiled in the DBMS, and you are not able to change it, because the parameters are bind to the sql statement that is compiled into the database. 

Finally for the standard way to make batching you can see that is the more portable, easy, but is not predictable like the proprietary batching implementation that offers Oracle.

The proprietary option offer only batching for PreparedStatement and the batching cannot be done for different kind of SQL statement, one point to note here is that the proprietary batching does not have a mechanism that you can use to make PreparedStatement to depend from others PreparedStatements results.

To make batching with the proprietary option you only need to cast the PreparedStatement returned by the JDBC connection to an OraclePreparedStatement and set the executeBatch property to the size that you want for the batch:

((OraclePreparedStatement)pstmt).setExecuteBatch(30);

When you set the ExecuteBatch property this makes the oracle implementation more predictable, because the JDBC driver knows the batch size and how and when to send the statements to the database, you can set a default for this property using the Oracle JDBC connection and setting the setDefaultExecuteBatch property value.

Drawbacks that this option has are:

1. Portability, depends on Oracle driver and database.
2. The batch execution problem: think in a process in which you have two statements, each statement needs to set the setExecuteBatch property value, but each statement will behave like a separate batch, this means that we have two batch one for the first statement and one for the second statement, if the batch statement of the second statement is executed before the first statement and the second statement depends of the first statement batch, this can cause some data lost and some weird exceptions, like not foreign key present exceptions. 

For conclusions:

• First, we saw that the standard way is more portable, but is not predictable. 
• Second, The oracle proprietary way to make batching has some advantages like predictability but you do not control the statement execution, and how the information is sent and when you send this information to the database. 
• Third, I forgot to say that Oracle does not support batching optimization in the standard way for java.sql.Statement, so if you use batching here you will not see any performance improvements, so this means that the Standard way and the Oracle way just only support batching for PreparedStatements. 
• Finally, I presented the ways for make batching with the Oracle driver, so is your opportunity to decide what is the best and optimal way to make batching when you are connecting to the Oracle database, this does not depend of a blog entry, it depends of the necessity that you have for your business, and architecture. 

If you want more information about this interesting topic please see the next link: http://docs.oracle.com/cd/E11882_01/java.112/e16548/oraperf.htm#JJDBC28752 

Thanks and let your comments.