시작 ====

자바 언어에서는 이미 전체 프로젝트를 모듈화하는 기본적인 기재들은 갖추고 있다. jar, war 등을 써서 이미 필요한 부분을 떨어뜨릴 수 있고,

그렇기 때문에 그런것들을 다운받아서, 라이브러리로 받아서 한글처리나, 구아바, RXJava 같은 비동기 라이브러리가 되었든, 새로 개발하지 않고 사용 가능하다.

사실 내가 짜고 있는 프로그램에서도, interface 를 잘 쓰면 모듈화가 가능하다. 자바에서는 패키지를 제공하기 때문에 3 dept, 4 dept 처럼 단계를 가지고, 자바 언어에서 제공해주는 public, private 등을 이용하여 기본적인 구조화, 모듈화가 가능하다.

그럼에도 불구하고 왜 이런 모듈이란 새로운 게 나왔는지, 기존것과 무엇이 다른지를 이해해야한다.

자바 9의 언어의 모듈화는 어떻게 되었을까?

  1. javadoc 이 달라졌다. https://docs.oracle.com/javase/10/docs/api/index.html?overview-summary.html

예전 자바doc을 들어가면 좌측은 패키지와 우측은 해당 패키지의 doc이었는데, 좌측 상단의 모듈들이 생기게 되었다. 모듈에서 패키지가 나온다.

base 모듈을 들어가보면, Exports Package 라는 항목이 나온다.

Package Description
java.io Provides for system input and output through data streams, serialization and the file system.
java.lang Provides classes that are fundamental to the design of the Java programming language.

provides 와 usec 는 서비스입니다.

자바 내부가 모듈화가 되었다는 첫번째 의미로 보았을, 여지껏 패키지로 모듈화가 되었다고 한다면, JAVA 7 기준으로 서로가 서로를 참조하는 매우 어려운 구성에서, JAVA 9 에서는 모듈화가 되면서 조금더 간략하게 되었다.

트리구조는 아래쪽을 띄어내서 모듈화하기 쉽지만, A > B > C > D > A 구조와 같은 순환처리를 하게 되면 트리구조와는 다르게 띄어내기가 힘들다. 그래서 JDK 라는 전체 클래스가 5천개가 넘는데, 해당 클래스들의 순환참조를 다 끊어냈다가, 2년여간에 걸쳐 Project jigsaw (모듈화된 JDK)라는 이름하에 다 끊어냈다. java.se 를 보더라도 순환처리가 없는 것을 알 수 있다.

모듈로 패키징하여 서로간의 순환참조를 하지 않도록 구성했다. 이것이 가능해지면서 기존에는 불가능한 구조가 가능하게 되었다.

원래는 2017년 9월에 나왔는데 2016년 초에 나오는게 목표였는데, 2016년부터 자바의 라이브러리를 만드는 최신 트랜드를 고민하는 개발자들은, 내가 가진 라이브러리로 고정부와 변동부, 확장과 기본, 아니면 계열분리와 같은 식으로, 라이브러리를 재작성하는 사례들이 있었다.

RxJava 도 그런 형태로 그렇고, JUnit 또한 테스트 프로그램을 만들 때, JUnit5 가 모듈화되어서 나왔다. 테스팅을 하는 일반적인 JUnit5, Junit 쥬피터, Junit3나 4에 대한 레거시를 확장가능한 Junit 빈티지 와 같은 3개의 라이브러리를 모듈화하여 나왔었다. (JUnit 5 = JUnit platform + JUnit Jupiter + Junit vinatage)

- foundaton for launching testung frameworks on the JVM
- the combination of the new programming model and extension model for writing test and extenstions Junit 5
- TestEngine for running JUnit 3 and JUnit 4 based tests on the platform

솔직히 이렇게 하려면 어렵다. 고정부와 변동부를 쪼갠다는 건 매우 어려운 일이다. 관리자들이 이게 왜 필요한지를 모른다. 실제로 고정부와 변동부를 잘 쪼갰는지에 대해서는 잘 이해하기 어렵다. 그랬을 경우 성능은 떨어지지 않았는지에 대한 고민 또한 필요하다.

  1. 자바 언어에서 모듈이란 키워드가 추가되었다. 그리고 모듈이란 키워드는 module-info.java에 들어간다. 들어가는 것은 export, requires 등이 있다. 그리고 사실 usec도 있고 provides도 있 커테인스도 있고 멘데이스도 있 많다.

  2. Project Jigsaw라는 프로젝트에 의해 JDK도 모듈이 되었다. 가장 자주 쓰이는 것은 java.base, java.xml, java.sql 등이 있다.

  3. 모듈은 exports 한다. 모듈은 내부적으로 숨길수도 있고 외부에 노출 시킬 수 있지만, 기본적으로 exports는 패키지 단위로 한다. 이것은 java 9의 설계한 설계자의 선택이었다.

  4. public 도 exports 해야만 외부에서 참조 가능하다. (Reflection도 불가능하다.) public 은 어디서나 참고가능했었다. 패키지 내부는 default 나 protected 나 그런것으로 보호하지 않는 한, 완전히 다 열려있는데 모듈이라는 개념이 와서 public 이라도 모든 걸 가져올 수 없게 되었다. 한마디로 public 개념 축소되었다. 원하는 기능이 있을 때, 오픈소스의 경 소스를 다 볼 수 있었다. 근데 그 기능이 Hide된 API 라고 하더라도, 그럴 경우 그 시그너쳐만 따다가, 리플렉션으로 동적 호출을 합니다. 아예 그런것들이 JVM 단에서 막힌다. 그래서 Reflection도 안되게 강력하게 막을 수 있게 되었다.

  5. 동일 패키지는 중복할 수 없음 (Split pakages) 순환참조가 없어야하는 제약과 함께, A와 B라는 모듈에서 동일한 패키지명을 가질 수 없는 제약이 생겼다. 클래스 이름만 같지 않으면 되었는데, 패키지는 완벽하게 modules의 하위가 되버림. 예전에는 전체에서 어떤 패키지를 쓰는지 자유로웠다면, 모듈 하위에서 패키지가 들어가므로, 중복되는 이름을 사용할 수 없게 되었다.

  6. JVM 시작시 필요한 모든 클래스를 확인 (Module Resolution) JVM 이 실행할때 모든 클래스를 확인합니다. 예전에는 컴파일에서는 확인하지 않고 런타임되었을때 에러났을 부분들을 예방하기 위해서 Module Resolution이라는 모든 클래스를 확인하는 절차가 생겼다.

  7. Custom JDK 만들 수 있음 (JLink)

정상적으로 지원되는 IDE IntelliJ IDEA (2017.9) 이클립스 Photom (2018.6) : 아직도 불안정함. ETC. Netbeans 9.0 RC1 (2018.7) 은 아직도 동작못함.(정식버젼아님.)
표준 그레들 방식으로 한다면 아직 IntelliJ 형태로 진행하는게 좋다.