자, 자바커들아, 게이물 시작하지. Porject Jigsaw 통과.

지난 6월 27일, 내 예상과는 달리 직쏘가 통과되어, JDK 9에 당당히 포함할 수 있게 되었다.
직쏘 반대하느라 A4용지 30여페이지를 날린 레드헷만 끝가지 반대 입장을 고수했고, 나머지는 오라클 영업력에 뻑이 갔는지 모두 찬성했다고 한다.

자바 개발자들에게 여태까지 버텨왔던 하위 호환성. 이제 개나 주게 생겼다.
하지만 그건 문제가 아니다. 왠만한 언어 스펙도 이런 고통을 안고 업그레이드 했다.
가장 대표적인 게 Python인데, 유니코드 지원이 강화한 대신 유용(?)한 API를 삭제했다고 원성을 높여
아직도 2.7을 쓰는 프로젝트와 제품이 즐비한 상황이다.
자바도 뭐 이미 그꼴 날 건 뻔할 뻔자지만, 당분간 자바개발자들은 임베디드나 모바일 계통이 아닌 이상은
계속 Java 8을 보고 있을 것으로 보인다.

직쏘를.araboja

정식 명칭으로 “자바 플랫폼 모듈 제계(Java Platform Modulule System)”라는 이름을 가지게 되었으며, JSR-277 번호를 가지고
2011년 프로젝트를 시작하여 원래 자바 7에 추가할 예정이었다. 하지만 구조적 문제가 해결되지 않아 자바 8에서도 보류하는 아픔을 겪었다.
직쏘에 기대를 거는 이유는 하나다. 여태까지 고질적인 자바의 문제를 해결할 핵심 기능을 가지고 있었기 때문이었다.
자바의 고질적인 원흉인 캡슐화 문제는 뭐 이미 옛날부터 제기해왔지만, 당시 닫혀 있었던 구조상 해결할 수 없어 그저 수용만 했던 개발자들이 대부분이었다.
하지만 자바의 오픈 이후 이를 개선할 수 있는 움직임이 생겼으며, 이 중 하나가 바로 직쏘다.

대부분의 자바 개발자는 이런 반응을 보일 것이다.

  • 크로스 플랫폼으로 잘만 돌아가고 있는데 왜?
  • 메모리 문제? 그저 사양만 늘려주면 빠르고 깔끔하잖아?
  • 경량화? 경량화 할 디바이스가 어딨다고…

근데, 리조트 프로젝트 했었는데, POS를 자바로 개발하려는 시도가 있었다. 하지만 낮은 사양에 높은 처리능력을 요구하기에 자바는 맞지 않았고 닷넷으로 갔다.
관련 프로젝트를 해본 사람이라면 안다. 왜 자바를 POS에 접목시키는 게 쉽지 않았는지. 웹 말고.
하지만 모듈 시스템을 탑재하면 더 가벼워진 이미지로 적은 메모리로도 POS 시스템을 돌릴 수 있다고 생각해보자.
속 시원하지 않겠는가?

이 중 큰 원인이 바로 자바의 상속 시스템인데. rt.jar 파일 아는가? 자바에 모든 API가 있는 라이브러리다.
그만큼 무겁다. 더럽게 무겁다. 모든 자바 프로그램은 절대 이 라이브러리를 거역할 수가 없다.
닷넷의 경우 얘기가 틀린데, 닷넷은 GAC이라는 레지스트리급 쓰레기가 있지만, 대신 모듈이 분리되어 필요한 것만 갖다가 쓸 수 있다.
그래서 시작 속도 뿐 만 아니라 성능 면에서도 유리하다. 예를 들어,
자바는 웹을 아예 안 써도 웹 API를 가지고 가야 한다. 하지만 닷넷은 안쓰면 안가져가도 된다. 이 차이인 것이다.
그러나 직쏘와 함께하면 자바도 웹 안쓰면 웹 안들고 가도 동작하도록 할 수 있다. 말 다했다.

