探索Java 9模块化：模式与实践

需积分: 10 27 浏览量更新于2024-07-18 收藏 9.28MB PDF 举报

"Java 9 Modularity Patterns and Practices" 在Java 9中，模块系统首次引入到平台中，这是一个重大变革，标志着Java平台上的模块化软件开发新时代的开始。这一变化对于开发者来说是革命性的，通过阅读相关的书籍和学习，开发者可以充分理解和掌握这一新特性，从而充分利用模块系统的潜力。模块化是Java 9的核心改进之一，它改变了Java应用程序构建和部署的方式。正如书评中所提到的，模块化是一种深入而根本的改变，对于Java应用的结构和部署有着深远影响。Java 9的模块系统旨在提供更好的封装性、依赖管理和性能优化。本书《Java 9 Modularity Patterns and Practices》由Sander Mak和Paul Bakker撰写，受到了业界专家的高度评价。Ben Evans，Java Champion和jClarity的联合创始人，认为这本书是指导开发者充分利用Java 9模块系统潜力的重要资源。Martijn Verburg，jClarity的CEO和Oracle Java Champion，表示他在编写Java 9教程、准备演讲以及将jClarity的应用程序转换为使用Java新模块系统的过程中，都受益于这本书，并且他计划为公司的工程团队购买此书。书中的内容涵盖了创建模块化应用程序所必需的关键实践知识，对于希望采用Java 9中这一重大特性的开发者和架构师来说，是一本必读之作。Simon Maple，ZeroTurnaround的开发者关系总监，强调这本书是掌握Java 9中最具影响力功能之一的必备读物。通过学习本书，你可以了解到如何设计和实现模块化的Java 9应用程序，包括如何定义模块（modules），使用`module-info.java`文件声明模块依赖，理解模块路径（module path）与类路径（class path）的区别，以及如何处理模块间的可见性和封装。此外，书中还会探讨最佳实践，如如何有效地组织模块，进行模块化测试，以及如何在现有代码库中迁移至模块化结构。 Java 9的模块系统为大型和复杂的项目带来了更好的可维护性和可扩展性。通过深入理解和实践书中介绍的模式和实践，开发者可以构建出更稳定、更高效的应用程序，同时为未来的Java版本更新做好准备。

Chapter 1. Modularity Matters

Have you ever scratched your head in bewilderment, asking yourself, “Why is this

code here? How does it relate to the rest of this gigantic codebase? Where do I even

begin?” Or did your eyes glaze over after scanning the multitude of Java Archives

(JARs) bundled with your application code? We certainly have.

The art of structuring large codebases is an undervalued one. This is neither a new

problem, nor is it specific to Java. However, Java is one of the mainstream languages

in which very large applications are built all the time—often making heavy use of

many libraries from the Java ecosystem. Under these circumstances, systems can

outgrow our capacity for understanding and efficient development. A lack of

structure is dearly paid for in the long run, experience shows.

Modularity is one of the techniques you can employ to manage and reduce this

complexity. Java 9 introduces a new module system that makes modularization

easier and more accessible. It builds on top of abstractions Java already has for

modular development. In a sense, it promotes existing best practices on large-scale

Java development to be part of the Java language.

The Java module system will have a profound impact on Java development. It

represents a fundamental shift to modularity as a first-class citizen for the whole Java

platform. Modularization is addressed from the ground up, with changes to the

language, Java Virtual Machine (JVM), and standard libraries. While this represents

a monumental effort, it’s not as flashy as, for example, the addition of streams and

lambdas in Java 8. There’s another fundamental difference between a feature like

lambdas and the Java module system. A module system is concerned with the large-

scale structure of whole applications. Turning an inner class into a lambda is a fairly

small and localized change within a single class. Modularizing an application affects

design, compilation, packaging, deployment, and so on. Clearly, it’s much more than

just another language feature.

With every new Java release, it’s tempting to dive right in and start using the new

features. To make the most out of the module system, we should first take a step

back and focus on what modularity is. And, more important, why we should care.

What Is Modularity?

So far, we’ve touched upon the goal of modularity (managing and reducing

complexity), but not what modularity entails. At its heart, modularization is the act

of decomposing a system into self-contained but interconnected modules. Modules

are identifiable artifacts containing code, with metadata describing the module and

its relation to other modules. Ideally, these artifacts are recognizable from compile-

time all the way through run-time. An application then consists of multiple modules

working together.

So, modules group related code, but there’s more to it than that. Modules must

adhere to three core tenets:

Strong encapsulation

A module must be able to conceal part of its code from other modules. By doing

so, a clear line is drawn between code that is publicly usable and code that is

deemed an internal implementation detail. This prevents accidental or unwanted

coupling between modules: you simply cannot use what has been encapsulated.

Consequently, encapsulated code may change freely without affecting users of

the module.

Well-defined interfaces

Encapsulation is fine, but if modules are to work together, not everything can be

