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

자바 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

자바 개발시 Hot Swapping 종류

Java Server Hotspot

  • JDK 설치하면 기본적으로 제공
  • 메소드 내용을 수정한 뒤 재시작 없이 반영
  • 그게 다임. 내용 수정 외의 수정은 모두 재시작해야 함.

jRebel

  • 상용으로 유료 솔루션
  • 자바 코드 어떻게 수정해도 재시작 없이 반영
  • Spring 플러그인에 한해 XML 설정도 재시작 없이 반영
  • 왠만한 WAS 및 환경에서 사용가능 (국내한정 JEUS는 되긴 하지만 공식 미지원)
  • 적은 코드 변경에는 아주 빠른 Reload
  • 변경 코드가 많을수록 Overhead 심각 (이건 어느 솔루션도 못피함. 이건 무조건 재시작삘.)

Spring loaded

  • 무료이며 오픈소스
  • 스프링만 적용 가능 (전자정부는 되겠지 뭐)
  • 스프링 자바 및 XML, properties 변경 시 적용
  • 스프링 외 플러그인 설정파일 변경 지원 안함.
  • 현재 톰캣만 지원. 나머지 WAS 보증불가
  • 몇몇 사용자에서 재시작이 안되는 문제가 보고되고 있음

Spring boot devtools

  • 무료이며 오픈소스
  • Spring boot만 적용 가능 (상속 때문에 일반 spring 적용 불가)
  • spring boot 및 상속 가능한 모든 자바 및 설정 파일 변경 시 적용
  • spring boot 돌아가는 어떤 WAS 상관 없이 지원 (JEUS는 모름)

닷넷커: ㅋㅋ ASP.NET (MVC 포함)은 기본 전체 홧스왑 수준인데 고생한다.
자바커: MS 종속적이고 비싸기만 하며 오픈소스 없는 놈이 말이 많어.
닷넷커: 이제 크로스플랫폼 지원하고 소스는 이미 오픈된지 오래임.
자바커: 그러던가. 어자피 한국에서는 영원히 잊혀질 기술임 ㅗ.

composite / 2016년 5월 12일 / Piss Development / 0 Comments

또다른 오픈소스 IDE: Consulo IDE

흐음… 한국에 자바 IDE 쌍벽은 아무래도 Eclipse 와 IntelliJ 일 것이다.
Netbeans 도 있긴 하지만 쓰는 사람이 드물어서…

어쨌든 간에, JetBrains 에서 .NET IDE 만든다고 한 지 2주.
근데 댓글에서 심상치 않은 IDE를 발견했다.

이름하여 Consulo IDE 이다.

Consulo는 IntelliJ IDEA Community Edition의 쉘 전신인 IDEA IDE 베이스로 만들어진 오픈소스 IDE이다.
현재 안드 공식 개발 툴인 IntelliJ IDEA 기반의 쉘 UI 프레임워크가 오픈했다라…
엉? IntelliJ에 썼던 UI가 오픈소스라고?

정말 있다. 오픈소스로. IntelliJ Community Edition

그렇다. 커뮤니티 에디션에 한해서 오픈소스로 공개하긴 했다.
게다가 Apache 2.0 라이선스다. 상업적으로 써도 문제는 물론 없다.
아니었으면 상업적으로 안드로이드 개발은 물건너 갔을테니.

어쨌든, 다시 Consulo로 돌아가자.

Consulo는 현재 C#, Javascript, Java 등을 지원하며, 모든 언어를 지원하는 하나의 IDE로 통일하겠다는 목표를 가지고 있다.
안타깝게도 안정된 버전이 아니라서 실무에 쓰기는 조금 어렵지만,
유니티 개발자들이 이 IDE를 주목하고 있다.
왜냐?
모노IDE가 좆같거든.

인텔리 기반이라 인텔리 플러그인을 지원 하기는 한다. 조금 손을 봐줘야 한다고 한다.
마이그레이션 과정을 거치는데, 아무래도 라이선스 이슈 때문이다.
불편하더라도 인텔리제이와는 분리해야 써야 하는 이유이기도 하다.

Add a plugin

JetBrains 에서 Project Rider 로 C# IDE를 꾀하고 있고.
아마 유니티 개발에서 하나의 변수로 떠오를 가능성이 큰 상황이다.
어자피 모노와 닷넷은 API가 틀리지 언어 구조와 스펙까지 틀린 건 아니니
지켜봐야 할 내용이고,

거기에 오픈소스로 강공을 펼칠 Consulo IDE에도 주목할 필요가 있다.

IDE 전쟁이 시작되는 것이다. 우오.

composite / 2016년 1월 28일 / Piss Development / 0 Comments

Javascript 파이프라인

어찌보면 나도 간과한 일일 수도 있다.
Javascript 로 열심히 삽질하다 보면 역시 콜백 늪에 안빠져본 자스 개발자는 없을 것이다.
이런 콜백 지옥을 빠져나가기 위해 여러 패턴이 도입되었고, 그 중 대표적인 게 Promise 패턴, Generator, 그리고 async/await 이다.

마침 Play.node() 라는 컨퍼런스가 이미 진행했었고, 공개된 발표자료 중 바로 한눈에 들어온 세션이 있었는데,
그게 바로 Session 3. Pipe: 콜백지옥의 또 다른 거짓 선지자 였다.

