OSGi, Java 모듈성 및 Jigsaw


95

그래서 어제 아침에 나는 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 지옥 물건에 무게를 둘 수있는 모든 사람에게 감사합니다!)


음, Java 9는 어제 Jigsaw와 함께 여기에 있습니다. 니스 읽기 : 상위 10 직소 및 Java 9 오해 정체를 폭로
데이비드 Tonhofer

답변:


100

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

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

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

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

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

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

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


이것도 당신인가요? slideshare.net/mfrancis/… 거의 동일한 내용입니다.
Jin Kwon

JBoss 모듈도 있습니다 : docs.jboss.org/author/display/MODULES/Introduction Ceylon (ceylonlang.org)에서도 사용됩니다. Ceylon 사용자 포럼에서 다음 스레드를 참조하세요. groups.google.com/forum/?hl=de#!topic/ceylon-users/RmDskLDNkug
OlliP

최종 진술 : "모듈 형 애플리케이션 개발에 진지하게 관심이 있다면 OSGi는 마을에서 유일한 게임"이 여전히 유효합니까?
Adam Arold 2015

1
@AdamArold 그렇게 믿습니다. Jigsaw는 아직 출시 된 Java 버전에는 존재하지 않습니다. JSR 376 (Java Platform Module System)은 아직 전문가 그룹을 구성하고 있으며 아직 초안을 작성하지도 않았습니다. Java 9는 1 년 이상 예정되어 있지 않으며 릴리스 된 경우에도 모듈성이 보장되지 않습니다 (Java 7에서 다음 Java 8에서 미끄러 져 쉽게 다시 미끄러질 수 있음). 마지막으로 JSR376에 대한 공개 된 요구 사항에는 OSGi interop이 필요 하다고 명시되어 있습니다. 따라서 OSGi를 채택하는 것은 여전히 ​​안전한 선택이며 오늘날 유일한 실용적인 선택입니다.
Neil Bartlett

2
@AdamArold 좋아요 그건 약간 다른 질문입니다! OSGi는 마이크로 서비스 아키텍처라고 말할 수 있지만, 무슨 말을하는지 알고 있습니다. 나에게 모든 서비스를 프로세스로 모델링한다는 생각은 관리 및 보안 및 통신 오버 헤드 측면에서 훨씬 더 복잡한 문제입니다. OSGi는 더 간단하고 빠릅니다. 하지만 OSGi 원격 서비스를 사용하여 프로세스 장벽 안팎으로 서비스를 전환하는 것은 매우 쉽기 때문에 마이크로 서비스를위한 구현 기술을위한 좋은 선택이라고 생각합니다.
Neil Bartlett

21

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

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

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

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

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


네, 저는 Sun과 OSGi Alliance 사이에 많은 '나쁜 피'가 있다고 생각했습니다. 하지만 오라클이 모든 것을 통제 할 수 없게 할 것이라고는 상상할 수 없습니다. 이 JAR 지옥을 조만간 진정으로 해결할 계획이 없다고 정말로 말하고 있습니까? 그것은 내 마음을 날려 버린다!
IAmYourFaja 2011 년

6
@Mara 나쁜 피가 있다고 말하는 것은 정말 공평하지 않습니다. 결국 Sun은 약 12 ​​년 전에 OSGi (JSR 8)의 공동 제작자 중 한 명이었습니다. 썬은 또한 오라클이 인수되기 약 1 년 전에 OSGi Alliance에 정회원으로 재가입했습니다. 그들은 또한 Oracle 이전의 OSGi를 기반으로 많은 소프트웨어를 개발했습니다. 가장 확실한 예는 Glassfish입니다. 그러나 Sun / Oracle과 OSGi의 특정 개인간에 마찰이 있다고 말하는 것은 타당합니다.
Neil Bartlett

15

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

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

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

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

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.