수요일, 9월 27, 2017

[Java] Java 9의 모듈 시스템에 대한 단상

우여곡절 끝에 자바 9에 jigsaw 즉, Java Platform Module System이 포함되어 출시되었다.

오래동안 사용되던 ClassLoader 기반의 OSGi와 다르게 Java Platform Module System은 JDK 내부적으로 module을 지원한다.

이를 위해 java.lang.ClassLoader 등의 클래스가 module 관련 선언에 있는 내용대로 접근성이 허용되는지를 내부적으로 체크하도록 JDK 코드가 수정되었다.

그 외에도 모듈에 선언된 것 외에는 타 모듈의 클래스를 액세스할 수가 없는데 Class.forName(...)을 통해 Class 객체는 구할 수 있지만 newInstance 등을 통해 인스턴스 객체를 만들려고 시도하는 순간 에러가 나게 된다.

이 점은 기존 코드와 심각하게 비호환되게 하는데 이를 완화하기 위해 java.util.ServiceLoader를 통해서 객체를 만들 수 있도록 하고 있다. (이게 가능하려면 해당 제공 모듈에서 provides를 선언해야만 한다.)

기존의 자바는 클래스로더의 자유도를 기반으로 모듈화를 저해하는 일들을 많이 하는 일들을 많이 해왔다. 특히 프레임웍들은 그러한 형태를 권장해왔다.
모듈에 대한 제어가 없고 이를 통해 더 많은 기능을 제공할 수 있으니까.
자바 9 이후부터는 이러한 모듈화를 저해하는 것들이 많이 줄어들 것 같다.

아니, 새로 작성되는 프로그램들은 자바 9과 쉽게 호환할 수 있도록 자바 코드를 모듈화하여 분리시키는 설계를 항상 선행하여야 할 것 같다.

OSGi는 표준 Java API를 기반으로 사용하므로 특별히 JPMS 기준의 타 모듈에 액세스하지 않는 한 잘 동작할 것이다.
현재로서는 JPMS는 같은 모듈의 멀티 버전을 지원하지 않는다. 그리고 동적 업데이트나 동적 unload도 지원하지 않는다.
엔터프라이즈 환경에서 동적 업데이트/unload는 여러 가지 상황에서 필요하다. 이 글에서 언급한 것처럼 IoT만 필요한 것은 아니다.
물론 클라우드 환경의 blue-green deployment가 이러한 동적 update/unload의 필요성을 줄여줄 수는 있다.
어쨌든 당분간 이 dynamic behavior는 여전히 커스텀 클래스로더나 클래스로더 기반 기술인 OSGi를 사용할 수밖에 없다.


참고자료
  • Java 9, OSGi and the Future of Modularity (Part 1)
  • The Top 10 Jigsaw and Java 9 Misconceptions Debunked
  • Getting Started with the Modules Project
  • Project Jigsaw: Complete!
    (참고) JDK 소스 코드 중 모듈 관련 변경 사항들


    • JSR 277 API, implementation, and configuration files
      • src/share/classes/java/module/*
      • src/share/classes/sun/module/*
      • src/share/lib/module/*
    • JSR 294 reflective API
      • src/share/classes/java/lang/reflect/Superpackage.java
      • src/share/classes/java/lang/Class.java
      • src/share/classes/java/lang/ClassLoader.java
      • src/share/classes/java/lang/annotation/ElementType.java
    • JSR 269 updates
      • src/share/classes/javax/lang/model/*
    • java launcher
      • src/share/bin/java.c

    댓글 없음: