다중 플랫폼을 고려한다면..., mysql workbench의 궁색한 변명?

저도 자바를 설치하기 싫어한다에 동의합니다.
전 자바 개발자이긴 하지만 자바 깔기 싫습니다. :(
최근 릴리즈 들어 jdk 포함해 jre의 용량은 기적에 가까울 정도로 줄어들었지만,
'개발 이외의 목적'을 위해서 혹은 '프로그램 하나'를 위해서 자바를 설치해야한다면 '싫다'라고 느낄 것 같습니다.

좋은 글 잘 읽었습니다. :)

- Why don't you come in OpenSolaris? I hope you come together.

이곳에서 글을 읽고 다운로드하여 설치하려고 하니 .NET framework 2.0 이상이 필요하군요.
전 자바보다 저거 설치하는게 몇 배는 더 싫은데... 자바는 안되고 .NET은 되고?
저 사람들 말이 앞 뒤가 안 맞네요. 혹시, Linux 용은 mono 설치하라고 하는거 아닙니까?

진정 거부감 없이 깔수 있는 크로스 플랫폼 환경은 Flash 밖에 없는게 아닌가 하는 생각이 드네요. Write once, run everywhere의 세상은 아직 먼건가요?

MySQL workbench 개발을 Qt나 WxWindows툴킷으로 시작했으면 어땠을까 하는 생각이 드네요.

=-=-=-=-=-=-=-=-=
http://youlsa.com

핑계같고 변명같지만 개발자라는 이유로 다 이해해줍니다.
아쉬..귀찮아...

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

충분히 일리가 있는 이야기들 같은데요. 그리고 저도 JRE 설치하기 무척 싫더군요. 크로스플랫폼 GUI 툴킷 사용하지 않는 이유도 바로 이해가 됩니다. Mac OS X에서 비 Cocoa 애플리케이션이 얼마나 우스꽝스럽게 나오는지 아는 사람은 이해가 될 겁니다. X라도 뜨게 되면 얼마나 보기 싫은지. (아는 사람의 표현을 빌리자면 “무도회장에 노숙자 갖다놓은 것 같은” 모양.) MySQL GUI Tools의 Mac OS X 버전은 모두 Cocoa로 작성된 것 같던데, 그래서인지 무척 깔끔하고 만족스러웠습니다.

• dahlia.kr
• 한국 Io 사용자 모임
• LangDev

윗분들 자바에 관해 그렇게 얘기하시다니요.

지금 저의 애인 자바가 울고 있습니다.

하나 하나 반박을 하겠습니다.

--------------------------------------------------------------------------------------------
1. creativeidler "자바 GUI 는 느리다"

자바 개발 툴에서 자신이 만든 프로그램을 실행하면서 느리다고 하시는건 좀 아니잖아요.

일단 jar 파일로 컴파일하신후 에디터를 통해서가 아닌 실재로 돌려보셔야죠.

debug 프로그램하고 release 프로그램하고 같나요?

그리고 씨쁠쁠에서 컴파일 할때는 컴파일 옵션을 주시면서 자바는 아무것도 안주시지 않나요?

예) 자바에서 게임이라면 OS 에서 지원하는 그래픽 카드 파이프 라인

OpenGL 혹은 DirectX 파이프라인을 사용하는 컴파일 옵션을 주셔야

만족하는 jar 파일 결과가 나옵니다.

----------------------------------------------------------------------------------------------

2. fender "자바 스윙 look & feel 이 맘에 안든다(?)"

자바 스윙은 3 가지의 테마를 지원합니다.

- 지금 사용중인 OS 의 기본 테마.

- 자바에서 지원하는 몇 종류의 테마.

- 자신이 직접 만든 테마 (JTattoo 혹은 JNapkin 등)

이중에서 자신이 직접 고르면 됩니다.

혹은 오버라이딩을 통해 직접 색을 칠해주는 방법도 있죠.

제가 2 번에 ? 표를 친 이유는 자바 개발 자시라면 당연히 알고 계실거라 믿기에

제가 질의를 잘못 파악한것 같아서 친겁니다.

제가 잘못이해했다면 사과드립니다.

------------------------------------------------------------------------------------------------

3. lateau "메모리를 너무 많이 먹는다. 메모리 리킹이 있다!"

이 부분은 반박 할수가 없군요.

일단 자바자체가 jvm 위에서 돌아가는 것이기에 일정량의 메모리를 먹습니다.

더욱 큰 문제는 메모리 리킹인데...

이것은 최신 버전을 받으면 대부분은 사라집니다.

하지만 아직도 메모리 문제가 남아 있긴하죠.

그래도 대부분의 경우는 유저가 프로그램을 잘못 짠겁니다.

무식하게 룹에서 new 를 통해 필요이상의 객체들을 생성하고 처리는 하지 않죠.

어느 한 지점에서 한번씩 System.gc() 를 통해 쓰레기 처리를 해주는것이 중요합니다.

-------------------------------------------------------------------------------------------------

자바 개발 자들이어...

자바는 신생언어 입니다.

문재가 많을 수도 있고 마음에 안들수도 있지만.

새로나오는 기술들도 보지않고 옛날 기술들만을 고집하면 어찌 됩니까?

새로 새로 릴리스 되는 자바 문서를 읽으며 공부를 하는 습관을 들입시다.

-미국에서 자바하던 학생이 돌아다니다가 끄적여봄-

데이터 베이스 모델링 툴 이라면 아마 경쟁 제품에서 ERWin이 가장 유력한 제품일 것인데요
ERWin은 M$ 기반에서 동작 합니다.
ERWin 자체가 잛은 시간 사용된 애플리케이션도 아니고 , 지속적으로 개발되고 시장에서 선택 받은 제품으로 만약 ERWin 경쟁 제품을 만든다면 M$ 기반의 데이터 베이스 모델링 툴 사용의 사용자가 압도적으로 많다는 걸 인지 하였겠지요.
저도 개발 프로젝트에서 데이터 베이스 모델링 툴은 vbox에서 실행 되는 M$ NT에서 ERWin 사용하는 입장에서 충분이 납득이 갑니다.

글이 GUI에서의 자바 성능 문제로 흘러가고 있군요 ㅎㄷㄷ;;

CDC급 jvm을 clean room 구현 하기에는 팀의 역량이나 시간에 한계가 있어서 제가 일하던 곳에서는 ORP 라는 intel기반 vm위에 kaffe의 AWT를 붙여서 iPAQ에 올렸습니다. 저는 AWT 쪽이었습니다. 뭐 그당시 Kaffe의 AWT가 지금의 AWT에 비교가 되겠습니까만, 여하튼 iPAQ에서 AWT프로그램을 돌리는데 성공을 했습니다.(삼성의 넥시오에 올리기 위해서 영업을 하다 외국제품에 밀려서 뭐 프로젝트를 접긴했습니다만...)