한마디로 자바의 입지를 한 층을 넘어 더 다양한 분야에 뛰어들게 해주는 샘물같은 존재다. 그걸 모르는 자바 개발자들은 지금에도 만족하며 잘 개발하고 있겠지만.
게다가 이런 현상을 유지하는 데 한몫한 업체가 바로 의외에 있었는데, 구글이다. 그렇다. 안드로이드다.
하지만 안드로이드는 개발 시 자바를 언어로 쓸 뿐, 오라클의 JVM을 쓰지 않고 아예 독립적으로 개발한 JVM으로 돌리고 있다.
게다가 딸려나오는 라이브러리도 많다. 그리고 이들 모두를 상속받아야 안드앱 개발이 가능하다.
따라서 모듈 시스템에 수혜를 받기엔 가상머신부터 틀려서 일단 패스하고.

이클립스 실행하는 데 느리다고 생각하는 사람 많을 거다. 더럽게 무겁기도 유명한 비주얼 스튜디오보다도 느리다. 인텔리제이도 시작 속도 예외는 없다.
그걸 빠르게 해 주겠다는데. 왜?

직쏘가 어떻게 구현되고 돌아가는지는 얘기가 너무 길어지니 직접 검색해서 보도록 하자. 한글 블로그에도 많이 소개되어 있다.

직쏘의.problem

이렇게 자바에게 날개를 달아주는 녀석이지만, 많은 자바 개발자들이 우려하고 있는 점이 있다면 바로 하위 호환성을 꼭 빼놓을 수 없다.
자바 1.5부터 추가된 제네릭의 경우는 객체 소멸(Type Erasure)을 통해 컴파일 때에만 제네릭을 검사하고 런타임 상는 제네릭 없이 돌아가도록 구현하였다.
그래서 닷넷과는 달리 Map 클래스와 Map<Key, Value> 클래스. 제네릭이 있던 없던 같은 클래스로 취급하는 것이다. 닷넷은 다른 클래스로 취급한다.
결국 1.4 때 제네릭 없었던 클래스처럼 써도 무방할 정도인 것이고, 성능상 이점이 없으며, 그저 자바의 방향인 Strong Typed에 부합될 뿐이었다.
그리고 자바 1.8부터 도입된 람다식의 경우 이미 익명 클래스로 충분히 소화해낼 수 있기 때문에 간소화된 것만 빼면 하위 호환성에 큰 지장은 없다는 것이다.
하지만 직쏘는 그 이전 버전에 대체할 수 있는 환경이 아예 없다. 하위 호환성을 유지하려면 직쏘를 아예 쓰지 말아야 할 정도이다.
여태까지 하위 호환성을 최대한 생각했기에 개발자 입장에서는 큰 난관이 아닐 수 없다.
만약 버전을 올리고 개발했을 때, 문제가 생기면 해당 버전에 맞게 개발하고 컴파일 하면 됐다. 하지만 직쏘는 그게 안된다. 다 버려야 한다는 것이다.
그래서 자바 API를 닷넷에 쓰게 해주는 IKVM.NET 개발자는 모듈 시스템의 복잡도 때문에 더 이상 새 자바에 대응하지 않겠다는 공식 입장을 피력할 정도.
그리고 이 불안은 현재진행형이며, 정식 버전이 나오면 1.9를 바라볼 사람이 얼마나 될 지 의문이다.

자, 자바 개발자들이여, 이제 게임을 시작하지. 직쏘.

composite / 2017년 7월 5일 / Piss Development / 0 Comments

프로젝트 직쏘는 희망이 없다?

자바 9가 올해 7월 말 즈음 출시될 가운데 안타까운 소식이 들어왔다.

바로 JCP(Java Commnity Program) 총괄 리뷰에서 프로젝트 직쏘가 많은 반대에 부딪혀 빛을 못볼 위기에 처해 있다는 것이다.
DZone – Java Zone – EC Rejects Jigsaw

직쏘 프로젝트 참여자들은 30일 내에 보완 후 다시 리뷰를 진행해야 하는데,
다음 리뷰에서 실패하면 직쏘는 자바 9에서도 볼 수 없는 시스템이 될 것이다.

프로젝트 직쏘는 익히 알다시피 하여 짤막하게 소개한다. SI/SM 개발자들은 관심없이 1.6 이하 버전이나 쳐 만지겠지만.
현재 자바는 JVM 내에 돌아가는데, JVM이 자바에 있는 핵심 라이브러리 외에도 사용자가 추가한 라이브러리 모두 안고 가기 때문에
성능 문제는 여러 방면에서 제기된 문제가 있었으며, 이로 인해 특히 임베디드 장비에서 자바를 꺼려하는 이유이기도 하다.
그래서 안드로이드 자바는 아예 달빅 등으로 자바를 재구성 해서 안드로이드 전용 자바 환경을 만들었던 이유이기도 하다.
물론 안드도 성능 이슈는 피할 수 없긴 매한가지지만.

