OSGi, Java 모듈러 및 직소

OSGi, Java 모듈러 및 직소

어제 아침까지 OSGi가 무엇인지 전혀 몰랐습니다.OSGi는 몇 번이고 떠오르는 유행어였기 때문에, 마침내 다시 연습할 시간을 마련했습니다.

사실 꽤 멋진 내용인 것 같기 때문에 먼저 (공고를 위해) 저는 OSGi를 반대하는 것도 아니고 OSGi를 때리는 것도 아닙니다.

결국, OSGi는 Java Modularity에서 JSR 277을 어드레싱한 것으로 보입니다.JSR 277은 JSR에 대한 단점이 있음을 인식했습니다.JAR특정 코너 케이스에서 네임스페이스 확인 및 클래스 로딩 문제를 일으킬 수 있는 파일 사양입니다.OSGi는 그 밖에도 많은 훌륭한 기능을 갖추고 있지만, 제가 확인한 바로는 이것이 가장 큰 매력입니다(혹은 그 중 하나).

상당히 새로운 Java EE 개발자로서 2011년 현재 Java 7 시대에 살고 있다는 것, 그리고 이러한 클래스 로딩 문제가 여전히 존재한다는 것, 특히 하나의 애플리케이션 서버에 수백 개의 JAR이 있을 수 있는 엔터프라이즈 환경에서 많은 JAR이 차이에 따라 달라질 수 있습니다.(다소) 동시에 실행되고 있는 버전을 대여할 수 있습니다.

질문입니다.

OSGi에 관심이 있는 만큼, 그리고 OSGi에 대해 배우기 시작하고 싶은 만큼, 프로젝트에 도움이 될 수 있는지 확인하고 싶은 마음이 굴뚝같지만, 적어도 지금은 그렇게 큰 것을 배울 시간이 없습니다.

그렇다면 OSGi 이외의 개발자는 이러한 문제가 발생했을 때 어떻게 해야 할까요?현재 어떤 Java(Oracle/Sun/JCP) 솔루션이 존재합니까?J7에서 직쏘가 잘린 이유는?Jigsaw가 내년에 J8에 구현될 커뮤니티는 얼마나 확실합니까?아직 Java 플랫폼의 일부가 아닌데 Jigsaw를 프로젝트에 사용할 수 있습니까?

내가 여기서 묻고 싶은 것은 패닉, 음모, 그리고 얼굴 종려의 조합인 것 같다.OSGi가 무엇인지 이제야 알게 되었지만, Jigsaw와 같은 것이 어떻게 결실을 맺는데 20년 이상이 걸렸는지, 그리고 출시에서 어떻게 캔을 만들 수 있었는지 이해할 수 없습니다.그냥 기본인 것 같아.

또한 개발자로서 SANS OSGi 솔루션이 무엇인지 궁금하기도 합니다.

또, 주의:이 질문이 "순수한 프로그래밍" 유형의 질문이 아니라는 것을 알지만, 여러분 중 일부는 기분이 나빠지기 전에, 저는 (공개를 위해) 이 질문을 일부러 SO에 올렸다는 것을 다시 한 번복합니다.왜냐하면 저는 동료 SO들에 대한 최고의 존경심밖에 없기 때문입니다.또, 매일 이 근처에 숨어 있는 「IT의 신」으로부터 아키텍쳐 레벨의 해답을 찾고 있습니다.

단, SO 질문을 코드 세그먼트로 뒷받침해야 한다고 주장하는 고객에게는 다음과 같습니다.

int x = 9;

(이 OSGi/Jigsaw/classloader/네임스페이스/J에 참여해주신 모든 분들께 감사드립니다.AR 지옥 같은 것!)

먼저 Jigsaw의 주요 사용 사례는 JRE 자체를 모듈화하는 것입니다.부차적인 목표로서 다른 자바 라이브러리와 응용 프로그램에서 사용할 수 있는 모듈 시스템을 제공할 것입니다.

