引言

近期在 Baeldung 看到了一篇有關(guān)Java9模塊化入門(mén)介紹的文章，整體翻譯加理解下來(lái)發(fā)現(xiàn)確實(shí)不錯(cuò)，個(gè)人認(rèn)為美中不足的是項(xiàng)目構(gòu)建過(guò)于簡(jiǎn)單和偏手動(dòng)，個(gè)人建議找一些簡(jiǎn)單的Java9以及之上的開(kāi)源項(xiàng)目結(jié)合參考使用更佳。

原文

A Guide to Java 9 Modularity | Baeldung

1. Overview

Java 9 introduces a new level of abstraction above packages, formally known as the Java Platform Module System (JPMS), or “Modules” for short.

Java 9 在包上面引入了新的層次，正式的名稱(chēng)叫做 Java 平臺(tái)模塊系統(tǒng)（JPMS），或者更簡(jiǎn)單稱(chēng)之為“模塊”。

In this tutorial, we'll go through the new system and discuss its various aspects.

本教程介紹新系統(tǒng)的各個(gè)方面。

We'll also build a simple project to demonstrate all concepts we'll be learning in this guide.

本部分構(gòu)建了一個(gè)簡(jiǎn)單項(xiàng)目介紹這些概念。

2. What's a Module?

First of all, we need to understand what a module is before we can understand how to use them.

首先，先理解什么是模塊才能理解什么是模塊化。

A Module is a group of closely related packages and resources along with a new module descriptor file.

一個(gè)模塊是一組密切相關(guān)的包和資源，以及一個(gè)新的模塊描述符文件。 怎么理解這個(gè)概念呢？實(shí)際上抽象理解為在 package 的基礎(chǔ)上再套了一層包即可。

In other words, it's a “package of Java Packages” abstraction that allows us to make our code even more reusable.

抓住“package of Java Packages”這個(gè)概念，目的是讓不同模塊之間代碼不產(chǎn)生干擾，并且具備更強(qiáng)的可維護(hù)性和安全性。

2.1. Packages

The packages inside a module are identical to the Java packages we've been using since the inception of Java.

模塊的包和Java原始包的概念是一樣的。

When we create a module,?we organize the code internally in packages just like we previously did with any other project.

創(chuàng)建一個(gè)新模塊，內(nèi)部再使用包組織結(jié)構(gòu)代碼，這意味著代碼不需要任何改變。

Aside from organizing our code, packages are used to determine what code is publicly accessible outside of the module.

而模塊的加入顯然就是為了確定包還被用來(lái)確定哪些代碼可以在模塊之外公開(kāi)訪問(wèn)。

2.2. Resources

Each module is responsible for its resources, like media or configuration files.

每個(gè)模塊負(fù)責(zé)各自的資源，比如媒體和配置文件。

Previously we'd put all resources into the root level of our project and manually manage which resources belonged to different parts of the application.

模塊化出現(xiàn)之前的代碼，所有的資源基本都在 根目錄管理，需要手動(dòng)管理劃分資源的歸屬。

With modules, we can ship required images and XML files with the module that needs it, making our projects much easier to manage.

通過(guò)模塊可以對(duì)于資源進(jìn)行進(jìn)一步的劃分，使得項(xiàng)目更容易管理。

2.3. Module Descriptor

When we create a module, we include a descriptor file that defines several aspects of our new module:

當(dāng)構(gòu)建一個(gè)模塊的時(shí)候，我們創(chuàng)建描述符文件，并且定義模塊的相關(guān)內(nèi)容。

• Name?– the name of our module 模塊名稱(chēng)

• Dependencies?– a list?of other modules that this module depends on 模塊的描述信息

• Public Packages?– a list of all packages we want accessible from outside the module 允許對(duì)外訪問(wèn)的模塊

• Services Offered?– we can provide service implementations that can be consumed by other modules 可以被其他模塊使用的服務(wù)實(shí)現(xiàn)

• Services Consumed?– allows the current module to be a consumer of a service 允許當(dāng)前模塊成為一個(gè)服務(wù)的使用者

• Reflection Permissions?– explicitly allows other classes to use reflection to access the private members of a package 明確地允許其他類(lèi)使用反射來(lái)訪問(wèn)包的私有成員。

The module naming rules are similar to how we name packages (dots are allowed, dashes are not). It's very common to do either project-style (my.module) or Reverse-DNS (com.baeldung.mymodule) style names.

模塊的命名規(guī)則類(lèi)似于我們命名包的方式（允許使用點(diǎn)，不允許使用破折號(hào)）。 比如：

• 項(xiàng)目風(fēng)格（my.module）

• 反向DNS（_com.baeldung.ymodule_）

下文的案例將會(huì)一直使用項(xiàng)目風(fēng)格介紹。

We need to list all packages we want to be public because by default all packages are module private.