그리고 콜백 지옥을 빠져나갈 수 있다는 여러 선지자들, 그리고 세션 발표자가 이를 개선하기 위해 만든 또다른 선지자를 소개하는 시간이었다.
필자는 여기에 참여하지 못해 이 세션의 처음과 끝이 어땠는지는 잘 모르겠지만, 자스 개발자들은 뭔가 너무 차별화된 형식으로 접근하려는 시각이 눈에 띄었다.

그렇다. 너무 차별화되어 다르게 보일 수 있지만 결국 똑같은 패턴.

그게 바로 작업 흐름 관리이다. 영어로 Task flow management.
이를 관리하기 위해 보통 제공되어 사용하는 패턴이 바로 Pipeline pattern 이다.
작업 단위 간 통신을 위해 꼬리를 물고 무는 패턴.

자바스크립트는 싱글 쓰레드다. 그렇기 때문에 얻을 수 있는 이점이 있지만 이를 위해 잃은 많은 것들이 있다.
얻을 수 있는 이점이 바로 비동기 이다. 자스는 비동기에 능하다. 어떤 작업 흐름을 미꾸라지처럼 빠져 나가는 재주를 지녔다.

다른 언어에서도 이런 미꾸라지같이 작업 흐름을 마칠 수 있는 이점을 수용하려 하고 있었고, 이렇게 생겨난 것이
자바의 Future<T> 와 닷넷의 Task<T> 이다. 그리고 닷넷 4.5 에는 asyncawait 문법으로 비동기 작업 흐름 관리에 종지부를 찍을 것 같았다.
자스에서도 이런 종지부를 받아들여 ES7에 들어올 예정이긴 하지만… 언제 들어올지는 아직 모른다. 그렇기에 기대에 부응하지 못하고 오늘도 자스는 작업 흐름을 관리하고 있다.

동시성과 비동시성을 합쳐서 여러 케이스로 작업 흐름을 관리하는 업무는 의외로 많다.
하지만 많은 개발자들은 이를 동기적으로 처리하려고 한다. 왜냐, 그게 편하고 순서있고 보기도 편하기 때문에.

하지만 위 소개된 세션을 통해 이런 자스의 고충을 이해할 수밖에 없는 이유가 있다. 아니. 이해해야 할 수밖에 없다.
바로 자스는 아까 말했듯 싱글 스레드이다. 아까 말했듯이 자스는 어찌보면 너무 많은 것을 잃은 것만 같다.
쓰레드를 여러 개 사용할 수 있는 자바나 닷넷 등이 아니다 보니 쓰레드 단위로 Pipeline 을 갖는다는 것은 매우 어려운 일이다.
그래서 위 세션처럼 비동기 방식의 장점을 살려 바로 이벤트를 통해 작업 흐름을 관리하는 파이프라인을 구현한 것이다.
여기서 가장 핵심 공통점은 바로 작업 간 데이터를 주고받아야 한다. 그리고 이 때문에 구현한 것이다.
자스는 작업 흐름 관리를 위해 콜백 간에 데이터를 주고받아야 하는 일이 많다. 그렇다 보니 전통적인 방법으로는 콜백 지옥이 발생하는 것이다.

그렇다. 자스도 결국 파이프라인 패턴 써야 한다. 작업끼리 물고 물고 늘어진다. 이건 어느 언어나 업무 흐름에 피할 수 없는 숙명인 것이다.
자스는 작업을 관리하는 방식이 다를 뿐, 결국 작업은 파이프라인인 것이다. 어쩌면 동시에 해야 할 수 있고, 그리고 동시에 모두 끝나야 대기탔던 작업 해야 하고.

WE ARE THE HELLO WORLD.

참고자료

Play.node() 발표자료 http://d2.naver.com/news/2602887
자바 : 파이프 스트림과 쓰레드간 데이터 교환 http://javacan.tistory.com/entry/72
닷넷 : C# 쓰레드 이야기: 11. 이벤트(Event) http://www.hanbit.co.kr/network/view.html?bi_id=360

콜백지옥의 또 다른 거짓 선지자 관련 또다른 참고자료

Node.js Flow (part 1) – Callback Hell vs. Async vs. Highland http://blog.vullum.io/javascript-flow-callback-hell-vs-async-vs-highland/
Node.js Flow (part 2) – Fibers and Generators http://blog.vullum.io/nodejs-javascript-flow-fibers-generators/
yortus/asyncawait – Callback heaven for Node.js with async/await https://github.com/yortus/asyncawait

composite / 2016년 1월 6일 / Piss Development / 0 Comments

Cloud IDE를 통해 우리가 얻을 수 있는 프로젝트 이점들

Eclipse. 국내 자바 개발자들의 국민 IDE 도구이다.
현재 릴리즈는 MARS 이며, 나온 지 얼마 안됐다. Luna 를 쓴지 얼마 안됐는데…
하지만 아직도 꽤 프로젝트들이 Indigo 및 심지어 Galileo 버전을 쓰기도 한다. ㄷㄷㄷ
그리고 어떤 이들은 디스크 오버헤드가 큰 개발환경에 질려 유료 IDE인 IntelliJ IDEA 를 통해 모던 웹 개발을 꾀하기도 했다.
게다가 구글은 자사 안드로이드 개발에 Eclipse 를 떠나보내고 IntelliJ 를 수용하여 많은 국내 안드개발자들의 공분(?)을 얻었다.

