🐹 chap14. 자바 모듈 시스템

Posted Jan 21, 2024

By 채승희 32 min read

자바 9에서 가장 많이 거론되는 새로운 기능은 모듈 시스템이다.

14.1 압력 : 소프트웨어 유추

저수준 영역 : 유지보수하기 쉬운 코드를 구현

고수준 영역 : 궁극적으로 소프트웨어 아키텍처(고수준 기반 코드)를 바꿔야 할 때 유추하기 쉬우므로 생산성을 높일 수 있는 소프트웨어 프로젝트가 필요

→ 관심사 분리와 정보 은닉

14.1.1 관심사 분리

: 컴퓨터 프로그램을 고유의 기능으로 나누는 동작을 권장하는 원칙

Soc(Seperation of concerns) - 관심사 분리

ex) 다양한 형식으로 구성된 지출을 파싱하고, 분석한 다음 결과를 고객에게 요약 보고하는 회계 애플리케이션 개발

SoC(관심사 분리)를 적용함으로 파싱, 분석, 레포트 기능을 모듈이라는 각각의 부분 즉, 서로 거의 겹치지 않는 코드 그룹으로 분리할 수 있다.

→ 클래스를 그룹화한 모듈을 이용해 애플리케이션의 클래스 간의 관계를 시각적으로 보여줄 수 있다.

모델, 뷰, 컨트롤러 같은 아키텍처 관점 그리고 복구 기법을 비즈니스 로직과 분리하는 등의 하위 수준 접근 등의 상황 → SoC 원칙이 유용

[ SoC 원칙의 장점 ]

개별 기능을 따로 작업할 수 있으므로 팀이 쉽게 협업할 수 있다.
개별 부분을 재사용하기 쉽다.
전체 시스템을 쉽게 유지보수할 수 있다.

14.1.2 정보 은닉

: 세부 구현을 숨기도록 장려하는 원칙

소프트웨어를 개발할 때 요구사항은 자주 변경된다. 세부 구현을 숨김으로 프로그램의 어떤 부분을 바꿨을 때 다른 부분까지 영향을 미칠 가능성을 줄일 수 있다.

→ 코드를 관리하고 보호하는 데 유용한 원칙

캡슐화: 특정 코드 조각이 애플리케이션의 다른 부분과 고립되어 있다.

캡슐화된 코드의 내부적인 변화가 의도치 않게 외부에 영향을 미칠 가능성이 줄어든다. 클래스 내의 컴포넌트에 적절히 private 키워드를 사용했는지를 기준으로 컴파일러를 이용해 캡슐화를 확인할 수 있다.

자바 9 이전까지는 클래스와 패키지가 의도된 대로 공개되었는지를 컴파일러로 확인할 수 있는 기능이 없었다.

14.1.3 자바 소프트웨어

잘 설계된 소프트웨어를 만들려면 위의 두 가지 원칙을 따르는 것이 필수다.

코드만으로는 소프트웨어 동작을 추론하기 어렵다. 따라서 UML 다이어그램같은 도구를 이용하면 그룹 코드 간의 의존성을 시각적으로 보여줄 수 있으므로 소프트웨어를 추론하는데 도움이 된다.

정보은닉을 살펴보면 자바에서 public, protected, private 등의 접근 제한자와 패키지 수준 접근 권한을 이용해 메서드, 필드 클래스의 접근을 제어했다.

하지만 이런 방식으로는 원하는 접근 제한을 달성하기 어려우며 심지어 최종 사용자에게 원하지 않는 메서드도 공개해야 하는 상황이 발생했다.

14.2 자바 모듈 시스템을 설계한 이유

14.2.1 모듈화의 한계

자바 9 이전까지는 모듈화된 소프트웨어 프로젝트를 만드는 데 한계가 있었다.

자바는 클래스, 패키지, JAR 세 가지 수준의 코드 그룹화를 제공한다. 클래스와 관련해 자바는 접근 제한자와 캡슐화를 지원했다.

하지만 패키지와 JAR 수준에서는 캡슐화를 거의 지원하지 않았다.

제한된 가시성 제어

자바의 네 가지 가시성. 접근자

