OSGi, Java 모듈성 및 Jigsaw

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은 그러한 조합이었습니다.

After having spent a couple of months moving a substantial part of our code base to OSGi, I would say that OSGi is an even better tool in this regard. And that is really a sufficient reason to move to OSGi. In the long run it will save you a lot of money.

And, as a bonus, it'll give you a chance to do a lot of cool stuff. Imagine, during a demo, seamlessly upgrading the authentication module, without traffic loss, to support OAuth ... it's suddenly a joy again to create stuff!

참고URL : https://stackoverflow.com/questions/7498540/osgi-java-modularity-and-jigsaw