Shulou(Shulou.com)06/02 Report--

This article introduces how to achieve Java modular system analysis, the content is very detailed, interested friends can refer to, hope to be helpful to you.

It has been a long time since the introduction of the Java modular system, and it was not finalized in JSR (JSR-376) until late 2014, and this section is likely to appear in Java 9. But there has always been no prototype that can be used. On September 11, the early build version released by OpenJDK finally included the Jigsaw project.

My colleague Paul Bakker and I discussed the Java modular system on JavaZone. The whole discussion is based on the JSR-376 requirements document and some valuable information around it. When we proposed this report at the beginning of the year, we were convinced that we could show a prototype at this meeting, but things didn't work out as expected. The situation now is that this prototype will be released after the end of our report. This also means that some of the contents of the report are a little out of date, but the main ideas are still very new.

Why use modules?

What is a module? Why do we need them again? If you want an in-depth discussion, please read "State of the module system" or take a look at our report. For those who don't know much about this area, here is an annotated version of Cliff.

We all know that Java has jar files. However, in fact, these are just compressed files containing some class (classes), and inside these jar packages are some package (packages). When you use some different jar packages to run applications (more complex programs are also applicable), you need to put them in the specified classpath. And pray silently. Because there are no effective tools to help you know whether you have put all the jar packages needed by the application into the classpath. Or it's possible that you inadvertently put the same class files (in different jar packages) in the classpath. Classpath disasters (similar to DLL disasters) are real. This can lead to bad conditions at run time. At the same time, we don't know which classes are included in the jar at run time. From a JRE point of view, all you know is a bunch of class files. In fact, jar packages are interdependent, but this dependency cannot be recorded in a data file yet. Ideally, you can hide the concrete implementation of the class files in the jar package and just provide some common API. Modular system is proposed in Java to solve these problems:

The module becomes the first consideration, it can pack the implementation details and expose only the required interfaces.

The modules accurately describe the interfaces they can provide, as well as their needs (dependencies). As a result, we can clarify and deal with dependencies in the process of development.

The module system greatly improves the maintainability, reliability and security of large-scale systems. At least JDK itself lacks such a system. Through such a module system, the module diagram can be built automatically. This diagram includes only the modules that your application needs to run.

Install JDK9 preview

If you want to try to write the sample code yourself, you need to install an earlier build of JDK9 that contains Jigsaw prototypes. On OSX, you need to extract the document, and then move the extracted directory to Library/Java/JavaVirtualMachines/. Then you need to set the environment variable and point the JAVA_HOME environment variable to the directory of JDK9. I used a very useful setjdk script that allows you to switch commands for Java installation in the command window. You probably don't want to use this early build as your Java installation. You can confirm that the installation is complete through java-version. The output is shown below:

one

two

three

Java version "1.9.0-ea"

Java (TM) SE Runtime Environment (build 1.9.0-ea-jigsaw-nightly-h4337-20150908-b80)

Java HotSpot (TM) 64-Bit Server VM (build 1.9.0-ea-jigsaw-nightly-h4337-20150908-b80, mixed mode)

As long as the output contains Jigsaw, you can continue. The sample code at the end of the article can be downloaded from https://github.com/sandermak/jigsaw-firstlook.

A simple example.

You can still use JDK9 in "traditional" ways such as classes, jar packages, and classpath. But obviously we want to adopt a modular approach. So we will create a project with two modules: module one uses the code from module two.

The first thing to do is to build our project and distinguish the two modules well. Then, the module needs to add metadata in the form of a module-info.java file. Our example is built as follows:

one

two

three

four

five

six

seven

Src

Module1

Module-info.java

ComtestTestClassModule1.java

Module2

Module-info.java

CommoretestTestClassModule2.java

Next, we will introduce the top layer of the package (package) layer (module1, module2), which you have built before. In these "module directories", you can see the module-info.java file in the root directory. Also note that both classes are in the display named package.

Take a look at the code of TestClassModule1:

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

Package com.test

Import com.moretest.TestClassModule2

Public class TestClassModule1 {

Public static void main (String [] args) {

System.out.println ("Hi from" + TestClassModule2.msg ())

}

}

It looks ordinary, right? The module is not involved here, but the TestClassModule2 is imported, and the main function will then call the msg () method.

one

two

three

four

five

six

seven

eight

nine

ten

eleven

Package com.moretest

Public class TestClassModule2 {

Public static String msg () {

Return "from module 2!"

}

}

So far, module-info.java is empty.

Compile the Java module

Now proceed to the next step: compile our module and associate the source file. To do this, we will introduce a new javac compilation parameter:

one

Javac-modulesourcepath src-d mods $(find src-name'* .java')

When using the above statement, we assume that the command program is already in the parent directory of the src folder. The-modulesourcepath parameter takes javac from traditional compilation mode to module mode. The-d tag indicates the output directory of the compiled module. Javac will output these modules as unpackaged files. If we want to use these modules in jars form after that, we need a separate step.

So what happens when we call the javac command line above? An error occurred in the compilation!

one

two

Src/module1/module-info.java:1: error: expected 'module'

Src/module2/module-info.java:1: error: expected 'module'

An empty module-info.java file caused this error. Therefore, some new keywords will be introduced into these files, which are very important parts of the module. The scope of these keywords is the definition part of module-info.java. You can also use variables of type module in the source file of java.

We used the least description information and updated the module description file:

one

Module module1 {}

Then there is module 2:

one

Module module2 {}

Now, the module has been accurately named, but no other data has been included. Compiling again will cause a new error:

one

Src/module1/com/test/TestClassModule1.java:3: error: TestClassModule2 is not visible because package com.moretest is not visible

Here comes the package! By default, classes or other types within the module are hidden from the outside. This is why javac does not allow TestClassModule2, even if it is a public class. If we still use compilation based on the traditional classpath, everything will work fine. Of course, we can also solve this problem by explicitly exposing TestClassModule2 to the outside world. The next changes are necessary for module-info.java in module2:

one

two

three

four

five

Module module2 {

Exports com.moretest

}

That's not enough. If you compile the modified version, you will get the same error. That's because, although module2 has now exposed the required packages (including all public types), module1 has not yet declared its dependency on module2. We can also change module1's module-info.java file to solve this problem:

one

two

three

four

five

Module module1 {

Requires module2

}

Dependencies on other modules can be expressed by specifying names, although they are exported in the form of packages in these modules. There is still a lot to say in this regard, but I do not want to cover it in the preliminary introduction. After this step, we successfully compiled the multi-module project using Jigsaw * *. If you open the / mods directory, you can see that the compiled things are neatly divided into two directories. It worked!

Run modular code

It's just not much fun to compile. We want the application to be up and running. Fortunately, JRE and JDK already support module associations in this prototype. This application can be launched by specifying the module path instead of the classpath:

one

Java-mp mods-m module1/com.test.TestClassModule1

We point the module path to the mods folder, which is where the output module is written when javac compiles. And-m indicates the module to start initially, through which other modules can be started step by step. We also added the name of the startup class that needs to be called during initialization, and the running result is as follows:

one

Hi from from module 2!

On how to achieve the Java modular system analysis is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.