간단한 AWT 프로그램 하나를 띄우기 위해서 5개의 Thread가 돌고 상당히 복잡하게 context swiching을 합니다. 상상초월입니다. 디버거로(evc 3.0) JVM을 들여다 보면 프로그램이 동작하는게 신기할 정도입니다. 위젯 하나 show하는 걸 따라가본게 정리된게 있는데..

        MT = main thread
        CT = collector thread
 
 (0)    MT : show                                        (main java)
 (1)    MT :   addNotify                                 (Window)
 (2)    MT :       createNative                          (Toolkit)
 (3)    MT :           [in Block No.1]                   (Toolkit)
 (4)    MT :           evtSendWMEvent(e);
 (5)    MT :              in native                      (evt.cpp)
 (6)    MT :              PostMessage   -->              (context switch)
 (7)    CT :                 in WndProc WMEvent.dispatch
 
 (8)                   [in Block No.2 of (2)]
 (9)    MT :           wait      -->                     (blocking)
 (10)   CT :                 [in WMEvent.dispatch]                               
 (11)   CT :                 c.addNotify              (Window)
 (12)   CT :                      supper.addNotify()      (Window)
 (13)   CT :                      supper.addNotify()      (NativeContainer)
 (14)   CT :                      supper.addNotify()      (Container)
 (15)   CT :                      supper.addNotify()      (Component)
 (16)   CT :                      return to Container     (Compoment);
 (17)   CT :                      for (0 to nchildren)
                                      children[i].addNotify();
                                  }   
                                  return to NativeContainer
                                                              (Container)
 (18)   CT :                      return to Window        (NativeContainer)
 (19)   CT :                      finishAddNotify         (Window)
 (20)   CT :                      return to WMEvent.dispatch (8) 
 
 (21)   CT :                 notifyAll                      (unblock MT) 
 (22)   CT :                 return to WndProc       (evt.cpp)
 (23)   CT :                 end of WndProc and context switch
 (24)   MT :       return to (2): createNative
 (25)   MT :       return to (0): show

위의 구조보다야 지금이 더 좋겠지만 앞으로도 JVM 그리고 UI integration layer의 혁혁한 발전이 몇 번 더 거듭되지않고는 native 만큼 쓸만한 반응성을 보일만한 java GUI 프로그램은 어려울것 같습니다.

Life rushes on, we are distracted

음... 점점 글타래의 본래 주제에서 이탈하는 것 같지만, SWT 조차도 데스크탑에서 널리 쓰이지 않는 이유는 이런 것 같습니다.

(1) 사용자 인식의 문제

이 글타래에서도 극명하게 드러났지만, 데스크탑 자바 어플리케이션에 대한 개발자들과 사용자들의 인상은 상당히 나쁩니다.

일반 사용자 입장에서 접해본 자바 프로그램은 우선 설치하기 불편하고 느리며 이질적입니다.

JRE를 따로 다운받아야 하는 경우도 있고 그나마 시스템에 몇개씩 다른 버전의 자바가 깔리거나 JRE를 다운 받는데 엉뚱하게 오픈오피스나 구글툴바를 기본으로 설치하기도 합니다.

또한 최소한 제 지식과 경험으로는 SWT는 물론이고 심지어 스윙조차도 요즘에는 충분히 빠르고도 남습니다만 일반 사용자의 인식은 그렇지 않습니다. 그 이유는,

- 스윙/AWT는 과거에 정말로 느렸던 적이 있습니다. 또한 JVM 자체의 성능도 최근에 급격하게 향상이 되었기 때문에 과거의 경험을 토대로 판단을 한다면 자바 어플리케이션은 여전히 느리다고 생각합니다.

- 스윙은 체감상 느리게 느껴지는 문제가 있었습니다. 1.5근처에도 스윙은 상당한 성능상의 개선이 있었지만 특히나 레이아웃을 조절하거나 화면 전환시 리페인트 과정이 눈에 보여 껌뻑임이 있다거나 (awt의 더블버퍼링 테크닉 같은 것과는 다른 문제입니다) 해서 더욱 굼뜨게 느껴지는 경우가 있습니다.

- 자바 어플리케이션은 보통 많은 메모리를 소비합니다. 더구나 데스크탑에서 쓰이는 자바 어플리케이션은 jedit, eclipse, azureus 등의 예를 보아도 드러나듯, 컴팩트함 보다는 자바의 언어적 특성을 활용해 다양한 기능을 내세우는 것들이 많습니다. 이 경우 메모리 설정 등을 세심하게 튜닝하지 않는다면 gc나 페이징 등으로 GUI 반응성이 때때로 급격히 떨어지는 경우가 있습니다.

- 스윙 어플리케이션은 이질적입니다. 글꼴, 드래그엔 드랍 특성, 파일 선택 창 등 여러모로 '난 자바 어플리케이션이다'라고 광고하는 느낌이 있습니다. 물론 안좋은 쪽으로 말입니다.