→ public, protected, 패키지 수준(default) , private

패키지 간의 가시성은 어떻게 제어할까?

한 패키지의 클래스와 인터페이스를 다른 패키지로 공개하려면 public을 선언해야 한다. 결과적으로 이들 클래스와 인터페이스는 모두에게 공개된다.

특히 기본 구현을 제공하는 의미로 “impl”이라는 문자열을 가진 패키지에서 이런 문제가 두드러진다. 이런 상황에서 보통 패키지 내부의 접근자 public 이므로 사용자가 이 내부 구현을 마음대로 사용할 수 있다.

⇒ 다른 프로그래머가 임시적으로 사용해 정착해버릴 수 있으므로 기존의 애플리케이션을 망가뜨리지 않고 라이브러리 코드를 바꾸기 어려워진다. 보안 측면에서도 코드가 노출되었으므로 임의로 조작하는 위협에 도 많이 노출될 수 있다.

클래스 경로

애플리케이션을 번들하고 실행하는 기능과 관련해 자바는 태생적으로 약점을 갖고 있다. 클래스를 모두 컴파일한 다음 보통 한 개의 평범한 JAR 파일에 넣고 클래스 경로에 이 JAR 파일을 추가해 사용할 수 있다. 그러면 JVM이 동적으로 클래스 경로에 정의된 클래스를 필요할 때 읽는다.

클래스 경로와 JAR 조합에는 몇 가지 약점이 존재한다.

클래스 경로에는 같은 클래스를 구분하는 버전 개념이 없다.
ex) 파싱 라이브러리 JSONParser 클래스를 지정할 때 버전 1.0을 사용하는지 버전 2.0을 사용하는지 지정할 수가 없으므로 클래스 경로에 두 가지 버전의 같은 라이브러리가 존재할 때 어떤 일이 일어날지 예측할 수 없다.
다양한 컴포넌트가 같은 라이브러리의 다른 버전을 사용하는 상황이 발생할 수 있는 큰 애플리케이션에서 이런 문제가 두드러진다.
클래스 경로는 명시적인 의존성을 지원하지 않는다.
각각의 JAR 안에 있는 모든 클래스는 classes라는 한 주머니로 합쳐진다. 즉 한 JAR가 포함된 클래스 집합을 사용하라고 명시적으로 의존성을 정의하는 기능을 제공하지 않는다. 이 상황에서는 클래스 경로 때문에 어떤 일이 일어나는지 파악하기 어려우며, 다음과 같은 의문이 든다.
- 빠진 게 있는가?
- 충돌이 있는가?
메이븐이나 그레이들 같은 빌드 도구는 이런 문제를 해결하는 데 도움을 준다.
하지만 자바 9 이전에는 자바, JVM 누구도 명시적인 의존성 정의를 지원하지 않았다.

14.2.2 거대한 JDK

자바 개발 키트(JDK): 자바 프로그램을 만들고 실행하는 데 도움을 주는 도구의 집합

javac - 자바 프로그램 컴파일러
java - 자바 애플리케이션을 로드하고 실행
JDK 라이브러리 - 입출력을 포함해 런타임 지원을 제공
컬렉션
스트림

등이 있다.

자바 8의 컴팩트 프로파일 기법: 관련 분야에 따라 JDK라이브러리가 세 가지 프로파일로 나뉘어 각각 다른 메모리 풋프린트를 제공

14.3 자바 모듈 : 큰 그림

자바 8는 모듈이라는 새로운 자바 프로그램 구조 단위를 제공한다.

module이라는 새 키워드에 이름과 바디를 추가해서 정의한다.

모듈 디스크립터

module-info.java라는 특별한 파일에 저장
보통 패키지와 같은 폴더에 위치하며 한 개 이상의 패키지를 서술하고 캡슐화할 수 있지만 단순한 상황에서는 이들 패키지 중 한 개만 외부로 노출시킴

직소 퍼즐에 비유하자면 exports - 돌출부, requires - 패인 부분 으로 생각할 수 있다.

메이븐 같은 도구를 사용할 때 모듈의 많은 세부 사항을 IDE가 처리하며 사용자에게는 잘 드러나지 않는다.