Jigsaw와 같은 것은 JRE에만 필요할 수 있지만, 다른 Java 라이브러리나 앱에서 사용할 경우 해결할 수 있는 문제보다 훨씬 더 많은 문제를 야기할 수 있다는 것이 제 의견입니다.

JRE는 매우 어렵고 특별한 경우이다.그것은 12년이 넘었고 의존성 주기와 무의미한 의존성으로 가득 찬 끔찍한 난장판이다.동시에 약 900만 명의 개발자와 수십억 대의 시스템이 사용하고 있습니다.따라서 리팩터링으로 인해 변경이 중단될 경우 JRE를 리팩터링할 수 없습니다.

OSGi는 모듈러형 소프트웨어 작성을 지원하는 모듈 시스템입니다.기존 비모듈형 코드베이스 위에 모듈형을 단순히 뿌릴 수는 없습니다.비모듈러 코드 베이스를 모듈러 코드 베이스로 만들려면 클래스를 올바른 패키지로 이동하거나 직접 인스턴스화를 대체하거나 분리된 서비스를 사용하는 등의 리팩터링이 불가피합니다.

따라서 OSGi를 JRE 코드베이스에 직접 적용하는 것은 어렵지만, JRE의 컷다운 버전을 제공하기 위해 JRE를 별도의 조각 또는 "모듈"로 분할해야 합니다.

따라서 JIGsaw는 JRE 코드를 분할하면서 존속시키기 위한 일종의 "극단적 조치"라고 생각합니다.코드의 모듈화에는 도움이 되지 않으며, 실제로 코드의 라이브러리나 애플리케이션을 진화시키는 데 필요한 유지보수가 증가할 것으로 확신합니다.

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

간단하지만, 현재 Java에서 실제 컴포넌트 기반 개발을 하고 싶다면 OSGi가 이 동네에서 유일한 게임입니다.

Jigsaw는 JDK에서 할 수 있는 일과 SUN과 OSGi의 과거 나쁜 관계를 절충한 것이라고 생각합니다.Java 8과 함께 배송될 수도 있지만, 좀 더 지켜봐야 합니다.

일반적인 엔터프라이즈 환경에서 작업하고 있는 경우 OSGi는 만병통치약이 아닙니다.또한 많은 유명한 라이브러리(Hibernate)가 OSGi 내에서 유효하지 않은 클래스 가시성에 대해 가정하고 있기 때문에 클래스 로딩의 구조를 이해할 필요가 있습니다.

OSGi를 좋아하지만 기존 시스템에 맞게 개조할 생각은 없습니다.그린필드 개발의 장점도 따져보고 싶습니다.OSGi의 생활을 심플하게 하는 Apache 또는 Eclipse 제품을 직접 보는 것이 아니라 추천합니다.

OSGi를 사용하지 않는 경우, 같은 라이브러리의 다른 버전에 의존하는 시스템을 생각해 낸 경우, 운이 나쁠 수 있습니다.여러 버전의 라이브러리가 필요한 것은 아키텍처의 '냄새'라고 생각되지만, 문제를 회피하는 것 밖에 할 수 없습니다.

현 상황을 설명하기 위해 "코너 케이스"라는 문구를 사용하는 것이 마음에 듭니다.

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

어쨌든 저는 수년 전부터 코드 작성을 지원하는 도구와 기술에 관심이 있었습니다. 코드 작성은 더 깨끗하고, 분리되고, 일관성 있고, 유지보수가 더 용이합니다.테스트 기반 설계와 Junit의 조합입니다.

코드 베이스의 상당 부분을 OSGi로 이행하는 데 몇 개월이 걸렸지만, 이 점에 있어서 OSGi는 훨씬 더 좋은 도구라고 말할 수 있습니다.이것이 OSGi로 이행하는 충분한 이유입니다.결국 그것은 당신에게 많은 돈을 절약시켜 줄 것이다.

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

언급URL : https://stackoverflow.com/questions/7498540/osgi-java-modularity-and-jigsaw