- 상대적으로 마이너한 원인입니다만 사용자는 항상 최신 버전의 JRE를 사용하지 않습니다. 예컨대 우분투 게시판에서 이클립스나 azureus 관련 속도/안정성 관련해서 올라오는 글타래를 보면 절반 넘게 썬이나 OpenJDK 대신 GCJ를 사용해서 생기는 문제입니다.

(2) 개발자 인식의 문제

다른 모든 문제를 떠나서 회사에서는 (1)의 사용자 인식상 위험을 감수하며 굳이 자바로 데스크탑 어플리케이션을 개발할 이유가 전혀 없습니다. 또한 데스크탑 실무 경험이 있는 자바 개발자도 전체 자바 개발자 중 극소수에 불과합니다.

이는 충분히 다른 대안이 있는 경우도 있지만 대다수의 웹관련 비즈니스 어플리케이션이 자바로 작성되는 이유와 흡사합니다. 이미 시장에 널려 있는 자바 개발자와 레퍼런스를 제쳐두고 찾기도 힘든 소수 언어 개발자를 모아 대규모 개발 유지보수를 하겠다는 건 개발사 경영진이나 클라이언트사 담당자 모두 납득할 수 없는 논리입니다.

데스크탑 시장만 봐도 그냥 남들 하듯이 VS로 뚝딱뚝딱 GUI 만들어 낼 줄 아는 개발자가 널렸고, 경쟁업체를 봐도 그게 일반적인데 굳이 다른 방법을 찾을 이유도 없고 실제로 찾기도 어렵습니다.

물론 자바도 마음만 먹으면 위지위그로 개발할 수 있고, exe만들고 인스톨러 만들 수 있습니다. 하지만 예컨대 실무에서 VE로 개발해서 JSmooth등으로 exe 만들고 NSIS 같은 걸로 JRE 디텍트/자동설치 스크립트 짜본 개발자가 도대체 몇 퍼센트나 되겠습니까?

또한 특히 스윙 같으면 최근 까지 네이티브 통합에 여러 어려움이 있었습니다. 하다 못해 브라우저 컴포넌트 하나 어플리케이션에 끼워 넣는 것이 간단한 문제가 아니었습니다. VS로 하면 그냥 웹브라우저 컨트롤 가져다가 떨구면 끝나는 걸 스윙에서는 돈주고 써드파티 컴포넌트 사다가 써야 하는 것입니다, 더구나 크로스플랫폼을 포기해가면서 말입니다.

회사 입장에선 자바로 데스크탑 개발할 이유가 전혀없고, 실무 자바 개발자는 이미 서버등 다른 분야에서 더 나은 대우 받으며 잘살고 있으며, 새로 개발자로 진입하는 사람들에겐 데스크탑 자바의 인식은 최악입니다. 그런 상황에서 데스크탑 자바 어플리케이션이 많지 않은 건 당연합니다.

또한 인식상이 아닌 실제적인 문제 역시 분명히 존재합니다. VS와 달리 개발 환경상 패키징 배포의 번잡함은 이미 이야기한바 있습니다. 회사에서 데스크탑 자바를 개발하지 않는다면 오픈소스에서 나와야 하는데, 특히 리눅스 진영의 자바에 대한 널리 퍼진 선입견은 제쳐놓고라도 실제 리눅스를 타겟으로 하는 자바 클라이언트 어플리케이션을 만드는 것은 쉽지 않습니다.

우선 스윙/AWT는 윈도우즈 환경에 비해 글꼴 처리나 속도의 문제도 해결되지 못했고, 무엇보다 패키징이 무척 애매합니다. 자바 런타임은 메인 저장소에 들어있지도 않을 뿐더러 정책상, 윈도우즈에서 하듯 사용하는 모든 의존 라이브러리를 번들할 수도 없습니다.

더구나 많은 수의 자바 데스크탑 어플리케이션이 플러그인이나 동적으로 라이브러리를 참조하는데, 이를 위해 따로 리눅스용 스크립트를 만들고 버전 충돌이나 클래스 로딩의 잠재적 문제를 다 해결하는 건 간단한 일이 아닙니다. 자바 개발자가 다 리눅스 사용자는 아니니까요...

(3) 결론

앞서 나열한 이유로 아직까지 데스크탑 시장에서 자바의 입지는 무척 협소합니다. 그러다 보니 그러한 상황에서 성공적인 데스크탑 어플리케이션은 주로 자바의 특성을 활용해서 동종 제품 중에 최고 수준의 기능을 집약시키거나 아니면 상대적으로 배포 등의 문제가 덜 민감한 대신 유지보수나 백엔드 통합성, 혹은 크로스 플랫폼 특성 등이 중시되는 특화된 시장에서 사용되는 경우가 많습니다.

첫번째의 예를 SWT와 스윙에서 하나씩 꼽아 보자면 대표적으로 Vuez(Azureus)와 JEdit를 들 수 있습니다. 각각 BitTorrent 클라이언트와 편집기 부분에서 극단적으로 기능과 확장성을 강조해서 성공한 경우입니다. 당연히 동종의 다른 제품들보다 기능은 매우 많고 따라서 무겁습니다.

반면 두번째의 예는 일반사용자들이 거의 접할 수 없는 분야에서 주로 사용됩니다. 특히 RCP 관련 어플리케이션들이 그렇습니다만 특정 솔루션의 프론트엔드나 특화된 분야의 클라이언트 제작에 주로 쓰입니다. 그나마 극소수인 실무 자바 데스크탑 개발자는 거의 이런 쪽으로 먹고 삽니다.

이와 같이 데스크탑 시장에서 엔드유저가 쓸만한 자바 어플리케이션이 많지 않은데에는 상당히 복합적인 이유가 있습니다.

그런 부분에 대한 고려없이 '내가 xx와 yy라는 자바 어플리케이션을 써봤는데 느리더라. 그러니 모든 자바 어플리케이션은 느릴 수밖에 없다'라던가 '자바 데스크탑 어플리케이션이 별로 없는 건 느려서 그럴거야, 안그러면 자바로 안만들 이유가 없잖아?'라고 결론 짓는 건 상당히 나이브한 생각입니다.

적어도 이 분야의 문외한인 일반 사용자들보다 오픈소스 개발자가 많은 커뮤니티라면 이와 같은 토론은 기술적, 논리적 근거를 두고 선입관에 대해 오픈된 태도로 이루어져야 한다고 봅니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

좀 보다 건설적인 토론이 되었으면 합니다.

뭐가 더 낫다느니만 따져서 뭐하겠다는 건지 참..

여기서 논쟁의 핵심은 우월성이 아니라

"왜! 플랫폼을 우선순위를 둬서 개발할수 밖에 없는 회사의 마음.."

이란 겁니다.

무슨 자바가 어떻네 하는 동문서답식 뜬구름잡기 논쟁은 논쟁의 질만 하락시키는군요

검색 링크타고 왔다가 글 재미있게 읽었습니다.
좀 지난 쓰레드이긴 하지만..
creativeidler 님 테스트 방법처럼

자바(swing)로 만들어진 오피스(thinkfree writer)와
네이티브C++(wtl)로 만들어진 오피스(한글 2007)의 메뉴를 화살표로 돌려보왔습니다.

메뉴의 갯수와 드롭다운된 리스트 갯수가 서로 틀리므로 밀리초단위의 시간을 비교한다는거는 의미가 없어보일거같구요.

눈이나 느낌으로 체감하기엔 자바로 만들어진 오피스가 느리다는 느낌을 전혀 받을수 없네요.

기능에 대한 속도 테스트는 하지않았습니다. 그건 위에서도 말씀하셨듯이 로직 구현에 따라 다를수 있기 때문이죠.

횟수당 30초 이상씩 10회이상 돌려봤는데 사람이 느끼는 속도 차이는 거의 없다고 봐도 될거같은데요.