我們需要列出所有我們想要公開(kāi)的軟件包，因?yàn)樵谀J(rèn)情況下，所有軟件包都是模塊私有的。

The same is true for reflection. By default, we cannot use reflection on classes we import from another module.

反射在默認(rèn)情況下也是不能對(duì)外使用的。

2.4. Module Types

There are four types of modules in the new module system:

在新的模塊系統(tǒng)中，有四種類(lèi)型的模塊：

• System Modules?– These are the modules listed when we run the?list-modules?command above. They include the Java SE and JDK modules.

系統(tǒng)模塊：通常是在java --list-modules 這樣的命令執(zhí)行結(jié)果中，它們包括Java SE和JDK模塊。

• Application Modules?– These modules are what we usually want to build when we decide to use Modules. They are named and defined in the compiled?module-info.class?file included in the assembled JAR.

應(yīng)用模塊：決定使用模塊的時(shí)候，這些模塊通常是想要構(gòu)建的，這部分命名會(huì)歸屬到一個(gè) module-info.class 這樣的文件當(dāng)中，當(dāng)然也包含在具體的jar當(dāng)中。

• Automatic Modules?– We can include unofficial modules by adding existing JAR files to the module path. The name of the module will be derived from the name of the JAR. Automatic modules will have full read access to every other module loaded by the path.

自動(dòng)化模塊：以通過(guò)在模塊路徑中添加現(xiàn)有的JAR文件來(lái)包括非官方模塊。自動(dòng)模塊擁有路徑加載的每個(gè)模塊的完整讀取權(quán)限。

• Unnamed Module?– When a class or JAR is loaded onto the classpath, but not the module path, it's automatically added to the unnamed module. It's a catch-all module to maintain backward compatibility with previously-written Java code.

未命名模塊：當(dāng)一個(gè)類(lèi)或JAR被加載到classpath上，而不是模塊路徑上，它就會(huì)被自動(dòng)添加到未命名模塊中。

如果從一個(gè)不具備模塊化的Java項(xiàng)目遷移到具備模塊化的Java項(xiàng)目，為了保持向前兼容，會(huì)將所有的包歸屬于未命名模塊。

2.5. Distribution

Modules can be distributed one of two ways: as a JAR file or as an “exploded” compiled project. This, of course, is the same as any other Java project so it should come as no surprise.

模塊同可以通過(guò)jar形式發(fā)布，或者作為編譯項(xiàng)目發(fā)布，發(fā)布方式和其他Java項(xiàng)目一樣。

We can create multi-module projects comprised of a “main application” and several library modules.

我們可以創(chuàng)建”一個(gè)主程序應(yīng)用“和多個(gè)庫(kù)模塊形成的多模塊項(xiàng)目。

和Maven的多Moudule概念類(lèi)似，只不過(guò)是語(yǔ)言本身開(kāi)始支持這種封包方式。

We have to be careful though because we can only have one module per JAR file.

但我們必須小心，因?yàn)槊總€(gè)JAR文件只能有一個(gè)模塊。

When we set up our build file, we need to make sure to bundle each module in our project as a separate jar.

在構(gòu)建各個(gè)模塊確保項(xiàng)目每個(gè)模塊都可以捆綁為單獨(dú)的jar包。

3. Default Modules

When we install Java 9, we can see that the JDK now has a new structure.

安裝JDK9之后可以看到現(xiàn)在有一個(gè)新結(jié)構(gòu)。

They have taken all the original packages and moved them into the new module system.

原本零散的分包方式現(xiàn)在被搬運(yùn)到新的模塊系統(tǒng)當(dāng)中。

We can see what these modules are by typing into the command line:

我們可以通過(guò)下面的命令查看JDK的原始模塊（JDK17為例）

java?--list-modules
$?java?--list-modules
java.base@17.0.7
java.compiler@17.0.7
java.datatransfer@17.0.7
java.desktop@17.0.7
java.instrument@17.0.7
java.logging@17.0.7
java.management@17.0.7
java.management.rmi@17.0.7
java.naming@17.0.7
java.net.http@17.0.7
java.prefs@17.0.7
java.rmi@17.0.7
java.scripting@17.0.7
java.se@17.0.7
java.security.jgss@17.0.7
java.security.sasl@17.0.7
java.smartcardio@17.0.7
java.sql@17.0.7
java.sql.rowset@17.0.7
java.transaction.xa@17.0.7
java.xml@17.0.7
java.xml.crypto@17.0.7
jdk.accessibility@17.0.7
jdk.attach@17.0.7
jdk.charsets@17.0.7
jdk.compiler@17.0.7
jdk.crypto.cryptoki@17.0.7
jdk.crypto.ec@17.0.7
jdk.crypto.mscapi@17.0.7
jdk.dynalink@17.0.7
jdk.editpad@17.0.7
jdk.hotspot.agent@17.0.7
jdk.httpserver@17.0.7
jdk.incubator.foreign@17.0.7
jdk.incubator.vector@17.0.7
jdk.internal.ed@17.0.7
jdk.internal.jvmstat@17.0.7
jdk.internal.le@17.0.7