encapsulated. Code that is not encapsulated is, by definition, part of the public

API of a module. Since other modules can use this public code, it must be

managed with great care. A breaking change in nonencapsulated code can break

other modules that depend on it. Therefore, modules should expose well-defined

and stable interfaces to other modules.

Explicit dependencies

Modules often need other modules to fulfill their obligations. Such dependencies

must be part of the module definition, in order for modules to be self-contained.

Explicit dependencies give rise to a module graph: nodes represent modules, and

edges represent dependencies between modules. Having a module graph is

important for both understanding an application and running it with all necessary

modules. It provides the basis for a reliable configuration of modules.

Flexibility, understandability, and reusability all come together with modules.

Modules can be flexibly composed into different configurations, making use of the

explicit dependencies to ensure that everything works together. Encapsulation

ensures that you never have to know implementation details and that you will never

accidentally rely on them. To use a module, knowing its public API is enough. Also,

a module exposing well-defined interfaces while encapsulating its implementation

details can readily be swapped with alternative implementations conforming to the

same API.

Modular applications have many advantages. Experienced developers know all too

well what happens when codebases are nonmodular. Endearing terms like spaghetti

architecture, messy monolith, or big ball of mud do not even begin to cover the

associated pain. Modularity is not a silver bullet, though. It is an architectural

principle that can prevent these problems to a high degree when applied correctly.

That being said, the definition of modularity provided in this section is deliberately

abstract. It might make you think of component-based development (all the rage in

the previous century), service-oriented architecture, or the current microservices

hype. Indeed, these paradigms try to solve similar problems at various levels of

abstraction.

What would it take to realize modules in Java? It’s instructive to take a moment and

think about how the core tenets of modularity are already present in Java as you

know it (and where it is lacking).

Done? Then you’re ready to proceed to the next section.

Before Java 9

Java is used for development of all sorts and sizes. Applications comprising millions

of lines of code are no exception. Evidently, Java has done something right when it

comes to building large-scale systems—even before Java 9 arrived on the scene.

Let’s examine the three core tenets of modularity again in the light of Java before the

arrival of the Java 9 module system.

Encapsulation of types can be achieved by using a combination of packages and

access modifiers (such as private, protected, or public). By making a class

protected, for example, you can prevent other classes from accessing it unless they

reside in the same package. That raises an interesting question: what if you want to

access that class from another package in your component, but still want to prevent

others from using it? There’s no good way to do this. You can, of course, make the

class public. But, public means public to every other type in the system, meaning no

encapsulation. You can hint that using such a class is not smart by putting it in an

.impl or .internal package. But really, who looks at that? People use it anyway,

just because they can. There’s no way to hide such an implementation package.

In the well-defined interfaces department, Java has been doing great since its

inception. You guessed it, we’re talking about Java’s very own interface keyword.

Exposing a public interface, while hiding the implementation class behind a factory

or through dependency injection, is a tried-and-true method. As you will see

throughout this book, interfaces play a central role in modular systems.

Explicit dependencies are where things start to fall apart. Yes, Java does have

explicit import statements. Unfortunately, those imports are strictly a compile-time

construct. Once you package your code into a JAR, there’s no telling which other

JARs contain the types your JAR needs to run. In fact, this problem is so bad, many

external tools evolved alongside the Java language to solve this problem. The

following sidebar provides more details.

EXTERNAL TOOLING TO MANAGE DEPENDENCIES: MAVEN

AND OSGI

Maven

One of the problems solved by the Maven build tool is compile-time

dependency management. Dependencies between JARs are defined in an

external Project Object Model (POM) file. Maven’s great success is not the

build tool per se, but the fact that it spawned a canonical repository called

Maven Central. Virtually all Java libraries are published along with their

POMs to Maven Central. Various other build tools such as Gradle or Ant

(with Ivy) use the same repository and metadata. They all automatically

resolve (transitive) dependencies for you at compile-time.

OSGi

What Maven does at compile-time, OSGi does at run-time. OSGi requires

imported packages to be listed as metadata in JARs, which are then called

bundles. You must also explicitly define which packages are exported, that

is, visible to other bundles. At application start, all bundles are checked: can

剩余366页未读，继续阅读

柚子君.

粉丝: 3961
资源: 555

探索Java 9模块化：模式与实践

掌握Java 9模块化：实践与模式

探索Java 9模块化：实践与模式

Java 9 Modularity：串行连接设置优化与精度分析

高清彩版 Java 9 Modularity Patterns and Practices

Java 9 Modularity Patterns and Practices 完整版epub

Java 9 Modularity Patterns and Practices 完整版无水印pdf

Java 9 Modularity Patterns and Practices.pdf 完整版本

Java 9 Modularity: Patterns and Practices

Java 9 Modularity Revealed Project Jigsaw and Scalable Java Applications epub

两本非常不错java 9 学习资料

最新资源