주가로 자바로 만들어진 Jedit와
네이티브로 만들어진 Notepad++ 역시 같은 방식으로 비교 해봤는데..

역시나 제눈이나 감각으로는 차이를 못느끼겠네요..

제 컴퓨터 사양은
듀얼코어 2.4
메모리 2기가
지포스 7600 gs

입니다.

메뉴 이동속도말고 다른걸 비교 해보고 싶은데 비교자료같은거라도 있으면 좋겠습니다

이제는 visio를 쓰긴 하지만 제가 자주 사용했던 Together workflow editor(http://www.enhydra.org/workflow/jawe/index.html)가 있는데 몇년째 사용했었지만 여기서 제기된 문제들은 전혀 느끼지 못했는데.. ;;

workbench는 다운받으려니 가입해야 하네요. 그래서 패스.. ;;
ERWin의 Complete Compare를 능가하는 기능이 있다면 가입해서 다운받아 보겠는데..

최근 임베디드 자바를 하면서 느끼는걸 좀 써보려고 합니다.

결론부터 말하자면 자바의 문제점은 위에서 creativeidler님이 말한 문제가 맞다고 생각 합니다.

사실 제가 SE 내부는 보질 않아서 잘 모르겠지만, CDC VM과 CDC-PBP를 구현 하면서 느낀 점들을 쓰자면, graphic layer에서 아무리 빠르게 한다고 해도,

어플리케이션 짜는 사람들이 묘하게 코드를 짜게 되면 느리게 됩니다. 이건 어느 언어에서나 어느 플랫폼에서나 일어날 수 있는 문제죠.

근대 자바 같은 VM이 있는 언어들은 이 묘한 코드에 GC의 garbage collection time이 끼어들면서 문제가 생깁니다.

특히 빠르게 움직이는 menu 같은 부분에서 문제가 일어날 수 있습니다.
어찌 되었건 반복되는 로직 안에서 garbage collection time이 필요한데, 거지같은 코드로 짜 놨다면,(아니면 어쩔수 없이 로직이 복잡했다거나..)
이 사이에 많은 양의 garbage collection이 일어나게 되고, 이 때 프로그램은 정지하고, 쓰래기 수거를 하게 됩니다.

근대 이 시간이 개발자들은 매우 짧다고 생각할 수 있는데, 이 시간이 최소 0.0000001초라고 하더라도 코드에 따라 0.1초 혹은 상황에 따라 0.1초가 넘는 시간이 들어갈 수도 있다는 겁니다.

문제는 위에서 fender님이 말한것처럼 0.5초 정도 이하의 시간은 사용자가 못 느끼느냐... 인데,

제가 BD(Blue-ray Disk)-player에 있는 BD-J framework를 손보면서 느낀점은 사람의 눈은 생각보다 위대 해서,
0.1초 정도만 (연속도 아니고) 잠깐 버벅여도 사용자들이 바로 눈치 챈다는 점입니다. 하물며, 이게 반복되면... 우욱..-_-;;

물론 대다수의 시간을 눈치 못채고 살 수도 있지만, 계속 반복해서 보다보면 언젠가는 느끼게 되는 거죠. 특히 menu 처럼 반복해서 수시로 보는 UI인 경우 더 합니다.

이 menu에 화려한 effect가 들어가 있다면 더 심하게 되죠(BD title은 menu가 매우 화려한 경우가 많습니다.)
바로 이때 자바의 느린 GC response time이 보는 사람을 더럽게 짜증나게 하는 거죠 -_-...

사실 이렇게 써놨지만, 전 CDC만 보고 있는지라 요새 SE 내부가 어떻게 되어 돌아가는지 잘 모릅니다... 하지만 저 부분이 UI를 보는 사람을 충분히 짜증나게 할 수 있다는 데 공감이 가서 이렇게 글을 씁니다.

즉 0.1초 정도면 사람을 충분히 짜증나게 할 수 있다.. 라는 거죠 -_-;

새 생각 :)