These modules are split into four major groups:?java, javafx, jdk,?and?Oracle.

java?modules are the implementation classes for the core SE Language Specification.

javafx?modules are the FX UI libraries.

Anything needed by the JDK itself is kept in the?jdk?modules.

And finally,?anything that is Oracle-specific is in the?oracle?modules.

主要模塊組成分為 java（包含Java SE 的語(yǔ)言規(guī)范實(shí)現(xiàn)類(lèi)）、javafx（FX用戶(hù)界面庫(kù)）、jdk（JDK本身需要的任何東西） 和 Oracle（任何與Oracle有關(guān)的東西）

4. Module Declarations【Important】

To set up a module, we need to put a special file at the root of our packages named?module-info.java.

定義模塊化需要在root根目錄新建 module-info.java 文件。在一個(gè)Maven項(xiàng)目當(dāng)中，類(lèi)似下面的組織結(jié)構(gòu)：

This file is known as the module descriptor and contains all of the data needed to build and use our new module.

這個(gè)文件被稱(chēng)為模塊描述符，包含了構(gòu)建和使用我們的新模塊所需的所有數(shù)據(jù)。

We construct the module with a declaration whose body is either empty or made up of module directives:

module?myModuleName?{
????//?all?directives?are?optional
}


We start the module declaration with the?module?keyword, and we follow that with the name of the module.

我們使用 module 關(guān)鍵字進(jìn)行聲明，然后用模塊的名稱(chēng)跟在關(guān)鍵字后面。

The module will work with this declaration, but we'll commonly need more information.

該模塊將在這個(gè)聲明下工作，但我們通常需要更多的信息。

That is where the module directives come in.

下面就是模塊指令上場(chǎng)的時(shí)候了。

4.1. Requires

Our first directive is?requires. This module directive allows us to declare module dependencies:

第一個(gè)指令為 requires，該模塊指令允許聲明依賴(lài)性。

module?my.module?{
????requires?module.name;
}


Now,?my.module?has?both a runtime and a compile-time dependency?on?module.name.

上面的語(yǔ)法說(shuō)明 my.module 對(duì)于 module.name 運(yùn)行和編譯的時(shí)候都具備了依賴(lài)性。

And all public types exported from a dependency are accessible by our module when we use this directive.

當(dāng)使用這個(gè)命令的時(shí)候，所有的依賴(lài)關(guān)系關(guān)聯(lián)的public類(lèi)型都可以被模塊訪問(wèn)。

4.2. Requires Static

Sometimes we write code that references another module, but that users of our library will never want to use.

有的時(shí)候會(huì)出現(xiàn)代碼引用了另一個(gè)模塊但是永遠(yuǎn)沒(méi)有使用。

For instance, we might write a utility function that pretty-prints our internal state when another logging module is present. But, not every consumer of our library will want this functionality, and they don't want to include an extra logging library.

例如，我們可能會(huì)需要另一個(gè)類(lèi)似日志的模塊在需要的時(shí)候幫忙打印內(nèi)容，當(dāng)然并不是所有的模塊都需要用到這樣的功能。

By using the?requires static?directive, we create a compile-time-only dependency:

通過(guò)?requires static 這樣的語(yǔ)法，我們創(chuàng)建一個(gè)僅僅在編譯的時(shí)候使用的依賴(lài)。

module?my.module?{
????requires?static?module.name;
}


4.3. Requires Transitive

We commonly work with libraries to make our lives easier.

But, we need to make sure that any module that brings in our code will also bring in these extra ‘transitive' dependencies or they won't work.

有時(shí)候我們會(huì)有類(lèi)似圖書(shū)館這樣“合作關(guān)系”的依賴(lài)，因此我們也需要確保任何引入我們代碼的模塊也會(huì)引入這些額外的 "及物 "依賴(lài)關(guān)系，否則它們將無(wú)法正常工作。

這里的及物含義：及物動(dòng)詞必須有一個(gè)對(duì)象，否則意思上不完整。

Luckily, we can use the?requires transitive?directive to force any downstream consumers also to read our required dependencies:

我們可以使用 requires transitive 指令來(lái)強(qiáng)制任何下游消費(fèi)者也讀取我們所需的依賴(lài)。

module?my.module?{
????requires?transitive?module.name;
}


Now, when a developer?requires my.module, they won't also have also to say?requires module.name?for our module to still work.

現(xiàn)在當(dāng)開(kāi)發(fā)者引入?my.module模塊時(shí)，無(wú)需再顯示聲明引入module.name模塊。

4.4. Exports

By default, a module doesn't expose any of its API to other modules.?This?strong encapsulation?was one of the key motivators for creating the module system in the first place.