그런 말도 탈도 많은 Eclipse에서 며칠 전 Che 버전이 오픈됐다.
몇년 전부터 웹 기반 Eclipse 개발을 발표했고, 그리고 꾸준히 개발해왔다.
그리고 이제 “쓸 수 있는” 웹 기반 Eclipse IDE가 생겼고, 이 버전 코드명칭을 Che 로 칭했다.
근데 Che가 뭔지 아직 모르겠다. 좀 더 자료를 수집해야겠다.

어쨌든, 이녀석은 웹 기반의 IDE이다.
Atom같은 쉘을 통하여 자체 브라우저를 통해 응용 프로그램 행세하는 에디터는 아니고 그저 브라우저에 돌아가는 녀석이다.
이녀석은 서버로 운영되며, 서버 내 개발자들에게 같은 개발 환경을 제공한다.

그리고 또하나 흥미로운 기능이 있다면 바로 Workspace 서버이다.
이클립스는 Workspace를 잡고 여기에 설정을 관리하고 개발 환경을 만든다.
이런 Workspace가 이제는 서버에서 관리되어 개발자들의 용량 부담을 최소화 했다.

Eclipse Che

요렇게 생겼다. 뭔가 인텔리제이같이 생겼다고? 디자인만 그럴 뿐 순전히 Eclipse 환경이다.
그리고 이 같은 개발환경을 여러 개발자에게 워크스페이스와 같이 제공한다.

그렇다면, 이런 개발 환경에서 얻을 수 있는 개발 이점은 무엇이 있을까?
가장 많이 쓰이는 자바 개발 환경 기준으로 설명하겠다.

1. 개발환경을 매우 쉽게 세팅할 수 있다.

한국의 SI 스러운 개발환경. 솔직히 말해 A부터 Z까지 표준을 맞춘다는 건 마음에 안들고 너무 꽉막힌 생각이다.
한국의 개발환경은 그리고 A-Z 모두 맞춰줘야 한다. 심지어 경로까지… 워워…
아무렴 어떤가. 클라우드 개발환경은 개발자들의 쓸데없는 개발환경 세팅 시간을 줄여준다.
관리자가 그저 개발자 계정과 워크스페이스 권한만 주면 개발자는 브라우저를 통해 접속만 하면 개발환경 세팅 끝이다.
물론 DB의 경우는 얘기가 틀리겠지만 Tadpole DB Hub를 통해 개별 관리하거나 하면 시간은 더 줄어들겠지만 그럴 일은 없어보이고…

2. 익숙한 개발환경을 그저 클라우드로 즐길 뿐이다.

Eclipse Che 는 Eclipse 기반이다. 당연히 자바로 만들었고, 자바로 돌아간다. 자바 개발환경이 모범을 보여줘야지.
자바 개발자들에겐 당연히 Eclipse 는 친숙함 그 자체이다. 이 친숙함 그대로 클라우드로 즐기면 된다. 뭐가 문제인가?
개인 프로젝트 개발해야 하는데? 그러면 별도 IDE를 쓰면 되잖나. 개발환경 분리되는게 일상인 프리랜서가 뭔 걱정인가?

3. 보안과 통합이 매우 쉽다.

워크스페이스를 서버가 관리한다는 게 무슨 뜻이겠는가? 개발 소스를 자기들이 관리하겠다는 거 아닌가?
그렇게 되면 개발자들이 개별로 소스와 구조를 가질 필요가 없어지고, 그리고 이로 인한 소스 코드 유출 피해를 줄일 수 있지 않겠는가?
아직 소스 구조를 다운로드 받기 기능과 이에 대한 권한에 대해서는 확인이 필요하지만, 만약 있다면 개발 보안도 한층 업그레이드 될 것이다.
그리고 개발자가 이제 철수한다면 철수할 개발자에게 권한을 빼면 끝이다. 뭐 삭제
또한, 통합을 하고자 한다면 그저 관리자가 Eclipse Che 서버만 관리하면 된다. 모든 개발자가 다 적용된다.
물론 각 개발자별 플러그인이 필요할 것이고, 이를 관리자가 맞춰줄 수 있다. 그렇지 않다면 분명 불편할 개발자도 있을 테니.
SVN? Git? 다 된다. 버전 관리는 공통으로 한번 세팅하거나, 사용자별 세팅하면 땡이다. 그다음 지속적 배포 환경 고민을 하면 된다.

4. 개별적 개발상 이슈를 최소화할 수 잇다.

개발하다보면 예상치 못한 문제에 직면한다. 갑자기 개발자 컴퓨터가 맛이 가버리거나, 팅기거나 등등…
여태까지 작업한 것들이 날아가는 모습을 본 개발자에게는 허망함과 부담감이 가득할 것이다.
또한, 개발 환경이 반드시 100% 맞춤형이 아니다 보니, 어떤 컴퓨터에서 잘 안돌아가기도 한다.
그래서 어떤 프로젝트는 심지어 OS와 브라우저 등 아주 원초적인 환경까지 통일해야 하는 표준을 규정하여 개발시키기도 한다.
피곤하다.
웹 환경은 그딴거 없다. 웹만 되면 된다. 구버전 브라우저만 아니라면 개발할 수 있는 모든 게 다 된다.
Eclipse Che는 그렇게 만들어졌고, 그게 목표이기 때문이다.
웹 브라우저 외에 어느 환경도 구애받지 않는 개발 환경이라면 피곤할 필요도 없지 않겠는가?
게다가 관리자가 허락만 한다면 재택 근무도 가능하고. 물론 그럴 가능성을 염두해 둘 리는 없겠지만.

이제 개발환경도 새바람이 불고 있다.
여태까지 나온 임대 기반 개발환경이 싫다면 언제든 개발환경을 구축하여 제공할 수 있다.
서버 기반의 개발환경으로도 데스크탑 못지 않은 개발환경을 구축할 수 있는 시대도 도래했다.
이를 친숙한 Eclipse 에서 Che 버전을 통해 제공할 것이다.

이제 자바 개발자들에게 고민해야 할 것은 무엇인가?
바로 인식의 전환이다.
다른거 다 필요없다.

composite / 2015년 12월 28일 / Dog's bullshit / 6 Comments

Symbol 프로그래밍?

https://en.wikipedia.org/wiki/Symbol_(programming)

심볼. 굳이 우리말을 쓰자면 기호. 기호 개발. (뭔가 어색하다?)

오늘 페북에서 ECMAScript 6 표준에 Symbol이 정의되어 누군가가 MDN에 번역해 주었다.
Symbol – Javascript | MDN
심볼. 아마 자바, 닷넷, 자스 개발자 등에게 어찌보면 생소한 개념일 수 있다.
하지만 루비 개발자나 Object-C 개발자는 이미 있기 때문에 알고 있을 것이다.
이 심볼 개발방법은 여러 스크립트 언어 등에서 채택한 개발론이다.

간단하게 설명하자면, “가장 유일한 식별자”다.
뭐?
루비(Ruby)의 심볼이란?

정의는 한 번. 더 이상 변경할 수 없는 값이다.
여기까진 상수와 비슷한 개념이다.
그렇다면 값 비교 시 “A” 와 “A”가 같다? 심볼은 그딴거 없다.
그렇다. 심볼의 값은 일종의 사람만이 식별하기 위해 존재하는 값일 뿐.
문자열 값은 리터럴을 정의할 때마다 메모리가 늘어난다. 설령 변수를 지정하던 상수를 쓰던.
간단하게 생각해보자.
“A” “BC” “DEF”… 이들은 언제 바뀌지 못하기 때문에 불명확한 메모리를 할당받으며 서 있다.
당연히 그런 만큼 메모리를 잡아먹는다.
하지만 심볼은 딱 정해진 메모리만큼만 먹는다. 바뀔 일도 없기 때문에. 확장할 일도 없고.
그러니 메모리 애끼는 효과가 있다.

그렇다면 어따가 쓰냐고?
가장 쓰임새가 많이 쓰이는 곳이 바로 “해시 값”을 다루는 데에 쓰인다.

JS에 새로 정의된 Symbol을 통해 예제 하나 뿌리겠다.
ES6 Symbol Test 예제

var obj = {};
var a = Symbol("a")

obj[a] = "a";
obj[Symbol.for("b")] = "b";
obj["c"] = "c";
obj.d = "d";

for (var i in obj) {
   console.log(i); // logs "c" and "d"
}

console.log(obj[a]); //logs "a"

심볼 “a” 란 해시 키에 “a” 값을 넣었다.
근데… 반복문에는 나타나지 않는다.
그렇다. 주소 값이니 나오지 않을 수밖에.
대신에 명시적으로 해시 키를 정의하면 가져올 수 있다.
이런 이득이 있다는 것이다.
그렇다면 이런 특징으로 얻을 수 있는 이득이 뭐가 있을까?

간단하다. hidden 키와 값을 넣을 수 있는 그런 개발이라면 모두 가능하다.
일종의 private identifier 인 셈이다.

자. 이제. 자바와 닷넷도 이런 개념이 존재하냐고 물어보는 사람이 있을 것이다.
당연히 없다. 근데 자바와 닷넷은 문자열에 한해 인터닝(Intern) 이라는 개념이 있다.

자바의 String.intern() String.intern()은 메모리를 아낄 수 있다?

  • String pool에 있는 각종 문자열에 equals해서 같은게 있다면 그 놈을 반환하고,
  • 같은게 없다면 String pool에 String object를 추가하고, 추가한 놈을 반환한다.

즉, String 객체를 리터럴로 관리하여 메모리 절약을 꽤하는 개념이다.
그렇다 보니 아래와 같은 단점이 존재한다.

  • 우선 String 객체를 하나 만들어야 한다.
  • String의 equals 메소드를 이용해서 String pool에 있는 놈을 찾아서 비교해야 한다. ( 시간이 걸림 )
  • String pool에 들어 갔으므로, 더 이상 GC(가비지컬렉션)의 대상이 될 수 없다. ( 메모리 관리 불가 )

그렇기 때문에 적재적소에 잘 관리해야 한다는 점이 있다. 그래도 같은 문자열을 객체로 정의하여 메모리 쳐묵보단 낫다.

참고로 닷넷도 아주 동일한 개념이다. String.Intern() 메소드 쓰는 건 매한가지이며 동일하기 때문에 별도의 설명은 생략하겠다.

자. 자바와 닷넷이 문자열을 관리하는 방법이 여기서 나온다. 리터럴은 자바나 닷넷이나 내부 풀을 따로 운영하여 저장한다. GC에 걸리는 걱정 없이.
(물론 new String 처럼 객체로 만들었다면 걸릴 각오는 해야 하지만.)

뭔가 삼천포로 빠진 것 같다.
하지만 메모리를 아껴서 빠르고 유연한 개발을 꾀하는 개발자는 있다.
이럴 때 필요한 것이 뭐고, 뭘 알아야 하는지는 개발자의 사명인 것이다.
그러기 위해 이 포스트를 올렸다.
그럼 이제…

끗.

composite / 2015년 11월 17일 / Piss Development / 0 Comments

2015년 6월 29일자 NoSQL 오픈소스 임베디드 DB 리스트

이번엔 약속대로 자바 기반의 임베디드 NoSQL DB를 소개한다.
Java 1.6에 내장된 Apache Derby DB(Java DB)는 소개에서 제외한다. SI/SM 개발자들 이거 자바 내장인거 알기나 하는지 내 알바 아니지만.
사족으로 역시 자바가 정말 다양한 방식의 NoSQL DB가 있다. 닷넷에서 아쉬우면 IKVM 써서 쓰는 방법이 있긴 하지만…

1. MapDB

MapDB is embedded database engine. It provides java collections backed by disk or memory database store. MapDB has excellent performance comparable to java.util.HashMap and other collections, but is not limited by GC. It is also very flexible engine with many storage backend, cache algorithms, and so on. And finally MapDB is pure-java single 400K JAR and only depends on JRE 6+ or Android 2.1+.

순수 자바로 만들어진 컬렉션 기반의 키값 DB. 메모리 및 파일 가능.
400kb의 가벼움과 안드로이드 지원으로 특히 안드로이드 개발자에게 사랑받고 있는 DB인 데다가
Apache License 2.0 이라 기업에서도 부담없이 사용 가능.

2. OrientDB

OrientDB is a 2nd Generation Distributed Graph Database with the flexibility of Documents in one product with an Open Source commercial friendly license (Apache 2 license). First generation Graph Databases lack the features that Big Data demands: multi-master replication, sharding and more flexibility for modern complex use cases.

순수 자바로 만들어진 Graph/Document DB. 서버/임베디드 모두 가능. NoSQL 계의 MySQL 같은 존재임.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
리플리케이션 및 셰딩이 지원되기 때문에 스케일링이 가능하면서도 Apache License 2.0으로 기업에서도 무료로 사용 가능.
자바를 사용하는 유명 기업에서 채용되기도 하였으며, 유료인 Enterprise Edition은 엔터프라이즈에 필요한 기능을 사용 가능. (개발/테스트 목적으로 무료로 사용가능)

3. Neo4j

Neo4j is used by thousands of organizations, including 50+ of the Global 2000, in mission-critical production applications. Developed by the inventors of the modern graph database, Neo4j is the only graph database on…

순수 자바로 만들어진 Graph DB로 OrientDB와 쌍벽을 이루고 있으나 우세. eBay나 National Geographic 등 세계 유명 기업에서 사랑받는 DB.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
리플리케이션 및 셰딩이 지원되기 때문에 스케일링이 가능한데 라이선스가 GPLv3 라 기업의 경우 내부시스템은 무료로 쓸 수 있으나 재배포 판매 시 소스 공개하던가 사던가 해야 함.
유료인 Enterprise Edition은 엔터프라이즈에 필요한 기능을 사용 가능. (30일 체험 사용 가능)

4. Titan

Titan is a scalable graph database optimized for storing and querying graphs containing hundreds of billions of vertices and edges distributed across a multi-machine cluster. Titan is a transactional database that can support thousands of concurrent users executing complex graph traversals in real time.

빅데이터를 위해 태어난 자바 기반의 Graph DB. 다른 NoSQL DB와 연동하는 기능이 특징.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
빅데이터 위주의 스케일링에서 강점이 있으며, Apache License 2.0이기 때문에 기업에서도 부담없이 사용 가능.

5. iBoxDB

iBoxDB is a fast transactional table style document NoSQL Application Database, easily store, process objects and documents, traditional table with unstructured data, zero configuration, pure JAVA and .NET engines, no dependencies.

iBoxDB has a well designed interface with great performance and capability for agile development, you can focus on the applications. It can embed into an application and deploy on mobiles, desktops, servers, then help designers to persist objects and documents thread-safely with transaction support.

.NET 과 Java 둘 다 품은 (그것도 IKVM도 아니고 독립적으로 각각 엔진 개발) 특이한 키값 기반 NoSQL DB.
.NET은 2 이상, Java는 6 이상이면 가능. 라이선스는 걍 무료. 오픈소스는 아님 (자바는 오픈되었으나 닷넷만 클로즈드)

6. JasDB

JasDB was designed with easy of use and minimal configuration in mind. JasDB can be installed and configured in almost no time at all. Use JasDB as an embedded DB inside your JVM or you can use it to store your unstructured data in JSON format. If you want to scale JasDB, simply run and use it through the REST webservice.

순수 자바로 만들어진 Document DB. REST 내장으로 서버로도 사용 가능. JSON 형식으로 저장하는 것이 특징.
안드로이드도 지원하며, MIT X11 License로 기업에서도 부담없이 사용 가능

… 자바로 만든 NoSQL DB 드럽게 많아서 더이상 나열 못하겠다.
NoSQL DB를 전문적으로 모은 사이트가 있으니 어느 언어 개발하던 상관없이 부족함을 채우고 싶다면 여기로 가서
http://nosql-database.org/
Key-Value, Document, Graph, Column 등 다양한 DB 종류 구분이 가능하다. 하지만 지원되는 언어는 나도 모르니 해당 공식 사이트 가서 확인하라.

composite / 2015년 6월 29일 / Piss Development / 0 Comments

[.NET vs JAVA] 쓰레드 동기화