14.4 자바 모듈 시스템으로 애플리케이션 개발하기

14.4.1 애플리케이션 셋업

자바 모듈 시스템을 적용하기 위해 코드를 구현할 예제 프로젝트로 영수증 비용 관리 애플리케이션을 구현해보자. 다음과 같은 여러 작업을 처리해야 한다.

파일이나 URL에서 비용 목록을 읽는다.
비용의 문자열 표현을 파싱한다.
통계를 계산한다.
유용한 요약 정보를 표시한다.
각 태스크의 시작, 마무리 지점을 제공한다.

애플리케이션의 개념을 모델링할 여러 클래스와 인터페이스를 정의해야 한다.

[ Reader 인터페이스 ]: 소스에서 얻어온 직렬화된 지출을 읽는 역할

소스가 어디냐에 따라 HttpReader, FileReader 등 여러 구현을 제공해야 한다.
JSON 객체를 자바 애플리케이션에서 사용할 수 있는 도메인 객체 Expense로 재구성할 Parser 인터페이스도 필요하다.
주어진 Expense 객체 목록으로 통계를 계산하고 SummaryStatistics 객체를 반환하는 SummaryCalculator 클래스가 필요하다.

프로젝트를 준비했으니 자바 모듈 시스템으로 이들을 모듈화해야 한다. 프로젝트에는 다음처럼 분리할 수 있는 여러 기능(관심사)이 있다.

다양한 소스에서 데이터를 읽음(Reader, HttpReader, FileReader)
다양한 포맷으로 구성된 데이터를 파싱(Parse, JSONParser, ExpenseJSON-Parser)
도메인 객체를 구체화(Expense)
통계를 계산하고 반환(SummaryCalculator, SummaryStatics)
다양한 기능을 분리 조정(ExpensesApplication)

교수법에 따라 아주 세부적으로 문제를 나누는 접근 방법을 이용한다. 다음처럼 각 기능을 그룹화할 수 있다(모듈을 명명한 배경은 나중에 설명한다)

expenses.readers
expenses.readers.http
expenses.readers.file
expenses.parsers
expenses.parsers.json
expenses.model
expenses.statistics
expenses.application

이 간단한 애플리케이션에서 모듈 시스템의 여러 부분이 두드러질 수 있도록 잘게 분해했다.

간단한 프로젝트에서 이처럼 잘게 분해해 작은 기능까지 캡슐화하는 것은 장점에 비해 초기 비용이 높아진다. 하지만 프로젝트가 점점 커지면서 많은 내부 구현이 추가되면 이때부터 캡슐화와 추론의 장점이 두드러진다.

위 목록들은 애플리케이션 경계에 의존하는 패키지 목록으로 생각할 수 있다. 아마 각 모듈은 다른 모듈로 노출하고 싶지 않는 내부 구현을 포함할 것이다.

ex) expenses.statistics 모듈은 실험적인 통계 방법을 다른 방법으로 구현한 여러 패키지를 포함할 수 있다. 이들 패키지에서 어떤 것을 사용자에게 릴리스할지는 나중에 결정할 수 있다.

14.4.2 세부적인 모듈화와 거친 모듈화

세부적인 모듈화
: 모든 패키지가 자신의 모듈을 갖는다.
→ 설계 비용 증가
거친 모듈화
: 한 모듈이 시스템의 모든 패키지를 포함한다.
→ 모듈화의 모든 장점을 잃음

가장 좋은 방법은 시스템을 실용적으로 분해하면서 진화하는 소프트웨어 프로젝트가 이해하기 쉽고 고치기 쉬운 수준으로 적절하게 모듈화되어 있는지 주기적으로 확인하는 프로세스를 갖는 것이다.

모듈화 = 소프트웨어 부식의 적

14.4.3 자바 모듈 시스템 기초

메인 애플리케이션을 지원하는 한 개의 모듈만 갖는 기본적 모듈화 애플리케이션

module-info.java라는 파일이 프로젝트 구조의 일부에 포함되어 있다. 이 파일은 앞에서 설명한 모듈 디스크립터로 모듈의 소스코드 파일 루트에 위치해야 하며 모듈의 의존성 그리고 어떤 기능을 외부로 노출할 지를 정의한다.

