viewimageM.php?id=programming&no=29bcc427b78777a16fb3dab004c86b6f0c84ca7046af80d4102901631ae35077262c628585202784e4ac5a5ed307a3a251252f8814187b2cfafc4a4468b60c161d16e5cfdb5b8bf9

보다 의미있는 비판이 되려면 과연 클라이언트 어플리케이션을 만드는데 있어서 자바 언어가 적합한지에 대한 이야기를 하는게 낫지 않을까 싶습니다.

서버 쪽에서의 성공과는 달리 애플릿과 스윙 이후 데스크탑 시장에서 자바는 실패한 솔루션으로 치부되어 왔습니다. 실제로 JEdit이나 Limewire 등 몇몇 어플리케이션을 제외하면 자바로된 널리 쓰이는 데스크탑 응용프로그램은 거의 없습니다.

이유를 따져 보자면 :

(1) JRE를 번들해야 하는 부담감.

(2) 패키징의 어려움 - 어느 누구도 간단한 응용프로그램을 띄우려고 콘솔에서 java -jar ....를 입력하고 싶어 하지 않습니다.

(3) 느린 속도와 메모리 점유율 - 자바 자체가 느리지 않다고 해도 최소한 스윙은 *분명히* 느립니다. 1.4에서 비약적인 발전이 있었지만 네이티브 어플리케이션과 비교할 때 어느 정도 차이는 있습니다. 또한 어플리케이션을 띄울 때마다 새 JVM을 띄우기 때문에 속도에 영향을 줍니다.

(4) 프로페셔널한 UI 디자인이 어려움 - 물론 L&F를 잘 지정해주면 어느정도 예쁜 UI를 만들 수는 있지만 다른 네이티브 어플리케이션과 글꼴이나 다른 여러 요소들의 느낌이 다르게 느껴지는 건 어쩔 수 없습니다. 특히 윈도우즈에서는 상황이 낫지만 리눅스는 글꼴 설정 없이는 한글도 보이지 않고 AA도 먹지 않아 다른 세련된 GTK 어플리케이션과 비교했을 때 조잡한 느낌을 줍니다.

이런 이유로 이제까지 데스크탑 시장에서 자바는 별다른 힘을 쓰지 못했다고 봅니다. 하지만 특히 최근에 와서 SWT/JFace와 GCJ 등의 등장으로 상황이 급격히 나아지고 있다고 판단 됩니다. 한 가지씩 따져본다면 :

(1) 고속 인터넷 보급과 윈도우즈 플랫폼에서의 자동 업데이트, 네트워크 인스톨 지원으로 JRE 다운로드의 부담이 줄었습니다. 현재 윈도우즈에서 JRE 설치 프로그램의 크기는 약 400k 정도로 알고 있습니다. 또한 GCJ를 써서 컴파일 할 경우 아예 JRE 자체를 필요로 하지 않습니다. 따라서 리눅스의 경우 JRE 없이 RPM이나 DEB으로 번들할 수도 있습니다.

(2) GCJ를 통해 exe와 같은 네이티브 실행파일을 만들 수 있습니다. 이를 설치프로그램이나 RPM, DEB 등으로 패키징 할 경우 기타 다른 언어로 만든 경우와 같이 쉽게 패키징이 됩니다. 혹은 자바로 만들더라도 InstallAnywhere나 JSmooth 등으로 JRE까지 포함해서 깔끔하게 설치할 수 있습니다.

(3) JRE 1.5 대에 공유 VM이 들어갈 예정입니다. 이미 1.4대에서 VM의 시작 속도가 상당히 개선됐고 만일 공유 VM이 일반화 된다면 경우에 따라선 운영체제 시작과 함께 JRE를 백그라운드에서 시작할 수도 있을 것입니다.

(4) SWT/JFace를 사용하면 윈도우즈, 리눅스, 맥OSX 등에서 네이티브한 UI를 구현할 수 있습니다. 특히 최근 거의 VB와 흡사한 환경에서 SWT로 UI를 디자인하는 이클립스 플러그인들이 속속 개발되고 있어 상황은 더 나아지리라고 봅니다.

이런 단점들이 극복되면 자바 특유의 장점 - 방대한 써드파티 라이브러리, 높은 생산성 및 유지보수성, 크로스 플랫폼 등등이 영향을 주어 데스크탑 시장에서도 자바 어플리케이션이 많이 늘어날 것으로 생각합니다.

이것이 레알이라면 어서 자바응용프로글매을 개발하도록하세요
데스크탑PC에도 자바가 정ㅋ벅ㅋ해야져