고급 언어의 가장 알다가도 모를 이슈가 바로 쓰레드 동기화이다.
둘 다 Thread unsafe 의 경우는 반드시 발생을 하며, 특히 대량 처리로 인해 꼬이는 경우에 대해서는 유용하게 사용한다.
그럼 이 둘이 사용하는 동기화의 차이는 무엇일까?

결론부터 말하자면 차이점 없다. 기능 똑같다. 단지 구문만 틀릴 뿐.
자바의 경우 메소드에 synchronized 키워드를 붙일 수 있다.

public synchronized void doSomething(){
    //...
}

하지만 그래봤자 메소드 내용을 아래와 같이 처리하는 꼴이 된다.

public void doSomething(){
    synchronized(this){
        //...
    }
}

닷넷은 메소드에 동기화 키워드를 제공하지 않으며 구문으로만 제공한다.

public void DoSomething()
{
    lock(this)
    {
        //...
    }
}

그리고 임의의 private 객체 하나 지정해서 이를 사용해서 부분적인 동기화 작업을 수행하는 케이스가 대부분이다.
문제는 자바의 경우 메소드 동기화는 클래스 동기화나 다름없는데도 이를 이용하는 경우가 많다는 것이다.
물론 클래스 모두 동기화를 걸어서 일관적으로 수행하는 작업이라면 오히려 편리하지만,
그런 경우가 흔치 않기 때문에 오히려 동기화 방식은 구문 방법을 추천하고 싶다.
그 이유는 간단하다. 유연하고, 명확하며, 동기화가 필요한 부분에만 적용되어 더 빠른 처리를 제공할 수 있다.
특히 닷넷과 자바를 오가는 등의 폴리글랏 개발자라면 메소드 동기화보다 동기화 구문을 사용하자.
마이그레이션하기 존나 편할 것이다.

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

자바 개발자들은 왜 비동기를 싫어하는 걸까?

지금 닷넷 하고 있지만 얼마 지나지 않은 자바 개발 시절 얘기다.
나는 자바스크립트의 비동기 패턴에 익숙했다.
그래서 가끔씩 이벤트 패턴을 사용하기도 한다. 웹인데도.
하지만 공통팀 개발자로부터 태클이 들어왔다.
Anonymous Class 사용을 하지 말라는 거다. 유지관리가 어렵다는 이유에서였다.
나는 어이가 없어서 따졌고, 프로그램도 문제없이 돌아가는데 대체 왜냐고 물어봤다.
결국 최종적인 답변은 듣지 못했으나, 한가지 단서를 발견했다.
원래 자바는 익명 클래스를 만들면 해당 클래스에 $숫자 가 추가된 파일을 생성한다.
아마 그가 걸고 넘어지려는게 그 파일이 아닌가 생각했다.
왜냐면 그 달러 파일 안넘기면 당연히 런타임 오류가 나서 프로그램이 동작하지 않으니까.
개발환경에서 멀쩡히 돌아가는게 가운영서버에서 안돌아가는 케이스 되시겠다.
Jenkins 쓰지만 운영 배포는 따로 관리를 통해 수동으로 배포하고 운영한다.
결국 얼마 지나지 않아 나는 익명 클래스 빼고 길고 긴 Procedural style 로 코딩할 수밖에 없었다.
야근했다. 그날. ㅅㅂ.

자바 SI 하면서 정말 힘들었다. 튀는 개발은 받아주지 않는다. 당연하겠지만.
게다가 정부부터 전자정부 강제로 쓰게 만드는데 뭐 그건 좋다 이거야.
하지만 확장성이 부족하고 (어려움) 틀 안에서만 개발해야 한다.
이래놓고서 대량 트랜잭션을 바란다. 미치겠다.
물론 불가능한 건 아니다. 단지 빡셀 뿐이다.

자바는 원체 동기와 비동기 유연하게 돌릴 수 있다. Quartz를 통한 스케줄링을 사용할 수 있다.
특히 웹에서 그 진가를 발휘하지만 역시 GC와 메모리 문제로 따로 돌리는 경우가 대부분이다.
닷넷의 경우 이벤트 지원이 확실하기 때문에 비동기 프로세스를 자바보다 더 간결하게 구성할 수 있다.
그러나 ASP.NET의 경우에도 웹 앱에 스케줄링 걸면 뻑나가기 때문에 따로 빼거나 COM+ 돌린다.
여기서 웹상에서는 자바가 ASP.NET 보다는 스케줄링 작업이 잘 되긴 하지만 둘다 결과적으로 메모리 관리는 쉣이다.
둘 다 웹에서 비동기 스케줄링 걸 수는 있지만 메모리 관리 측면에서는 올바르지 않은 방법이다.
하지만 비동기만 쓴다면 나쁜 선택도 아니다. 사실 관점지향개발(AOP)도 비동기의 한 부류이기 때문이다.
이벤트 돌리니까 말이지. 하지만 그렇게 생각 안하나보다. 게다가 AOP조차도 잘 안쓴다.
비동기 개발에 능한 자바 개발자는 이벤트를 효율적으로 운영하는 방법을 찾는 데에 열중했고,
그 과정에서 발견한 프레임워크가 바로 Akka 이다.

하지만 SI 출신 개발자들은 이런 방식의 코딩을 능멸하는 것 같다.
여전히 많은 개발자는 Procedural style 의 코딩을 즐긴다. 객체지향? 그건 클래스에나 통하는 거고.