지출 애플리케이션 예제에서는 아직 다른 모듈에 의존하거나 외부로 노출하는 기능이 없으므로 최상위 수준의 module-info.java 파일에 이름만 정의되어 있을 뿐 내용은 비어있다.

  
// 현재 module-info.java
module expenses.application {

}

[ 모듈화 애플리케이션 실행 방법 ]

프로젝트의 모듈 소스 디렉터리에서 다음 명령을 실행한다.

javac module-info.java
    com/example/expenses/application/ExpensesApplication.java -d target

jar cvfe expenses-application.jar
    com.example.expenses.application.ExpensesApplication -C target

그럼 어떤 폴더와 클래스 파일이 생성된 JAR(expenses-application.jar)에 포함되어 있는지를 보여주는 다음과 같은 결과가 출력된다.

added manifest
added module-info: module-info.class adding: com/(in = 0) (out= 0)(stored 0%)
adding: com/example/(in = 0) (out= 0)(stored 0%)
adding: com/example/expenses/(in = 0) (out= 0)(stored 0%)
adding: com/example/expenses/application/(in = 0) (out= 0)(stored 0%)
adding: com/example/expenses/application/ExpensesApplicatioin.class(in = 456)
	(out= 306)(deflated 32%)

마지막으로 생성된 JAR를 모듈화 애플리케이션으로 실행한다.

java --module-path expenses-application.jar \
	 --module expenses/com.example.expenses.application.ExpensesApplication

처음 두 과정은 자바 애플리케이션을 JAR로 패키징하는 표준 방법이므로 이미 익숙할 것이다. 새로운 부분은 컴파일 과정에 새로 추가된 module-info.java다.

java 프로그램으로 자바 .class 파일을 실행할 때 다음과 같은 두 가지 옵션이 새로 추가되었다.

--module-path : 어떤 모듈을 로드할 수 있는지 지정한다. 이 옵션은 클래스 파일을 지정하는 --classpath 인수와는 다르다.
--module : 이 옵션은 실행할 메인 모듈과 클래스를 지정한다.

모듈 정의는 버전 문자열을 포함하지 않는다.

자바 9 모듈 시스템에서 버전 선택 문제를 크게 고려하지 않았고 따라서 버전 기능은 지원하지 않는다. 대신 버전 문제는 빌드 도구나 컨테이너 애플리케이션에서 해결해야 할 문제로 넘겼다.

14.5 여러 모듈 활용하기

모듈을 이용한 기본 애플리케이션을 설정했다.

비용 애플리케이션이 소스에서 비용을 읽을 수 있어야 한다. 이 기능을 캡슐화한 expense.reader라는 새 모듈을 만들 것이다. expenses.application와 expenses.readers 두 모듈간의 상호 작용은 자바 9에서 지정한 export, requires를 이용해 이루어진다.

14.5.1 exports 구문

다음은 expenses.readers 모듈의 선언이다.

  
module expenses.readers {
    // 이들은 모듈명이 아니라 패키지명
    exports com.example.expenses.readers;
    exports com.example.expenses.readers.file;
    exports com.example.expenses.readers.http;
}

exports → 다른 모듈에서 사용할 수 있도록 특정 패키지를 공개 형식으로 만든다.

기본적으로 모듈 내의 모든 것은 캡슐화 된다. 모듈 시스템은 화이트 리스트 기법을 이용해 강력한 캡슐화를 제공하므로 다른 모듈에서 사용할 수 있는 기능이 무엇인지 명시적으로 결정해야 한다(이 접근법은 실수로 어떤 기능을 외부로 노출함으로 몇 년이 지난 뒤에 해커가 시스템을 남용할 여지를 방지한다).

프로젝트의 두 모듈의 디렉터리 구조는 다음과 같다.

14.5.2 requires 구문

또는 다음처럼 module-info.java를 구현할 수 있다.

  
module expenses.readers {
    requires java.base; // 패키지명이 아니라 모듈명이다.

    exports com.example.expenses.readers;
    exports com.example.expenses.readers.file;
    exports com.example.expenses.readers.http;
}

requires → 의존하고 있는 모듈을 지정한다.

