Java9 new feature Module modular programming method

The Java language introduced an important concept in its version 9 - module. If you are familiar with the modular management of JavaScript code, you should feel familiar when you see the modular management of Java 9.

1. What is Java module?

Module introduces a higher level of Java code grouping, similar to packages in Java. Each such group (module) contains many sub-packages. Declare the folder and its subfolders as a module by adding the file module-info.java to the root of a module's source code file package. The syntax of the file is as follows:

 module xxx.yyy{
  ....
 }

where xxx.yyy is the name declared by the module module, not the package name.

2. Module export package

The file module-info.java can specify which packages under the module are visible and accessible to the outside world. This function is implemented through a new keyword exports.

 module xxx.yyy{
  exports com.zimug.java9;
 }

com.zimug.java9 represents a package.

It should be noted that even if the classes in a given package are public, if their package is not explicitly exported through "exports", they are not visible outside the module ( This is true both at compile time and at run time).

3. Module import package

If another module wants to use the classes in the exported package, you can use the requires keyword in its module -info.java file to import (read) the package package of the target module.

module def.stu{ requires xxx.yyy;}

4. The significance of Java module

The author believes that the introduction of the module modular management system in Java 9 is mainly due to security considerations. More than 90% of vulnerabilities in Java code are caused by reflection and insufficient access control granularity. The modular system of Java 9 can solve this problem. Java 9 modularity provides a higher level of visibility and accessibility control of Java code.

As an example, when we mark a class as private, it means that it is an inner class. There are only two modifiers for external classes: public and default. This also means a problem. We originally planned to use some public classes within the scope defined by the jar package, but the result is that any project that introduces this jar can use all the public class codes in this jar.

That is to say, our original intention was to provide public access within a limited scope, but the result was unlimited public access. After the introduction of Java 9 modularization, limited range of code public access rights can be achieved, and the code publicity is divided into: limited range of public access outside the moduleandinside the module Public access.

5. Example

In this example, I will create two modules "common.widget" and "data.widget" and place them in a single folder "modules-examples /src". The file "module-info.java" will be placed under the root folder of each module.
The file and directory format is as follows:

D:\modules-example>tree /F /A
\---src
    +---common.widget
    |   |   module-info.java
    |   |   
    |   +---com
    |   |   \---zimug
    |   |           RendererSupport.java
    |   |           
    |   \---org
    |       \---jwidgets
    |               SimpleRenderer.java
    |               
    \---data.widget
        |   module-info.java
        |   
        \---com
            \---example
                    Component.java

The first module

This code file directory:

modules-example/src/common.widget/ org/jwidgets/SimpleRenderer.java.

This package is not exported in the following text.

package org.jwidgets;
public class SimpleRenderer {
  public void renderAsString(Object object) {
      System.out.println(object);
  }
}

This code file directory:

modules-example/src/common.widget/com/zimug/RendererSupport.java.

This package will be exported later.

package com.zimug;
import org.jwidgets.SimpleRenderer;
public class RendererSupport {
  public void render(Object object) {
      new SimpleRenderer().renderAsString(object);
  }
}

Module export, this code file directory: modules-example/src/common.widget/module-info.java. Only the com.zimug package is exported, and the org.jwidgets package is not exported. The exported module name is common.widget

module common.widget{
  exports com.zimug;
}

The second module

module imports common.widget, this code file directory: modules- example/src/data.widget/module-info.java

module data.widget {
  requires common.widget;
}

Use package:com.zimug in the imported module common.widget. The path of this code file:

##modules-example/src/data.widget/com/example/Component.java

package com.example;
import com.zimug.RendererSupport;
public class Component {
  public static void main(String[] args) {
      RendererSupport support = new RendererSupport();
      support.render("Test Object");
  }
}

Compile and execute normally, the results are as follows:

Test Object

Attempting to use package code that has not been exported

Because package "org.jwidgets" has not been exported by the "common.widget" module, another module "data.widget" cannot use the package package Class

SimpleRenderer. Let’s make a counterexample to see what happens:

package com.example;
import org.jwidgets.SimpleRenderer;
public class Component {
  public static void main(String[] args) {
    SimpleRenderer simpleRenderer = new SimpleRenderer(); 
    simpleRenderer.renderAsString("Test Object");
  }
}

The compilation error message is as follows:

D:\modules-example\src\data.widget\com\example\Component.java:3: error: package org.jwidgets is not visible
import org.jwidgets.SimpleRenderer;         ^
  (package org.jwidgets is declared in module common.widget, which does not export it)
1 error

Even if it is declared as public, but the class under the unexported package cannot be access.

The above is the detailed content of Java9 new feature Module modular programming method. For more information, please follow other related articles on the PHP Chinese website!