1.1.1 자바 모듈화 제약.

1.1.1 Java’s modularity limitations

Java는 OOP로서 모듈화 관점을 가지고 있지만, 의도된 것은 아니었다.
그리고 보다 나은 모듈화 지원이 필요한 것을 알고 힘들게 모듈화와 싸워온 개발자들을 통해서  Java의 성공이 꽃피울수 있었다.

Low-Level code visibility control

• Access modifier라는 (접근수식어) - public, protected, private, default 와 package로 논리적인 시스템분할은 아니지만, 코드를 구분짓기 위한 수단으로 사용한다. 하지만 왜! 이것이 제약인가? 확장을 할때 언젠가는 non-public 라이브러리를 맞닥뜨리게 되기 때문에 내부 리소스를 수정, 확장할 수 없는 시점이 반드시 생긴다. 

요것만 지켜보자

1. NonPublic-API 노출을 피하기 위해 관련없는 클래스들을 한 패키지안에 넣으면, 논리적인 구조가 취약해 질 수 있다. 
2. 다른 패키지에서도 접근가능하도록 nonpublic APIs를 노출하는 여러개로 분리된 패키지를 사용함으로서 논리구조를 유지하자

Error-prone "class path" concept

• 두개의 jar의 각각 log1.0과 log1.1이라는 library를 가지고 있는 프로젝트라고 생각해보자. "NoSuchMethodError" 가 발생할 것이다. 자바 플랫폼은 코드버젼, 의존성 라이브러리 그리고 구성요소의 버전을 고려하지 않는다. 

LIMITED DEPLOYMENT AND MANAGEMENT SUPPORT

• 다이나믹 플러그인 지원을 위한 유일한 방법은 class-loader를 사용하는 것이다. 하지만 low-level이고 에러 발생율이 높다. 잘 정의된 자바 모듈화 레이어는 명확한 코드의 고레벨 추상화로 문제를 해결할 수 있을 것이다. 

아직도 OSGi에 대한 확인이 안생긴다면, 언제 우릴 도와줄 것인가 살펴보겠다. 

• ClassNotFoundExceptions - 어플리케이션 실행할 때 부끄럽게 해당 에러가 난다면, 코드실행전에 의존성에 부합되는지 확인
• Execution-time시 라이브러리 버젼확인
• 공유된 모듈내 Type 부합성 확인
• 논리적으로 비독립적인 jar파일을 패키징하고, 그중에서 필요한 jar들만 배포할 수 있다. OSGi의 목적과 크게 부합된다. 
• 어플리케이션을 위한 확장 메커니즘 정의

아.. 모든 케이스가 포함되어 있는건 아니지만, 어떻게 프로젝트에 적용되는지 OSGi를 살펴보며 느껴봐야겠습니다. 여전히 감이 안오는, OSGi!