Our code is significantly more secure, but now we need to explicitly open our API up to the world if we want it to be usable.

We use the?exports?directive to expose all public members of the named package:

module?my.module?{
????exports?com.my.package.name;
}


Now, when someone does?requires my.module, they will have access to the public types in our?com.my.package.name?package, but not any other package.

4.5. Exports … To

We can use?exports…to?to open up our public classes to the world.

我們可以使用 exports...to 將我們的公共類(lèi)向世界開(kāi)放。

But, what if we don't want the entire world to access our API?

但是如果不想公開(kāi)API應(yīng)該怎么辦？

We can restrict which modules have access to our APIs using the?exports…to?directive.

我們可以使用exports...tod的指令限制模塊訪問(wèn)API。

Similar to the?exports?directive, we declare a package as exported. But, we also list which modules we are allowing to import this package as a?requires. Let's see what this looks like:

與 exports 指令類(lèi)似，我們將一個(gè)包聲明為 exported。但是，我們也列出了我們?cè)试S哪些模塊導(dǎo)入這個(gè)包作為 requires 。

相關(guān)的操作語(yǔ)法如下：

module?my.module?{
????export?com.my.package.name?to?com.specific.package;
}


4.6. Uses

A?service?is an implementation of a specific interface or abstract class that can be?consumed?by other classes.

服務(wù)是一個(gè)特定接口或抽象類(lèi)的實(shí)現(xiàn)，可以被其他類(lèi)所使用。

We designate the services our module consumes with the?uses?directive.

我們使用 uses 指令指定模塊使用的服務(wù)。

Note that?the class name we?use?is either the interface or abstract class of the service, not the implementation class:

注意，指定的類(lèi)名稱(chēng)應(yīng)該是 接口 ?而不是具體的實(shí)現(xiàn)類(lèi)。

module?my.module?{
????uses?class.name;
}


We should note here that there's a difference between a?requires?directive and the?uses?directive.

在這里我們應(yīng)該注意到，_requires_ 指令和 uses 指令之間是有區(qū)別的。

We might?require?a module that provides a service we want to consume, but that service implements an interface from one of its transitive dependencies.

比如我們可能使用requires指令引入了提供服務(wù)的模塊，但服務(wù)實(shí)現(xiàn)的接口來(lái)自某個(gè)傳遞依賴(lài)。

Instead of forcing our module to require?all?transitive dependencies just in case, we use the?uses?directive to add the required interface to the module path.

這時(shí)無(wú)需強(qiáng)制我們模塊通過(guò)requires引入所有傳遞依賴(lài)，可以使用uses指令引入接口至模塊路徑。

4.7. Provides … With

A module can also be a?service provider?that other modules can consume.

一個(gè)模塊可以是服務(wù)的提供者給其他模塊進(jìn)行使用。

The first part of the directive is the?provides?keyword. Here is where we put the interface or abstract class name.

指令的第一部分是 provides 關(guān)鍵字。這部分要把接口和抽象類(lèi)的名字放這里。

Next, we have the?with?directive where we provide the implementation class name that either?implements?the interface or?extends?the abstract class.

接下來(lái)，我們有 with 指令，在這里我們提供實(shí)現(xiàn)類(lèi)的名稱(chēng)，該類(lèi)要么是 implements? 接口，要么是 extends 抽象類(lèi)。

Here's what it looks like put together:

上面兩個(gè)關(guān)鍵字放在一起的結(jié)果如下：

module?my.module?{
????provides?MyInterface?with?MyInterfaceImpl;
}


4.8. Open

We mentioned earlier that encapsulation was a driving motivator for the design of this module system.

前面的模塊化概念實(shí)際上就是進(jìn)一步提高Java語(yǔ)言的封裝性。

Before Java 9, it was possible to use reflection to examine every type and member in a package, even the?private?ones. Nothing was truly encapsulated, which can open up all kinds of problems for developers of the libraries.

在Java9之前，可以利用反射強(qiáng)制訪問(wèn)每個(gè)類(lèi)型和成員，甚至可以直接讀取private變量，這實(shí)際屬于完全破壞封裝性的行為，只不過(guò)這些規(guī)則全部靠開(kāi)發(fā)人員遵守而已。

Because Java 9 enforces?_strong encapsulation_（封閉性）,?we now have to explicitly（明確） grant permission for other modules to reflect?on our classes.

在Java9之后，這種反射濫用的行為受到明確限制，我們必須要明確授予其他模塊對(duì)于我們模塊的反射訪問(wèn)權(quán)限。

If we want to continue to allow full reflection as older versions of Java did, we can simply?open?the entire module up:

當(dāng)然如果想要省事，想繼續(xù)像舊版本的Java那樣允許完全反射，我們可以簡(jiǎn)單地_開(kāi)放整個(gè)模塊：

open?module?my.module?{
}


4.9. Opens

If we need to allow reflection of private types, but we don't want all of our code exposed,?we can use the?opens?directive to expose specific packages.

