OSGI에서 Jigsaw로 모듈 시스템

OSGI (Open Service Gateway initiative)

OSGI의 핵심 개념은 프로그램을 만들 때 하나의 큰 프로그램으로 만들지 않고 여러 가지의 작은 프로그램을 만든 후 이것을 하나로 묶어 내는 것입니다.
OOP가 클래스를 모듈화 시키는 것이라고 했을때, OSGI는 아예 프로그램 자체를 모듈화(OSGI에서는 이것을 번들(bundle)이라고 부릅니다.) 하고, OSGI Framework에서 이 모듈들을 각각 등록시키고 요청에 따라 실행을 시키게 됩니다.
OSGI의 장점은 다른 모듈의 코드를 전혀 신경쓰지 않아도 된다는 것이며, Input과 Output의 형태만 유지시켜주면 코드 변경으로 인한 오류가 일어날 걱정을 하지 않아도 된다는 것 입니다.
또한 가장 큰 특징으로 OSGI의 life cycle(설치, 실행, 중지)가 프로그램과 별개로 일어나기 때문에 모듈을 업데이트하거나 새로운 모듈을 적용할때 프로그램을 재시작 하지 않아도 된다는 것입니다.

OSGI의 한계

모듈 프로그래밍은 다음 요소들이 설계 원칙입니다.

1. 모듈 간 느슨한 coupling
2. clear한 모듈 간 종속성
3. 강력한 캡슐화를 이용한 숨겨진 구현

Java의 OSGI에서 Jar는 모듈의 단위가 되었는데, Jar는 다음과 같은 단점이 있습니다.

1. jar간 명시적인 종속성
2. jar내의 모듈의 약한 캡슐화
3. 컴파일은 정상적으로 되었지만 런타임시 클래스 경로의 누락 된 JAR 때문에 ClassNotFoundException이 발생된다는 것

Jigsaw

위와 같은 단점들을 극복하고자 JDK 9버전에서 직소 프로젝트가 도입되었습니다.
기존의 자바의 접근제한자의 타입은 다음과 같았습니다.

• public
• default
• protected
• private

하지만 OSGI와 같은 모듈 프로그래밍에서는 큰 단점이 존재합니다.
A라는 모듈이 여러 패키지로 구성되어 있어 패키지 간의 참조때문에 public으로 선언된 클래스나 메서드들이 있다고 가정할때, A라는 모듈을 참조하는 B모듈은 이러한 public 클래스와 메서드를 모두 참조할수 있습니다.
이는 A가 B에게 제공하지 않는 함수들까지 모두 공개가 된다는 말이고, 이는 캡슐화가 적절히 이루어지고 있다고 하기 어렵습니다. 또한 협업 시, 제공해주려하지 않은 기능까지 모두 제공해주게 되다보니 이를 이용하려는 개발자에게 혼란을 야기하기도 합니다.
그래서 직소에서는 어떤것을 제공하는지(export), 어떤것들이 필요한지(require)를 명시함으로써 다음과 같이 접근제한자의 폭을 넓혔습니다.

• 외부에 모두 Public (public to everyone who reads this module (exports))
• 특정 모듈에만 Public (public to some modules that read this module (exports to))
• 모듈 내부만 Public (public to every other class within the module itself)
• private
• default
• protected

이렇게 직소를 이용하면 원하는 타겟에게 원하는 클래스나 메서드를 제공해줌으로써 더 명확하고 캡슐화가 지원되는 모듈 프로그래밍이 가능하게 되었습니다.

추가 참조

https://www.baeldung.com/project-jigsaw-java-modularity
https://infoscis.github.io/2017/03/24/First-steps-with-java9-and-jigsaw-part-1/