[java] OSGi, Java 모듈성 및 Jigsaw

그래서 어제 아침에 나는 OSGi가 무엇인지에 대한 단서가 없었습니다. OSGi 는 몇 번이고 계속해서 나타나는 유행어 였기 때문에 마침내 시간을내어 문제를 해결했습니다.

사실 꽤 멋진 것 같기 때문에 나는 (기록을 위해) 어떤 점에서든 안티 OSGi가 아니며 이것은 “OSGi-bashing”질문도 아니라고 말하면서 시작하고 싶습니다.

결국 OSGi는 본질적 으로 Java Modularity에서 JSR 277 을 해결 한 것으로 보입니다 .JAR 특정 코너 케이스에서 네임 스페이스 해결 및 클래스 로딩 문제로 이어질 수 파일 사양의 . OSGi는 또한 다른 많은 멋진 기능을 수행하지만 제가 확인할 수있는 점에서 이것이 가장 큰 장점입니다 (또는 그중 하나).

나에게는 꽤 새로운 (현재 몇 년) Java EE 개발자로서 우리가 2011 년에 있고 현재 Java 7 시대에 살고 있으며 이러한 클래스 로딩 문제가 여전히 존재한다는 사실은 정말 놀랍습니다. 특히 하나의 앱 서버에 수백 개의 JAR이있을 수있는 엔터프라이즈 환경에서 대부분은 서로 다른 버전에 따라 다르며 모두 동시에 실행됩니다.

내 질문:

내가 OSGi에 관심이있는만큼, 내 프로젝트에 유용 할 수있는 위치 / 여부를 확인하기 위해 OSGi에 대해 배우고 싶은만큼, 앉아서 그렇게 큰 것을 배울 시간이 없습니다. 적어도 지금.

그렇다면 이러한 문제가 발생할 때 OSGi가 아닌 개발자는 무엇을해야합니까? 무엇 자바 있는 경우 (오라클 / 일 / JCP) 솔루션은 현재 존재 하는가? J7에서 Jigsaw를 잘라낸 이유는 무엇입니까? Jigsaw가 내년 J8에서 구현 될 커뮤니티는 얼마나 확실합니까? 아직 Java 플랫폼의 일부가 아니지만 프로젝트에 Jigsaw를 사용할 수 있습니까?

내가 여기서 묻는 것은 공황, 음모 및 안면 손바닥의 조합입니다. 이제 마침내 OSGi가 무엇인지 이해 했으므로 Jigsaw와 같은 것이 어떻게 결실을 맺기까지 20 년 이상 걸 렸는지, 그리고 어떻게 그것이 릴리스에서 통조림 될 수 있었는지 “얻지”못합니다. 근본적인 것 같습니다.

그리고 개발자로서 저는 OSGi가 아닌 제 솔루션이 무엇인지 궁금합니다.

또한 참고 :이 질문 이 ” 순수한 프로그래밍 “유형의 질문 이 아니라는 것을 알고 있지만 일부 사용자가 코를 구부리기 전에 의도적으로이 질문을 올렸다고 (다시 기록을 위해) 말하고 싶었습니다. 그래서. 그 이유는 동료 SO에 대한 존경심 밖에없고 매일 여기에 숨어있는 “IT의 신들”로부터 아키텍처 수준의 답변을 찾고 있기 때문입니다.

그러나 SO 질문이 일부 코드 세그먼트로 뒷받침되어야 한다고 절대적으로 주장 하는 사람들을 위해 :

int x = 9;

(이 OSGi / Jigsaw / classloader / namespace / JAR 지옥 물건에 무게를 둘 수있는 모든 사람에게 감사합니다!)



답변

먼저 Jigsaw의 주요 사용 사례는 JRE 자체를 모듈화하는 것임을 이해합니다. 두 번째 목표로 다른 Java 라이브러리 및 애플리케이션에서 사용할 수있는 모듈 시스템을 제공합니다.

내 입장은 Jigsaw 와 같은 것이 JRE에만 필요할 수 있지만 다른 Java 라이브러리 나 앱에서 사용하는 경우 해결한다고 주장하는 것보다 훨씬 더 많은 문제를 일으킬 것이라는 것입니다.

JRE는 매우 어렵고 특별한 경우입니다. 12 년이 넘었고 의존성주기와 무의미한 의존성으로 가득 찬 무서운 엉망입니다. 동시에 대략적으로 사용됩니다 9 백만 명의 개발자와 수십억 개의 실행중인 시스템에서 사용됩니다. 따라서 리팩토링이 주요 변경 사항을 생성하는 경우 JRE를 리팩토링 할 수 없습니다.