如果我們需要允許反射私有類(lèi)型，但我們不希望所有的代碼都暴露出來(lái)，**我們可以使用 opens ?指令來(lái)暴露特定的包。

But remember, this will open the package up to the entire world, so make sure that is what you want:

但是需要注意 opens 之后整個(gè)包就完全對(duì)外開(kāi)放訪問(wèn)了，使用之前需要仔細(xì)確認(rèn)這個(gè)行為是否需要。

module?my.module?{
??opens?com.my.package;
}


4.10. Opens … To

Okay, so reflection is great sometimes, but we still want as much security as we can get from?encapsulation.?We can selectively open our packages to a pre-approved list of modules, in this case, using the?opens…to?directive:

我們可以有選擇地將我們的包開(kāi)放給預(yù)先批準(zhǔn)的模塊列表，在這種情況下，使用opens...to指令

module?my.module?{
????opens?com.my.package?to?moduleOne,?moduleTwo,?etc.;
}


比如上面只開(kāi)放 to后面這部分的包對(duì)外反射使用。

5. Command Line Options

By now, support for Java 9 modules has been added to Maven and Gradle, so you won't need to do a lot of manual building of your projects. However, it's still valuable to know?how?to use the module system from the command line.

到目前為止，Maven和Gradle已經(jīng)加入了對(duì)Java 9模塊的支持，所以你不需要對(duì)你的項(xiàng)目進(jìn)行大量的手動(dòng)構(gòu)建。

當(dāng)然知道如何從命令行使用模塊系統(tǒng)對(duì)于我們學(xué)習(xí)依然很有幫助。

We'll be using the command line for our full example down below to help solidify how the entire system works in our minds.

下面會(huì)介紹完整例子中如何使用命令行，幫助理解整個(gè)公共系統(tǒng)的運(yùn)作方式。這里只需要理解工作機(jī)制即可。

• module-path?–?We use the?–module-path?option to specify the module path. This is a list of one or more directories that contain your modules.

• add-reads?–?Instead of relying on the module declaration file, we can use the command line equivalent of the?requires?directive;?–add-reads.

• add-exports?–?Command line replacement for the?exports?directive.

• add-opens?–?Replace the?open?clause in the module declaration file.

• add-modules?–?Adds the list of modules into the default set of modules

• list-modules?–?Prints a list of all modules and their version strings

• patch-module?– Add or override classes in a modules

• illegal-access=permit|warn|deny?– Either relax strong encapsulation by showing a single global warning, shows every warning, or fails with errors. The default is?permit.

• module-path - 我們使用 module-path 選項(xiàng)來(lái)指定模塊路徑。包含比如一個(gè)模塊的一個(gè)或多個(gè)目錄的列表。

• add-reads - 我們可以使用相當(dāng)于 requires 指令的命令行；_-add-reads_，而不是依賴(lài)模塊聲明文件。

• add-exports ** - ?此命令行替代 exports 指令。

• add-opens - 替換模塊聲明文件中的_open_條款。

• add-modules - 將模塊列表添加到默認(rèn)的模塊集中。

• list-modules - 打印所有模塊的列表和它們的版本字符串 。

• patch-module - 添加或覆蓋模塊中的類(lèi) 。

• illegal-access=permit|warn|deny - 通過(guò)顯示單一的全局警告來(lái)弱化強(qiáng)封裝，顯示每個(gè)警告，或者以錯(cuò)誤的方式失敗。默認(rèn)是 permit 。

6. Visibility

下面將要討論可見(jiàn)行問(wèn)題。

A lot of libraries depend on reflection to work their magic?(JUnit and Spring come to mind).

很多庫(kù)都依賴(lài)反射來(lái)發(fā)揮它們的魔力（比如 JUnit 和 Spring ）。

By default in Java 9, we will?only?have access to public classes, methods, and fields in our exported packages. Even if we use reflection to get access to non-public members and call?setAccessible(true),?we won't be able to access these members.

如果我們需要允許反射私有類(lèi)型，但我們不希望所有的代碼都暴露出來(lái)，**我們可以使用 opens 指令來(lái)暴露特定的包。

We can use the?open,?opens, and?opens…to?options to grant runtime-only access for reflection. Note,?this is runtime-only!

雖然我們可以使用 open 、_opens_ 和 ? opens...to 選項(xiàng)來(lái)處理反射只在運(yùn)行時(shí)授權(quán)訪問(wèn)。但是需要注意這些指令都是 只在運(yùn)行時(shí)間內(nèi)生效！

We won't be able to compile against private types, and we should never need to anyway.

我們將無(wú)法針對(duì)私有類(lèi)型進(jìn)行編譯，而且無(wú)論如何我們都不需要這樣做。

If we must have access to a module for reflection, and we're not the owner of that module (i.e., we can't use the?opens…to?directive), then it's possible to use the command line?–add-opens?option to allow own modules reflection access to the locked down module at runtime.