당연히 전통적 방식에 익숙한 자바 개발자들이 아는 범위 내에서 문제 없이 코딩해야겠는데 어쩌겠는가.
절차지향이 아무래도 보기에는 좋으니까. 무조건 순서대로 처리하니까 말이다.
게다가 가능하면 절차대로 수행하는 게 프로젝트 면에서 안전빵이라 생각하고 있을 것이다.

하지만 요즘은 달라졌다. 코어 수는 늘어났고, 더 많은 작업을 더 짧은 시간에 해내기를 요구한다.
게다가 코어 수가 늘어난 것도 엄청 오래됐다. 전통적인 싱글 코어에 맞춘 프레임워크는 멀티코어를 자동으로 해결해주지 않는다.
그 어떤 언어라도 마찬가지다. 더 많은 작업을 더 빨리 작업하려면 개발자가 생각하고 잡아주고 코딩해야 한다.
그런 측면에서 Procedural style 코딩은 이에 한계가 있다.
자바와 닷넷이 아무리 멀티코어를 지원한다 해도, Procedural style 코딩은 결국 하나의 쓰레드만 쓰는 꼴이니까.
프레임워크가 알아서 필요하면 쓰레드 잡고 간다고 편안하게 생각한다면 그건 개발자의 자질이 글러먹었다.

그런 측면에서 병렬 처리는 많은 작업을 짧게 해내는 데 유용한 기능을 제공한다.
자바 닷넷 둘 다 제공하거나, 부족할 경우 채워주기도 한다.
하지만 아무리 커다란 프로젝트라도 여전히 이를 만족하는 개발은 없다. 본적도 없고.
공공데이터 시스템 빼고는. (이는 병렬처리 안하면 뻑나가는 구조임)
특히 금융권 개발은 이를 잘 반영 안하고 있다. 대부분 DB 프로시저에 익숙한 탓이기도 하다.
그리고 이를 개선할 생각도 없고 개선하려 해봤자 눈먼 돈만 나가고 결국 실패하고.

이 병렬 처리를 하려면 개발자가 갖춰야 할 기본 자세가 바로 비동기이다.
왜냐면, 병렬 처리는 동시에 이루어지기 때문에,
Procedural style 로는 동시에 누가 먼저, 나중에 시작 후 끝나는지 캐치할 방법이 없기 때문인 데다가,
Procedural style 은 싱글 프로세스이기 때문에 애초부터 접근할 방법이 없다.

비동기의 장점은 꽤 많다. 물론 비동기도 Procedural style 에 비해 단점도 있다.
특히 비동기는 작업 중간중간을 캐치할 수 있다는 크나큰 장점이 있다.
예를 들면, 1분 이상 걸리는 무거운 쿼리를 요청한다고 가정해보자.
Procedural style 로 하려면 이 쿼리를 마냥 기다려야 다음 작업을 진행할 수 있다. 과정보다는 결과가 우선시되는 작업이다.
하지만 비동기로 하면 이 무거운 쿼리가 성능에 어떤 영향을 미치는지, 이에 실패하면 어떨지 등 여러 경우를 캐치할 수 있다.
이는 결과와 과정을 둘 다 캐치해낼 수 있는 작업인 것이다.
그걸 잘 반영한 자바 프레임워크가 바로 Akka 이다.
하지만 그거 쓰는 자바 개발자들이 얼마나 있을까. 특히 SI 말이다.

Akka 가 이젠 닷넷 개발자도 배려해 주었다. 이런 비즈니스 요구를 잘 반영한 Akka를 말이다.
아. 생각해 보다 닷넷 개발자도 자바 개발자와 다를 거 없다. 둘 다 절차적 스타일에 따른다.

나는 이 글을 쓰는데 비동기를 강조하고 Procedural style 을 까내리려 하는 것은 절대 아니다.
Procedural style 은 당연히 피할 수 없는 코딩 구조이다.
하지만 나는 필요시 비동기 스타일을 권유하고자 글을 쓰는 것이다.
굳이 대안을 작성하자면, 비동기 개발 좀 하라고. 끝.

SI가 정말 한국 개발의 발전을 저해시키고 동결시키긴 했다. 나도 이런 답답한 개발에 지겨우긴 했다.
하지만 그렇다고 나를 받아주는 곳도 없다. SI에서는 튀고, 그렇다고 선진개발자에게 SI경력은 Procedural style 중점의 개발자로 낙인찍히니.
나는 이렇게 본의아니게 어정쩡한 개발자가 되버렸다.
뭐. 아무렴 어때. 이제부터 중요한 것은, 내가 직접 보여주는 수밖에.

어떤 패턴을 쓰던 나는 존중한다. 하지만 그 패턴만 고집하는 행위는 옳지 않다.
그런 사고방식이 전에 자바 개발했을 때 개발자의 사기를 떨어뜨렸다.
그래서 나는 어떻게 개발하던 존중해달라고 하고 싶어서
이런 뻘글 썼다.

아. 한가지 첨언하자면 Akka는 스칼라로 만들어졌지만 자바로 개발 가능하니 스칼라 태클 걸지 않도록.
자세한 소개는 Akka 로 한국어 웹 검색만 해도 좌르륵 나온다.

composite / 2015년 4월 10일 / Piss Development / 0 Comments

[.NET vs JAVA] Boxing VS Generic

닷넷은 2.0부터, 자바는 1.5부터 제네릭을 지원한다.
당연히 그 전까지는 박싱과 언박싱을 써왔다.
그리고 그때당시 개발자들은 이미 그런 방식에 익숙하기 때문에 제네릭을 안쓰기도 한다.
특히 자바개발자는 제네릭 개념이 꽤 늦게 들어왔기 때문에 제네릭 안쓰는 개발자가 더 많다.
심지어는 나처럼 제네릭 쓰지 말라는 이상한 소리를 들을 수도 있다.