OSGi는 모듈 식 소프트웨어를 만들 도록 도와주는 (또는 강제 로) 모듈 시스템입니다 . 모듈식이 아닌 기존 코드베이스 위에 단순히 모듈성을 뿌릴 수는 없습니다. 비 모듈 형 코드베이스를 모듈 형 코드베이스로 만들려면 필연적으로 몇 가지 리팩토링이 필요합니다. 클래스를 올바른 패키지로 이동하고, 직접 인스턴스화를 분리 된 서비스를 사용하여 대체하는 등의 작업이 필요합니다.

이로 인해 OSGi를 JRE 코드베이스에 직접 적용하기가 어렵지만 JRE의 컷 다운 버전을 전달할 수 있도록 JRE를 별도의 조각 또는 “모듈”로 분할해야합니다.

따라서 저는 Jigsaw를 JRE 코드를 분할하는 동안 유지하기 위한 일종의 ” 극단적 인 조치 “라고 생각합니다. 그렇습니다코드가 모듈화되는 데 도움 않으며 ,이를 사용하는 라이브러리 나 응용 프로그램을 발전시키는 데 필요한 유지 관리를 실제로 증가시킬 것이라고 확신합니다.

마지막으로 OSGi는 존재하지만 Jigsaw는 아직 존재하지 않으며 존재하지 않을 수도 있습니다. OSGi 커뮤니티는 모듈 식 애플리케이션 개발에 12 년의 경험을 가지고 있습니다. 모듈 식 응용 프로그램 개발에 진지하게 관심이 있다면 OSGi가 마을에서 유일한 게임입니다.


답변

간단합니다. 오늘날 Java로 실제 컴포넌트 기반 개발을하고 싶다면 OSGi가 유일한 게임입니다.

제 생각에 Jigsaw는 JDK에서 할 수있는 일과 SUN과 OSGi 녀석 사이의 이전의 나쁜 관계의 타협의 조합입니다. Java 8과 함께 제공 될 수도 있지만 기다려야합니다.

OSGi는 일반적인 엔터프라이즈 환경에서 작업하는 경우 만병 통치약이 아니며 더 이상 유효하지 않은 클래스 가시성에 대한 가정을 만든 잘 알려진 여러 라이브러리 (Hibernate)로 클래스 로딩이 작동하는 방식에 익숙해 져야합니다. OSGi 내부.

저는 OSGi를 좋아하지만 기존 시스템으로 개조하려고하지 않습니다. 또한 그린 필드 개발 측면에서 장단점을 따져 볼 것입니다. OSGi의 삶을 단순화하는 Apache 또는 Eclipse 제품을 살펴보고 모든 작업을 직접 수행하지 않는 것이 좋습니다.

OSGi를 사용하지 않는 경우 동일한 라이브러리의 서로 다른 버전에 대한 종속성이있는 시스템을 생각해 낸 경우 운이 좋지 않습니다. 여러 버전의 도서관은 나에게 건축 ‘냄새’처럼 보인다.


답변

현재 상황을 설명하기 위해 “코너 케이스”라는 문구를 사용하는 것이 좋습니다.

특정 코너 케이스에서 네임 스페이스 확인 및 클래스 로딩 문제로 이어질 수있는 JAR 파일 사양의 단점이 있습니다.

여하튼 수년 동안 저는 코드 생성을 지원하는 도구와 기술에 관심을 가져 왔으며, 코드 없이는 아마도 결과물이 없었을 것보다 더 깨끗하고, 더 분리되고, 더 일관되고, 유지 관리가 더 낫습니다. Test Driven Design과 Junit은 그러한 조합이었습니다.

코드베이스의 상당 부분을 OSGi로 옮기는 데 몇 달을 보낸 후 OSGi가 이와 관련하여 훨씬 더 나은 도구라고 말할 수 있습니다. 이것이 OSGi로 옮겨야 할 충분한 이유입니다. 장기적으로는 많은 돈을 절약 할 수 있습니다.

그리고 보너스로 멋진 일을 많이 할 수있는 기회를 줄 것입니다. 데모 중에 OAuth를 지원하기 위해 트래픽 손실없이 인증 모듈을 원활하게 업그레이드한다고 상상해보십시오. 무언가를 만드는 것이 갑자기 다시 즐거워졌습니다!


답변