기본적으로 모든 모듈은 java.base라는 플랫폼 모듈에 의존하는데 이 플랫폼 모듈은 net, io, util 등 자바의 메인 패키지를 포함한다. (항상 기본적으로 필요한 모듈이므로 java.base는 명시적으로 정의할 필요가 없다.)

자바에서 “class Foo extends Object { … }”처럼 하지 않고 “class Foo { … }”처럼 클래스를 정의하는 것과 같은 원리다.

따라서 java.base 외의 모듈을 임포트할 때 requires를 사용한다.

자바 9에서는 requires와 exports 구문을 이용해 좀 더 정교하게 클래스 접근을 제어할 수 있다. 아래는 자바 9 이전과 이후의 접근자와 가시성 변화를 보여준다.

14.5.3 이름 정하기

오라클

→ 패키지명처럼 인터넷 도메인명을 역순(ex. com.iteratrlearning.training)으로 모듈의 이름을 정하도록 권고한다. 더욱이 모듈명은 노출된 주요 API 패키지와 이름이 같아야 한다는 규칙도 따라야 한다.

모듈이 패키지를 포함하지 않거나 어떤 다른 이유로 노출된 패키지 중 하나와 이름이 일치하지 않는 상황을 제외하면 모듈명은 작성자의 인터넷 도메인 명을 역순으로 시작해야 한다.

14.6 컴파일과 패키징

먼저 각 모듈에 pom.xml을 추가해야 한다. 사실 각 모듈은 독립적으로 컴파일되므로 자체적으로 각각이 한 개의 프로젝트다. 전체 프로젝트 빌드를 조정할 수 있도록 모든 모듈의 부모 모듈에도 pom.xml을 추가한다. 전체 구조는 다음과 같다.

이렇게 3개의 pom.xml 파일을 추가해 메이븐 디렉터리 프로젝트 구조를 완성했다. 모듈 디스크립터(module-info.java)는 src/main/java 디렉터리에 위치해야 한다. 올바른 모듈 소스 경로를 이용하도록 메이븐이 javac를 설정한다.

다음은 expenses.readers 프로젝트의 pom.xml 모습이다.

  
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0,0"
		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
	http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.example</groupId>
	<artifactId>expenses.readers</artifactId>
	<version>1.0</version>
	<packaging>jar</packaging>
	<parent>		
		<groupId>com.example</groupId>
		<artifactId>expenses</artifactId>
		<version>1.0</version>
	</parent>
</project>

순조롭게 빌드될 수 있도록 명시적으로 부모 모듈을 지정한 코드를 보자.

부모는 ID expenses를 포함하는 부산물(artifact)이다. pom.xml에 부모를 정의해야 한다.

다음으로 expenses.application 모듈의 pom.xml을 정의한다. 이 파일은 이전 파일과 비슷하지만 ExpenseApplication이 필요로 하는 클래스와 인터페이스가 있으므로 expenses.readers를 의존성으로 추가해야 한다.

  
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0,0"
		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
	http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.example</groupId>
	<artifactId>expenses.application</artifactId>
	<version>1.0</version>
	<packaging>jar</packaging>
	
	<parent>
		<groupId>com.example</groupId>
		<artifactId>expenses</artifactId>
		<version>1.0</version>
	</parent>

	<dependencies>
		<dependency>
			<groupId>com.example</groupId>
			<artifactId>expenses.readers</artifactId>
			<version>1.0</version>
		</dependency>
	</dependencies>

</project>

expenses.application과 expenses.readers 두 모듈에 pom.xml을 추가했으므로 이제 빌드 과정을 가이드할 전역 pom.xml을 설정할 차례다.

메이븐은 특별한 XML 요소 (자식의 부산물 ID를 참조)을 가진 여러 메이븐 모듈을 가진 프로젝트를 지원한다. 다음은 두 개의 자식 모듈 expenses.application와 expenses.readers를 참조하도록 완성한 pom.xml 정의다.

  
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0,0"
		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
	http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.example</groupId>
	<artifactId>expenses</artifactId>
	<packaging>pom</packaging>
	<version>1.0</version>

	<modules>
		<module>expenses.application</module>
		<module>expenses.readers</module>
	</modules>

	<build>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-compiler-plugin</artifactId>
					<version>3.7.0</version>
					<configuration>
						<source>9</source>
						<target>9</target>
					</configuration>
				</plugin>
			</plugins>
		</pluginManagement>
	</build>