如果我們必須訪問(wèn)一個(gè)模塊進(jìn)行反射，而我們又不是該模塊的所有者（也就是說(shuō)，我們不能使用 opens...to 指令），那么可以使用命令行 -add-opens 選項(xiàng)來(lái)允許自己的模塊在運(yùn)行時(shí)反射訪問(wèn)被鎖定的模塊。

The only caveat here's that you need to have access to the command line arguments that are used to run a module for this to work.

這里唯一需要注意的是，你必須能夠訪問(wèn)用于運(yùn)行模塊的命令行參數(shù)，這樣才能發(fā)揮作用。

7. Putting It All Together

Now that we know what a module is and how to use them let's go ahead and build a simple project to demonstrate all the concepts we just learned.

上面介紹了模塊化的基礎(chǔ)語(yǔ)法，現(xiàn)在用一個(gè)簡(jiǎn)單案例把這些內(nèi)容串起來(lái)。

To keep things simple, we won't be using Maven or Gradle. Instead, we'll rely on the command line tools to build our modules.

為了保持簡(jiǎn)單，我們將不使用Maven或Gradle。相反，我們將依靠命令行工具來(lái)構(gòu)建我們的模塊。

7.1. Setting Up Our Project

First, we need to set up our project structure. We'll create several directories to organize our files.

首先，我們需要設(shè)置我們的項(xiàng)目結(jié)構(gòu)。我們將創(chuàng)建幾個(gè)目錄來(lái)組織我們的文件。

Start by creating the project folder:

通過(guò)下面的命令進(jìn)行構(gòu)建。

mkdir?module-project
cd?module-project


This is the base of our whole project, so add files in here such as Maven or Gradle build files, other source directories, and resources.

只需要一串命令構(gòu)建項(xiàng)目，沒(méi)有Maven和Gradle那樣的額外依賴(lài)。

We also put a directory to hold all our project specific modules.

我們還放了一個(gè)目錄來(lái)存放我們所有的項(xiàng)目特定模塊。

Next, we create a module directory:

下面創(chuàng)建模塊目錄。

mkdir?simple-modules


Here's what our project structure will look like:

最后整個(gè)項(xiàng)目結(jié)構(gòu)如下：

module-project |- // src if we use the default package |- // build files also go at this level |- simple-modules ?|- hello.modules ? ?|- com ? ? ?|- baeldung ? ? ? ?|- modules ? ? ? ? ?|- hello ?|- main.app ? ?|- com ? ? ?|- baeldung ? ? ? ?|- modules ? ? ? ? ?|- main

7.2. Our First Module

Now that we have the basic structure in place, let's add our first module.

現(xiàn)在我們有了基本的結(jié)構(gòu)，讓我們來(lái)添加我們的第一個(gè)模塊。

Under the?simple-modules?directory, create a new directory called?hello.modules.

在simple-modules這個(gè)目錄下面構(gòu)建一個(gè)新的名為hello.modules的模塊。

We can name this anything we want but follow package naming rules?(i.e., periods to separate words, etc.). We can even use the name of our main package as the module name if we want, but usually, we want to stick to the same name we would use to create a JAR of this module.

我們可以給它起任何名字，但要遵循包的命名規(guī)則（即用句號(hào)來(lái)分隔單詞，等等）。如果我們?cè)敢?，我們甚至可以使用我們的主包的名字作為模塊的名字，但是通常我們希望堅(jiān)持使用與創(chuàng)建這個(gè)模塊的JAR相同的名字。

Under our new module, we can create the packages we want. In our case, we are going to create one package structure:

在我們的新模塊下面，我們可以創(chuàng)建想要的包。

com.baeldung.modules.hello


Next, create a new class called?HelloModules.java?in this package. We will keep the code simple:

接下來(lái)，在這個(gè)包中創(chuàng)建一個(gè)名為 HelloModules.java 的新類(lèi)。為了方便里面，這里將保持代碼的簡(jiǎn)單：

package?com.baeldung.modules.hello;

public?class?HelloModules?{
????public?static?void?doSomething()?{
????????System.out.println("Hello,?Modules!");
????}
}


And finally, in the?hello.modules?root directory, add in our module descriptor;?_module-info.java_：

最后，在 hello.modules 根目錄下，加入我們的模塊描述符；_module-info.java_：

module?hello.modules?{
????exports?com.baeldung.modules.hello;
}


To keep this example simple, all we are doing is exporting all public members of the?com.baeldung.modules.hello?package.

為了保持這個(gè)例子的簡(jiǎn)單，我們所做的就是導(dǎo)出 com.baeldung.modules.hello 包中的所有公共成員。

7.3. Our Second Module

Our first module is great, but it doesn't do anything.

第一個(gè)模塊很好，但是它沒(méi)有做任何事情。