자, 그렇다면 이 두 언어별 박싱과 제네릭의 특징을 알아보자.

.NET

닷넷은 닷넷 2.0부터 출연했는데, 시기적으로는 꽤 빨리 들어온 것이다.
어쨌든, 얘네들의 박싱과 언박싱은 C/C++의 단순한 업캐스팅 개념으로 만든 것이 아니다.
일단 닷넷에 있는 모든 객체는 object 클래스에 상속된다. 설령 struct로 정의한다 해도.
근데 이 structnullable이 불가능하다. 물론 Nullable<T>로 가능은 하지만.
얘네들의 박싱 개념을 C/C++로 표현하면 다음과 같다.

int num1 = 123;
object obj = num1;
int num1 = 123;
int *obj = new int;
(*obj) = num1;

즉, 전문적으로 말하자면 힙에 새로운 객체가 생성되면서 값이 복사되는 그런 개념이 되는 것이다.
그걸 Generic 이라는 개념을 도입했는데, 이 방식을 사용하면 Boxing과 Unboxing이 필요 없어진다.
ArrayList를 예로 들어보자.

ArrayList arr1 = new ArrayList();
ArrayList<string> arr2 = new ArrayList();

자. 일단 시니어 닷넷 개발자라면 HashTable 사용에 익숙할 것이다. 어쨌든, 얘네들은 동적 배열을 만드는데,
일정 개수만큼 (보통 16) 자리를 부여한다. 근데 제네릭이 없으니 뭐로 하겠나. 당연히 최상위 객체인 object 자리가 되는 것이다.
그러면 arr1.Add(num1); 을 넣으면 어떻게 되느냐. 싫어도 Boxing 해야 한다. 그럼 반대로 가져올때는? 당연히 강제 Unboxing 이다.
그에 반해 arr2 는 제네릭으로 타입이 명시되어 있다. 그리하여 닷넷 런타임은 일정 개수만큼 자리를 부여하되,
타입이 정해졌으니 object로 할 필요 없고 명시도니 string 자리를 부여한다.
그럼 거기다가 string 값만 넣으면 되니 Boxing 과 Unboxing 이 필요 있겠는가? 당연히 필요 없어지게 되는 것이다.
그래서 닷넷의 제네릭이 괜히 성능 얘기 나오는 게 아니고, 그걸 경험한 닷넷 개발자들은 제네릭에 익숙한 것이다.

Java

자바는 Auto Boxing 이란 개념이 있다. 닷넷 개발자는 생소할 텐데,
이 Autoboxing 개념은 자바 1.5에서 출발했다.
자바는 primitive type, Class, 그리고 null 이 있다.
자바 개발자들은 알 만한 사실이지만 primitive type 에 null 허용되는 건 당연히 아니다.
Auto boxing이 생기는 큰 이유는 바로 primitive type 와 Class 간 처리 때문이다.
숫자 타입으로는 primitive type 인 int 와, Class 인 Integer 가 있다.
이 둘이 오갈 때 당연히 메소드를 호출하는데,
int -> Integer = Integer.valueOf()
Integer -> int = (Integer).intValue()
이 둘을 명시적으로 Boxing 한다면 어떻게 될까? 먼저 primitive type 는 당연히 클래스가 된다.
Object도 클래스기 때문에 primitive type 를 직접 관리할 수 없기 때문이다.

int num1 = 123;
Object obj = num1;
//는 아래와 같다.
Object obj = Integer.valueOf(num1);

그렇다고 클래스라고 해서 그냥 넣는가? 안타깝게도 닷넷과 다를 바 없다.
자바나 닷넷이 Object 업캐스팅 개념이 없으니까.

자, 이제 제네릭으로 간다.
자바는 닷넷 제네릭과 달리 메모리에 관여하는 게 아니라 그저 심볼 역할만 하는 녀석이다.
그래서 ArrayListArrayList<T> 는 같은 클래스다.
닷넷은 ArrayListArrayList<T> 는 엄연히 다른 클래스로 취급하는 것과는 대조적이다.
이것은 당연히 하위 호환성 때문이다. 닷넷은 1.x과의 호환성을 포기하고 제네릭을 도입했으니 가능한 얘기다.

그래서 제네릭을 달아봐야 add() 로 넣을 때 박싱해버리고 get() 할때 언박싱한다.
제네릭 달아봐야 박싱 언박싱 그대로 해버리니… 그래서 닷넷과 달리 성능향상이 없다.
그저 컴파일 타임에서 타입 검증에 대한 강화 용도로 쓰이게 된다.

그래서 자바 개발자들은 제네릭 안써도 잘 한다. 굳이 필요가 없다고 느낄 정도다.
그래도 검증과 무결성 측면에서는 당연히 제네릭이 유리하다.
제네릭 쓴다고 성능 떨어지는것도 향상되는 것도 아니지만, 방어적 코딩이 나중에 장애나 유지보수에 어떻게 빛을 발하는지 겪어본 사람은 알 것이다.

결론

어쨌든 공통적으로 제네릭은 타입에 민감한 닷넷과 자바에게는 신의 한수인 것이다.
그러니 왠만하면 쓰자.

composite / 2015년 4월 8일 / Piss Development / 0 Comments