</project>

mvn clean package 명령을 실행해서 프로젝트의 모듈을 JAR로 만들 수 있다. 다음과 같은 부산물이 만들어진다.

./expenses.application/target/expenses.application-1.0.jar
./expenses.readers/target/expenses.readers-1.0.jar

두 JAR을 다음처럼 모듈 경로에 포함해서 모듈 애플리케이션을 실행할 수 있다.

java --module-path \
./expenses.application/target/expenses.application-1.0.jar:\
./expenses.readers/target/expenses.readers-1.0.jar \
	--module \
	expenses.application/com.example.expenses.application.ExpensesApplication

지금까지 모듈을 만드는 방법을 배웠으며 requires로 java.base를 참조하는 방법도 살펴봤다.

실제로는 java.base 대신 외부 모듈과 라이브러리를 참조해야 한다.

14.7 자동 모듈

HttpReader를 저수준으로 구현하지 않고 아파치 프로젝트의 httpclient 같은 특화 라이브러리를 사용해 구현한다고 가정했을 때, 이런 라이브러리를 프로젝트의 추가하려고 한다.

requires 구문을 배웠으므로 expenses.readers 프로젝트의 module-info.java에 이 구문을 추가한다. mvn clean package를 다시 실행하면 다음과 같은 에러가 발생한다.

[ERROR] module not found: httpclient

의존성을 기술하도록 pom.xml도 갱신해야 하므로 에러가 발생하는 것이다.

메이븐 컴파일러 플러그인은 module-info.java를 포함하는 프로젝트를 빌드할 때 모든 의존성 모듈을 경로에 놓아 적절한 JAR를 내려받고 이들이 프로젝트에 인식되도록 한다. 다음과 같은 의존성이 필요하다.

  
<dependencies>
	<dependency>
		<groupId>org.apache.httpcomponents</groupId>
		<artifactId>httpclient</artifactId>
		<version>4.5.3</version>
	</dependency>
</dependencies>

다시 mvn clean package를 실행하면 프로젝트가 올바로 빌드된다. 하지만 httpclient는 자바 모듈이 아니다.

httpclient는 자바 모듈로 사용하려는 외부 라이브러리인데 모듈화가 되어 있지 않은 라이브러리다. 자바는 JAR를 자동 모듈이라는 형태로 적절하게 변환한다. 모듈 경로상에 있으나 module-info 파일을 가지지 않은 모든 JAR는 자동 모듈이 된다.

자동 모듈은 암묵적으로 자신의 모든 패키지를 노출시킨다. 자동 모듈의 이름은 JAR 이름을 이용해 정해진다. jar 도구의 --describe-module 인수를 이용해 자동으로 정해지는 이름을 바꿀 수 있다.

jar --file=./expenses.readders/target/dependency/httpclient-4.5.3.jar \
	--describe-module httpclient@4.5.3 automatic

그러면 httpclient라는 이름으로 정의된다.

마지막으로 httpclient JAR를 모듈 경로에 추가한 다음 애플리케이션을 실행한다.

java --module-path \
	./expenses.application/target/expenses.application-1.0.jar: \
	./expenses.readers/target/expenses.readers-1.0.jar \
	./expenses.readers/target/dependency/httpclient-4.5.3.jar \
	    --module \
	expenses.application/com.example.expenses.application.ExpensesApplication

14.8 모듈 정의와 구문들

module 지시어를 이용하면 모듈을 정의할 수 있다. 다음은 com.iteratrlearning.application라는 모듈명의 예제다.

  
module com.iteratrlearning.application {

}

requires, exports 구문 이외에도 requires-transitive, exports-to, open, opens, uses, provides 같은 다른 구문들도 있다.

모던 자바 인 액션, chap14. 자바 모듈 시스템

모던 자바 인 액션 JAVA 14주차 채승희

This post is licensed under CC BY 4.0 by the author.