We can create a second module that uses it now.

我們現(xiàn)在可以創(chuàng)建一個(gè)使用它的第二個(gè)模塊。

Under our?simple-modules?directory, create another module directory called?main.app. We are going to start with the module descriptor this time:

在 simple-modules 目錄下面，創(chuàng)建另一個(gè)名叫 main.app 的模塊目錄，這次將會(huì)從模塊描述符開(kāi)始：

module?main.app?{
????requires?hello.modules;
}


We don't need to expose anything to the outside world. Instead, all we need to do is depend on our first module, so we have access to the public classes it exports.

我們不需要向外部世界暴露任何東西。相反，我們需要做的是依賴(lài)我們的第一個(gè)模塊，所以我們可以訪問(wèn)它所輸出的公共類(lèi)。

Now we can create an application that uses it.

現(xiàn)在我們可以創(chuàng)建一個(gè)應(yīng)用程序來(lái)使用它。

Create a new package structure:?com.baeldung.modules.main.

創(chuàng)建新的包 _com.baeldung.modules.main_。

Now, create a new class file called?MainApp.java.

創(chuàng)建名為 ?MainApp.java 的新類(lèi)。

package?com.baeldung.modules.main;

import?com.baeldung.modules.hello.HelloModules;

public?class?MainApp?{
????public?static?void?main(String[]?args)?{
????????HelloModules.doSomething();
????}
}


And that is all the code we need to demonstrate modules. Our next step is to build and run this code from the command line.

這就是我們演示模塊所需的全部代碼。我們的下一步是在命令行中構(gòu)建并運(yùn)行這段代碼。

7.4. Building Our Modules

To build our project, we can create a simple bash script and place it at the root of our project.

Create a file called?compile-simple-modules.sh:

為了構(gòu)建我們的項(xiàng)目，我們可以創(chuàng)建一個(gè)簡(jiǎn)單的bash腳本，并把它放在我們項(xiàng)目的根目錄。

創(chuàng)建一個(gè)名為 compile-simple-modules.sh 的文件：

#!/usr/bin/env?bash
javac?-d?outDir?--module-source-path?simple-modules?$(find?simple-modules?-name?"*.java")


There are two parts to this command, the?javac?and?find?commands.

這個(gè)命令有兩個(gè)部分，_javac_ 和 find 命令。

The?find?command is simply outputting a list of all .java?files under our simple-modules directory. We can then feed that list directly into the Java compiler.

find 命令是簡(jiǎn)單地輸出simple-modules目錄下所有. java 文件的列表。然后我們可以把這個(gè)列表直接輸入到Java編譯器中。

The only thing we have to do differently than the older versions of Java is to provide a?module-source-path?parameter to inform the compiler that it's building modules.

我們唯一要做的與舊版本的Java不同的事情是提供一個(gè) module-source-path參數(shù)來(lái)通知編譯器它正在構(gòu)建模塊。

Once we run this command, we will have an?outDir?folder with two compiled modules inside.

一旦我們運(yùn)行這個(gè)命令，我們將有一個(gè) outDir 文件夾，里面有兩個(gè)已編譯的模塊。

7.5. Running Our Code

And now we can finally run our code to verify modules are working correctly.

現(xiàn)在我們終于可以運(yùn)行我們的代碼來(lái)驗(yàn)證模塊是否正常工作。

Create another file in the root of the project:?run-simple-module-app.sh.

在項(xiàng)目的根目錄下創(chuàng)建另一個(gè)文件：?run-simple-module-app.sh 。

#!/usr/bin/env?bash
java?--module-path?outDir?-m?main.app/com.baeldung.modules.main.MainApp


To run a module, we must provide at least the?module-path?and the main class. If all works, you should see:

要運(yùn)行一個(gè)模塊，我們必須至少提供 module-path 和主類(lèi)。如果一切正常，你應(yīng)該看到：

>$?./run-simple-module-app.sh?
Hello,?Modules!


7.6. Adding a Service

Now that we have a basic understanding of how to build a module, let's make it a little more complicated.

當(dāng)我們使用指令，所有從依賴(lài)關(guān)系導(dǎo)出的公共類(lèi)型都可以被我們的模塊訪問(wèn)。

We're going to see how to use the?provides…with?and?uses?directives.

我們將看到如何使用provides...with和uses指令。

Start by defining a new file in the?hello.modules?module named?HelloInterface.java:

首先在 ?hello.modules 模塊當(dāng)中定義新文件，名字叫做 HelloInterface.java。

public?interface?HelloInterface?{
????void?sayHello();
}


To make things easy, we're going to implement this interface with our existing?HelloModules.java?class:

為了方便起見(jiàn)，我們將用現(xiàn)有的HelloModules.java.class來(lái)實(shí)現(xiàn)這個(gè)接口。