어쨌든, 이걸 해결하고자 모듈 시스템으로 필요한 라이브러만 쓰고, 쓰는 곳으로만 최적화하고, 이식 가능(Portable)한 프로그램을 만들기 위해
꾸려진 프로젝트가 JSR 376q번 프로젝트 직쏘다.

하지만 프로젝트 직쏘는 당연하겠지만 많은 반대에 부딪혔다. 특히 이번 반대의 가장 주역이 바로 상업용 리눅스로 유명한 대기업 “레드햇”인데,
프로젝트 직쏘에 대한 문제점을 34페이지를 썼다.

DZone에서 언급한 주요 내용은 아래와 같다.

The patterns introduced within Jigsaw are (in some cases) going to be extremely difficult to fix even in a later release, and will create backwards- and forwards-compatibility problems that will be very difficult to unwind

직쏘에서 제시한 패턴은 이후 자바 출시를 할 때 여러 면에서 거대한 장벽을 유발한다. 그리고 상위, 하위 호환성 측면에서도 난관이 많을 것으로 보인다.

Due to lack of one to one mapping of use cases (or sufficient interoperability capabilities) and other restrictions, we are concerned that there will likely be two worlds of Java software development: the Jigsaw world, and the “everything else” world (Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)

일대일 연계에 대한 문제와 여러 제한 사항으로 인해 우린 자바 개발자들이 직쏘 세계와 현재 자바 세계(Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)를 두가지로 나눠 개발하는 광경을 볼 지도 모른다.

그렇다. 레드햇은 자바의 기본적인 목표인 “하나의 코드를 여러 플랫폼으로”에서 거리가 먼 직쏘에 거리를 둔 것이다.
이외 IBM, SAP 등 여러 거대 개발기업도 반대 의사를 표시했으며, 세계에서 가장 큰 자바 커뮤니티인 런던 자바 커뮤니티는 강한 반대 의사를 표시했다고 한다.
우리가 많이 쓰는 개발 툴 제작사 이클립스 재단도 반대 의사를 표시했다.

물론 찬성도 있다. 자바를 주도하는 오라클, V2COM, 후지쯔 등인데,
후찌즈는 “EC 회원들이 직쏘에 많은 집중을 하는 만큼 다음 투표에서 해결되길 바란다.” 라며 찬성 의사를 표시했다. 그렇다. 실질적인 반대 의사인 것인데 찬성한 것이다.
SouJava 라는 업체는 처음에 찬성을 하다 반대 의사를 표시했는데. 역시 사용자 접근성 결여를 이유로 반대 표시를 한 것이다.

결국 접근성 문제와 여러 제한 사항, 호환성 문제를 이유로 많은 커뮤니티와 업체에서 반발한 것이다.
우려한 대로 말이다.

닷넷 진영에서는 프로젝트 직쏘 때문에 다 갈아엎어야 하는 iKVM.NET 개발을 포기하기로 했고, 자바를 기반으로 한 스칼라나 코틀린에서는 대응이 안되어 있는 상황.
이렇게 준비가 되어 있지 않은데 우린 대체 무슨 희망으로 직쏘를 지지했던 것인가를 다시한 번 생각하게 한다.

내가 보건데 자바 9에서도 직쏘는 보기 힘들 것으로 보인다.
별 거 아닌 것처럼 보여도. 자바 2.0이면 모를까 자바 1.x 에 직쏘를 넣는다는 건 엄청난 변화이고, 기존 자바 개발자들이 한국 SI/SM 개발자처럼 정체된 자바 환경을 접해야 할 지도 모르기 때문이다.
직쏘를 적용하는 순간부터 하위 호환성을 포기해야 하고, 상위 호환성을 걱정해야 하며, 그리고 자바 직쏘에 대한 또다른 지식과 구조를 개발자들이 알아야 하니, 기존 개발자들에게는 큰 난관이 아니 예상할 수 있겠는가.

composite / 2017년 5월 18일 / Piss Development, Waldo Translation / 0 Comments