자바 모듈 시스템 – JSR 277

본 원고는 필자가 2008년 1월호 마이크로소프트웨어에 기고한 내용입니다. 자료를 옮기시거나 사용하시려면 출처를 밝혀주시면 됩니다.

자바의 플랫폼에 대한 부분과 표준화 방식에 대해서 이야기 한 것은 JSR 277에 대한 부분을 이야기하기 위함이다. 자바는 JSR, JCP, RI등을 통해서 스펙이 결정되고 발전하는 과정을 거쳐간다. 이미 자바는 JAVA7이라는 새로운 플랫폼 규격을 선보이고 있는데, 그중에서 눈에 띠는 부분이 바로 JSR 277이다. 자바 모듈 시스템이라는 새로운 규격은 자바의 모듈성을 강조하는 새로운 시스템이다. 다만 우리는 OSGi라는 미들웨어 프래임워크를 알고있기에 JSR 277이 OSGi라는 아키텍쳐를 그대로(?) 모방했음을 쉽게 짐작할 수가 있다. 썬에서도 JSR 277은 JSR 291-OSGi 규격과 서로 상호호환하고 경쟁하면서 발전해 나가야한다고 발표하기도 했는데, 여기에는 매우 복잡하고 미묘한 관계들이 엃혀져 있다. 우선 JSR 277이란 무엇인지 알아보기도 한다. 기존 자바에서는 지원하는 모듈방식을 결정하는 것들은 크게 두가지인데, 논리적인 모듈방식(Logical Modularity)과 실질적인 모듈방식(Physical Modularity)이 있다.

[그림1. Java Logical Module View]

 

논리적인 방식에는 Classes, Packages, Class Loaders 등이 있으며, 실질적인 모듈방식에는 class file과 JAR file 이 있다. 이러한 모듈방식에는 몇가지 문제가 있는데 다음과 같은 것들이다.

 

1) 제한된 Scoping Mechanisms

2) 기본적인 그리고 제한된 기능의 버전 관리

3) 모듈간 의존성(Implicit Dependency) 문제

4) 패키지에서의 단순한 Class path 관리

5) 불분명한 Class Space Consistency

 

결국 이러한 부분들은 자바 플랫폼에서 모듈이라는 실행단위가 명확하게 지원되지못하는 문제에서 기인한다고 결론낼수가 있다. 이에 썬에서는 한정적인 자바 플랫폼 위에서(J2ME) 운영되는 OSGi 모델을 자바 플랫폼내에서 구현하기로 결정한다. 하나의 자바 V M 인스턴스에서 운영되는 멀티 서비스, 번들로 구분되는 다이나믹 모듈 시스템, 번들단위로 실행되는 커스텀 클래스 로더에서 얻어지는 많은 장점 – 클래스 로더간의 연결성, 독립적인 Namespace, 패키지 레벨에서의 클래스 공유 – 등이 더 이상 자바 플랫폼에서 운영되는 하나의 OSGi 프래임워크가 아닌 모든 자바 플랫폼에서 운영되는 다이나믹 자바 모듈 시스템으로 확장되는 계기를 마련해주었다. JSR 277에서 중점은 두고 개발한 부분은 다음과 같다.

 

1) 버전관리 (Version Management)

2) 배포(Distribution) 및 패키징 (Packaging)

3) 새로운 저장소 (New Repository)

4) 모듈간 공유 및 연결성 (Module Interconnection)

 

[그림 2. 새로운 배포 포맷 JAM의 예제]

 

이러한 특징들을 위해서 기존 JAR 포맷을 대신하여 JAM이라는 새로운 포맷을 탄생시켰으며, JSR 294와 연합하여 JSR 277 내부에 VM, Language들을 통합시켜버렸다. JAM이 탄생하기까지에는 기존의 JAR가 가져온 문제점들이 너무나 컸기 때문이다. 현재 자바에서 배포의 표준파일 타입은 JAR인데, 단순한 버전관리, 다른 JAR파일과의 레퍼런스 문제, 복수개의 JAR파일과 Native lib과의 연동 그리고 마지막으로 JAR는 배포와 실행 파일의 포맷을 모두 담당하고 있으면서 문제점들을 계속 노출시켜왔다. 결국 JAR가 내포하고 있는 문제점들이 우리가 위에서 살펴본 JSR 277의 탄생 이유이기도 하다. 또한 기존의 클래스 라이브러리들과 JDK 툴들도 통합시켜 확장된 하나의 플랫폼을 탄생시켰다. 이러한 새로운 플랫폼 규격에 가장 큰 특징은 역시 플러그인 스타일의 다이나믹 구조인데, OSGi 번들구조를 그대로 가져온것이라고해도 무방할정도이다. JSR 277에서는 OSGi의 번들을 모듈(Module)이라고 부르는데, JSR 277과 291(OSGi)간의 비교를 해보도록 하자. 우선 JSR 277, 291 모두에게 적용되는 특징은 다음과 같다. (Module는 Bundle로 생각하면 된다)

 

• Module name
• Module version
• Module attributes
• Module import
• Module re-export
• Version range
• Optional import
• Executable modules
• One class loader per module
• Platform dependencies
• Classes, native libraries, resources, 확장된 metadata가 포함된 Module
• JAR distribution format
• Reflective API

[그림 3. 모듈(번들)별 실행되는 클래스 로더]

 

반면 JSR277만의 고유한 특징도 있는데, 다음과 같다.

 

• Standard repository : 하나의 래포지터리에서 다양한 복수개의 모듈을 관리한다
• JAM distribution format : 기존 JAR 보다 더욱 강력한 배포 파일 포맷이다.
• Import override policy
• Part of the Java SE platform

 

결국 JSR 277 자바 모듈 시스템은 자바 파일의 배포와 실행 그리고 버전관리에 보다 중점을 두고 설계된 시스템이며 이러한 시스템은 OSGi의 번들이 다이나믹하게 플러그인 되고 수행되는 구조를 자바에 맞게 최적화된 구조방식이라고 볼수가 있다. 그러나 자바의 한계를 넘지못한 부분도 여전히 눈에 보이는데, 그것은 독자적인 OSGi만의 특징이기도 하다. 이번에는 JSR 277에 포함되지 못한 JSR 291(OSGi)의 고유 특징을 살펴보자

 

• Dynamic lifecycle support (번들, 서비스) : 다이나믹한 기능은 여전히 OSGi가 탁월하다
• Package import
• Dynamic package import
• Package attributes
• Mandatory attributes
• Split package support
• Module classpath
• Fragment modules
• Extension modules
• Pure Java implemented on top of Java SE
• Compatible with Java ME (JSR 232)

 

결국 특징들을 살펴보면 새로운 배포파일의 포맷(JAM)이나 모듈간의 연결성, Repository의 지원등 각자 고유한 부분이 있으나, 플랫폼에서의 다이나믹한 모듈 구조의 설계방식은 같다고 볼수가 있다.