public?class?HelloModules?implements?HelloInterface?{
????public?static?void?doSomething()?{
????????System.out.println("Hello,?Modules!");
????}

????public?void?sayHello()?{
????????System.out.println("Hello!");
????}
}


That is all we need to do to create a?service.

這就是創(chuàng)建服務(wù)所需要做的操作。

Now, we need to tell the world that our module provides this service.

現(xiàn)在需要對(duì)外公開(kāi)自己支持某些服務(wù)。

Add the following to our?module-info.java:

比如像下面這樣對(duì)外暴露接口。

provides?com.baeldung.modules.hello.HelloInterface?with?com.baeldung.modules.hello.HelloModules;


As we can see, we declare the interface and which class implements it.

正如我們所看到的，我們聲明了接口以及哪個(gè)類(lèi)實(shí)現(xiàn)了它。

Next, we need to consume this?service. In our?main.app?module, let's add the following to our?module-info.java:

接下來(lái)，我們需要使用這個(gè)服務(wù)。在我們的main.app模塊中，讓我們?cè)谖覀兊?code>module-info.java中添加以下內(nèi)容：

uses?com.baeldung.modules.hello.HelloInterface;


Finally, in our main method we can use this service via a?ServiceLoader:

最后，在main方法中，我們可以通過(guò)一個(gè)ServiceLoader使用這個(gè)服務(wù)：

Iterable<HelloInterface>?services?=?ServiceLoader.load(HelloInterface.class);
HelloInterface?service?=?services.iterator().next();
service.sayHello();


Compile and run:

編譯并且運(yùn)行。

#>?./run-simple-module-app.sh?
Hello,?Modules!
Hello!


We use these directives to be much more explicit about how our code is to be used.

我們使用這些指令來(lái)更明確地說(shuō)明我們的代碼將如何被使用。

We could put the implementation into a private package while exposing the interface in a public package.

我們可以把實(shí)現(xiàn)放在一個(gè)私有包中，而把接口暴露在一個(gè)公共包中。

This makes our code much more secure with very little extra overhead.

這使得我們的代碼更加安全，而且?guī)缀鯖](méi)有額外的開(kāi)銷(xiāo)。

Go ahead and try out some of the other directives to learn more about modules and how they work.

繼續(xù)嘗試其他一些指令，以了解更多關(guān)于模塊和它們?nèi)绾喂ぷ鳌?/p>

8. Adding Modules to the Unnamed Module

向未命名的模塊添加新模塊的方法如下。

The unnamed module concept is similar to the default package.?Therefore, it's not considered a real module, but can be viewed as the default module.

未命名模塊的概念類(lèi)似于默認(rèn)包。 這個(gè)模塊被叫做默認(rèn)模塊。

If a class is not a member of a named module, then it will be automatically considered as part of this unnamed module.

如果一個(gè)類(lèi)不是一個(gè)命名的模塊的成員，那么它將被自動(dòng)認(rèn)為是這個(gè)未命名的模塊的一部分。

Sometimes, to ensure specific platform, library, or service-provider modules in the module graph, we need to add modules to the default root set. For example, when we try to run Java 8 programs as-is with Java 9 compiler we may need to add modules.

有時(shí)候我們需要在默認(rèn)根集上添加模塊。比如我們使用Java9運(yùn)行低版本的Java8的程序時(shí)候，可能需要添加模塊化。

將命名的模塊添加到默認(rèn)的根模塊集中的命令如下：

In general, the option to add the named modules to the default set of root modules is –add-modules < module >(,< module >)* where < module > is a module name.

將命名的模塊添加到默認(rèn)的根模塊集的選項(xiàng)是 -add-modules <module>(,<module>) ，其中<module>是一個(gè)模塊名稱(chēng)。

For example, to provide access to?all?java.xml.bind?modules the syntax would be:

要提供對(duì)所有_java.xml.bind_模塊的訪問(wèn)，語(yǔ)法如下：

--add-modules?java.xml.bind


To use this in Maven, we can embed the same to the?maven-compiler-plugin:

Maven項(xiàng)目中則可以使用下面的插件：

<plugin>
????<groupId>org.apache.maven.plugins</groupId>
????<artifactId>maven-compiler-plugin</artifactId>
????<version>3.8.0</version>
????<configuration>
????????<source>9</source>
????????<target>9</target>
????????<compilerArgs>
????????????<arg>--add-modules</arg>
????????????<arg>java.xml.bind</arg>
????????</compilerArgs>
????</configuration>
</plugin>


9. Conclusion

整個(gè)文章大致梳理了下面的內(nèi)容：

1. 討論Java出現(xiàn)的模塊化概念。

2. JDK中包含的模塊。

3. 介紹模塊聲明文件，如何在實(shí)際項(xiàng)目使用。

4. 創(chuàng)建了一個(gè)建立在模塊系統(tǒng)之上的簡(jiǎn)單應(yīng)用程序

最后可以從 案例代碼 中找到本文的所有實(shí)踐部分。