IT/모바일
추석이 껴서 이번에는 두 주 소식을 묶었습니다. 혹시 기다렸던 분이 계시다면 사전 예고 해드리지 못해 죄송합니다. 대신 이번 소식도 무척 알차게 꾸며보았습니다. 부록으로 스팍 64비트 모드 특집도 다루었으니 끝까지 읽어보시길 바랍니다.
스윙 커넥션(Swing connection)은 우리나라에서 유독 힘을 못쓰고 있는 스윙 기술에 대한 썬의 광고판입니다. 저도 아주 가끔 들려보는데, 오늘 들어가보니 소식들이 많이 늘었더군요. 특히 주목을 끄는 점은 J2SE 1.4의 등장과 함께 스윙의 위상 변화-빨라진 속도와 다듬어진 기능-를 적극적으로 알리고 있는 스윙 명장면(Swing Sightings)입니다. 아주 다양한 스윙 애플리케이션과 사용례를 보여주는데 벌써 4회에 이를 정도로 내용도 많고 항상 마지막 부분에서는 재밌는(?) 기사가 실려있더군요. 미국 전산 문화를 피부로 느껴볼 수 있어 삥끗 웃게 됩니다. 그건 그렇고, 이러한 썬의 스윙 전략에서 개발자로서 아주 묘한 기분을 전해주는 것은 바로 자바 웹 스타트의 활용도입니다. 위의 자바 명장면 페이지를 보면 단순히 소개된 애플리케이션이나 사이트의 스냅샵(예제 화면)만 보여주는 것이 아니라 실제로 돌려볼 수 있게 해주는데 여기에 자바 웹 스타트가 쓰입니다. 저도 최근에 스윙을 기반으로 프로젝트를 수행하는 선배의 질문에 몇차례 답한 적이 있는데, Q: 이런이런 것은 안될까? A: 일단 해보죠... 하고 동동동 짜고 나면 그 결과를 선배에게 보여줘야하는데, 저는 일본에 있고 선배는 한국에 있으니 만나서 할 수 없죠. 그래서, A: 선배, 자바 웹 스타트를 설치하세요. 그리고 나서 제가 알려드리는 URL에 접속하세요. Q: OK. 그러면 저는 테스트 예제를 보통의 자바 애플리케이션처럼 다 만들고 나서 자바 웹 스타트로 불러들일 수 있도록 설명서를 쓰고 제 웹 서버에 올리면 끝납니다. 이러한 원격 개발 논의의 도구로 자바 웹 스타트는 매우 훌륭합니다. 이미 FreeHEP 자바 라이브러리 사이트는 자신들의 애플리케이션 프레임워크를 활용한 예제들을 자바 웹 스타트 형식으로 제공하고 있습니다. 특별히 소스나 바이너리를 받아 설치나 컴파일, 커스터마이즈같은 귀찮은 작업을 하지 않아도 단순히 자바 웹 스타트만 깔고 링크를 클릭하기만 하면 예제 프로그램의 실물을 구경할 수 있으니까요. 이미 미국에서는 스윙 명장면 사이트가 보여주듯이 각계 연구에 스윙이 활약하기 시작했으며 자바 웹 스타트도 그 흐름에 일조하고 있습니다. 앞으로 다양한 산학 협동 연구나 대학-연구소의 연구에서 탄력 넘치고 객체 지향적인 자바가 많이 쓰이며 특히 GUI와 그래픽이 많이 소요되는 과학 분야에서 스윙과 자바 웹 스타트가 더욱 멋진 활약을 보이도록 자바 업계의 관심과 지원이 이루어져야하겠습니다. (특히 우리나라에서의 비상용 분야의 자바 지원은 빈약하기 그지없습니다. 아직도 C와 C++로 구현의 곤욕을 치루어야하는 많은 대학생, 대학원생, 그리고 연구원들을 위해 자바의 강력하고 편리한 제반 관련 기술들의 홍보와 한글 문서 제공, 컨퍼런스 개최등이 이루어어진다면 자바의 기반이 더욱 공고히 쌓일 것입니다. 단언컨데 이는 절대 "돈이 안된다"고 우습게 볼 것이 아니며, "기초 과학"을 경시하는 우리나라 과학 기술의 기형성과 일맥 상통하는 현상이기때문에 반드시 지양해야한다고 생각합니다.)
버그 시커(BugSeeker)라는 디버그 전문 프로그램을 소개합니다. 기존의 통합 개발 환경(Integrated Development Environment-IDE)도 물론 디버그 기능을 지원하지만, 간단하게 짜고 디버그를 해보고 싶은 사람에게는 지나치게 무거운 감이 없지 않아 있습니다. 그렇다고 JDK에 기본 포함되어있는 jdb를 쓰자니 영 익숙하지도 않고 뭐가 뭔지 불편할 뿐이지요. 저도 솔직히 고백하건데 단지 공부할때라쳐도 디버그 툴은 거의 아니 전혀 쓰지 않습니다. 그 이유는,
앞서 버그 시커라는 범용 디버거(웹쪽은 좀 약했지만)를 소개했었는데, 오늘 자바스크립트 닷 컴에서 오는 뉴스 메일을 받아보니 톰켓 전용 디버기인 Communique JSP Debugger (cqjd)가 있어서 한번 받아서 돌려봤더니 썩 괜찮더군요. 원리는 버그 시커와 마찬가지로 JPDA를 썼는데 흥미로운 점은 디버거 자체는 자바가 아닌 C++으로 되어있다고 합니다. 그래서 그런지 UI도 상당히 윈도우틱(?)하고 빠르군요. JSP소스에 정지점을 설정하고 그 JSP페이지를 부르면 자동으로 해당 페이지의 실행과 동시에 디버깅이 이루어집니다. 점점 디버깅 도구들이 많이 나오는 것을 보면 그간의 자바 디버깅이 얼마나 힘들었던지가 역으로 증명되는 셈이군요. 만든 회사는 스위스에 근거하는데 제품명은 묘하게 불어를 썼군요. (하긴 스위스는 불어, 독어, 이탈리아어 공용 지대니까.) CQJP를 띄우기전에 톰켓의 work디렉토리에 있는 기존의 JSP 번역 소스와 컴파일 클래스를 싹 다 지우시기 바랍니다. 안그러면 JSP의 로컬 변수가 관찰되지 않는 등의 오동작이 일어나기도 합니다. (너무 당연한 얘기여서 그랬는지 문서에는 그런 지적이 없더군요.) 그리고 J2SE 1.4(멀린)에서는 -classic 옵션이 java에서 빠졌습니다. CQJP문서에 보면 -classic 옵션을 달아서 톰켓을 실행하라고 하는데 멀린과 함께 쓰시는 분들은 -classic 옵션을 빼세요. 커뮤니크 JSP 디버거(CQJP)는 여러모로 번뜩이는 아이디어가 두드러집니다. 우선 대개의 디버거들이 순수 자바내지는 자바 GUI를 쓰는 통에 디버깅 대상 자바 애플리케이션과 함께 뜨면 무척 무거워지는 현상이 일반적이죠. 그런데 CQJP는 JPDA 구조의 인터페이스만을 활용할 뿐, 자기자신이 자바여야할 필요성이 없음을 인지하고(실제로 JPDA는 오히려 네이티브 코드와의 연계를 많이 설명하고 있음) 아주 깔끔하게 타켓 애플리케이션과 날아다니고 있습니다. 특히나 무겁고도 무거운 서블릿 컨테이너들은 디버깅할 때 아주 쥐약이죠. 제이빌더에도 디버거와 서블릿 컨테이너가 함께 들어있지만, 완전 자바화된 제이빌더에 서블릿 컨테이너에 디버거 연결까지 온통 자바 프로세스로 떠버리면 제아무리 좋은 개발환경이라도 설설 기기는 마찬가지입니다. 개인적으로 아주 상쾌한 모습을 보여주었던 제이빌더 3에 애착이 가는데요, 이식성도 좋지만, 사실상 거의 윈도우즈 운영체계하에서 개발 작업을 하는 입장에서는 빠른 작업 속도가 더 절실합니다. CQJP는 톰켓에 TOMCAT_OPTS라는 옵션만 살짝 추가하면 되기때문에 일말의 복잡한 내부 설정 변경이나 기타 위험스러운 건드림(?)은 전혀 필요없습니다. 역시 JPDA의 존재는 여기서 빛을 발하는데 대신 JVM이 JDK 1.3이상이기를 요구하니 트레이드오프가 없지는 않군요. 이밖에도 작고도 간편한 운영방식의 면면이 이 디버거의 미래를 밝게 하고 있다고 생각합니다. 꼭 이 제품이 잘 팔리거나 대박을 내진 않더라도, 다른 디버거들에게 뭔가 자극이 될 수는 있겠죠.
포르테 포 자바 3가 J2SE 1.4 베타2와 함께 번들되어 나왔습니다. 가장 큰 특징이라면 역시 J2SE 1.4의 GUI강화를 그대로 이용할 수 있다는 점이고, 특히 휠마우스 지원은 순수 자바 개발 도구로서는 처음이지않나 싶군요. 아주 편리한 개발이 가능한 공개무료 도구입니다. 하지만 아직까지도 JSP에서는 들여쓰기(indentation)을 지원하지 않고 있군요. JSP작업이 많은 우리나라 현실에서 다소 맥빠지는 현상이기는 하지만, 여전히 장점이 많은 프로그램입니다. 포르테 2보다 더 커진 덩치덕분에 다소 무거워진 느낌도 들지만, 필요없는 컴포넌트나 모듈은 뗄 수 있기 때문에 자신이 필요한 것들만 모아 띄우면 충분히 가볍고 빠른 작업을 할 수 있다는 것도 넷빈(NetBean)기반의 포르테적 특징입니다. 아직은 포르테 포 자바 3 + 멀린(J2SE 1.4)의 합작이 시작 단계여서 버그와 미비점을 썬도 고백하고 있지만, 곧 패치를 통해 어느정도 쓸만한 수준으로 보안토록 한다니 올 4/4분기안으로 좋은 결과가 나오리라 점쳐봅니다.
특집!-멀린의 64비트 지원능력은 얼마나 될까요? 썬 울스라 스팍 IIe 500MHz, 메모리 256MB (대강 썬의 블레이드 100 웍스테이션급) 에서 J2SE 1.4 베타2를 32비트 버전 + 64비트 지원으로 설치해보았습니다. 미리 필요한 패치를 모두 끝낸후(특이하게 썬 솔라리스 운영체계용 J2SE은 설치전에 J2SE를 위한 운영체계 패치를 따로 해주죠. 아무래도 자신들이 만든 운영체계다보니 JVM에 최적화된 뭔가(?)를 하는 것인지...) 설치는 리눅스 수준으로 수월했습니다. 이제 두근거리는 64비트 테스트, 다음과 같은 예제를 우선 돌려보았습니다.
간단하게 1부터 1억까지의 정수를 합하는 계산을 취해보았는데, 얼라라? 어찌된 일인지 64비트 모드로 실행하면 더 느린 것입니다. 그것도 두세배 가까히. 이상하다 해서 멀린 문서를 확인해본 결과,
(sparc9v-64비트를 지원하는)옛날 솔라리스 운영체계에서는 특별히 부팅시에 64비트 커널을 쓰겠다고 명시해주어야한답니다. /platform/sun4v/boot.conf를 보면 자세히 설명이 나오는데 단도직입적으로 마지막 한줄의 주석을 빼고 reboot하면 64비트로 운영체계가 뜹니다.
이렇게 하고 나서 위의 예제를 돌려보면
-d64를 붙인 java가 64비트 모드입니다. 엄청나지요. 여러번 테스트해봐도 비슷한 시간들이 나옵니다. 대강 800:20정도로 보면 40분의 1이 빠른 셈이죠. 이번에는 롱(long)형을 한번 테스트 해보았습니다.
long형답게 1부터 10억까지 합을 내보았는데 결과는
로 대강 3배정도 64비트가 빠르게 나타났습니다. 또한 64비트 서버 모드로 JVM을 기동시에는 총 4기가 바이트 이상의 힙 메모리 확보가 가능하여 더욱 튼튼한 애플리케이션 서비스가 가능합니다.
또한 리눅스와는 달리 솔라리스에서 자바는 진정한 "하나의 프로세스"입니다. 실제로 리눅스에서 톰켓을 띄워보면 톰켓 엔진 시동 자바 프로세스밑에 가지친 수십개의 쓰레드 프로세스(혹은 포크트(forked) process)가 줄을 잇지요. 그러나 솔라리스의 경우에는 ps명령으로 확인해보아도 달랑 하나의 java 프로세스만이 눈에 띕니다. 이 또한 프로세스 관리나 운영 차원에서 몹시 반가운 모습이기도 하구요.
역시 자바 기반 서비스를 하는 데 있어서는 아직 리눅스는 좀 더 단련이 필요하다고 여겨집니다. 블랙다운과 썬이 함께 리눅스용 자바 기술을 개발해나간지도 얼마되지 않았으니 너무 기대가 큰 것도 사실입니다. 현재로서는 저가의 실용적인 64비트 자바 환경도 썬 스팍 솔라리가 되겠지요. 일본에서는 썬 스팍 솔라리스 보급용 엔트리 모델인 넷트라(Netra) X1이 우리돈으로 약 200만원부터 시작하고 있습니다. 물론 리눅스 머신보다는 훨씬(?) 비싸지만, 자바 성능과 안정성면에서 무척 부러운 면들이 많았습니다.
문제는 썬 스팍 솔라리스가 좋은 것은 알지만, 리눅스만큼도 대중화되어있지 않고, 관리와 운용에 비용이 많이 들어간다(혹은 갈지도 모른다)는 우려입니다. 서버 시장에서 점유율 1위를 차지하고 있다는 통계와는 다르게 우리나라 IT대중의 인식은 "썬은 단지 (큰) 기업 대상, 아니면 자바"로 통하고 있습니다. 반면 놀랍게도 제가 지금 일하고 있는 일본에서는 매월 나오는 썬 월드라는 썬 스팍 솔라리스 기술 전문 잡지가 있습니다. 그뿐아니라 스팍 솔라리스에 대한 책들도 상당히 많은데, 절대 리눅스에 뒤질 수준이 아닙니다. 리눅스나 솔라리스나 다 같은 유닉스이니 기본을 익혀두면 어디든 써먹을 수 있어 좋고, 각 특화된 유닉스별로 관리 기술과 운용의 묘를 터득할 수 있으면 더 좋지 않을까요? 리눅스의 눈부신 발전과 더불어 썬 솔라리스의 "한발 다가선" 대중과의 만남을 기대해봅니다. 큰 회사뿐만 아니라 중소업체에도 훌륭한 서버 머신과 운영체계 기술의 배치 기회를 부여한다면 자바도 "느리다"던가 "불안하다"던가 "비싸다"던가 하는 불평을 듣지 않겠지요.
가을이 끝나갑니다. 요사이 자바에 대한 위상 논쟁이 활성화되고 있습니다. 그만큼 자바를 아끼는 분들이 많다는 증거겠지요. 무척이나 어려운 시기, 곧 추운 겨울마저 다가옵니다. 자신의 의견을 개진하는 것은 물론 진정한 민주주의의 실천으로 무척 바람직하지만, "무엇이 절대 옳다"는 전제아래 모든 이를 압도하려는 자세는 이제 충분하지 않았나싶습니다. 남을 이해하려고 얼마나 노력을 해보았습니까? 그 과정의 훈훈함이 올 겨울을 따뜻하게 하기를 빕니다.
스윙 커넥션(Swing connection)은 우리나라에서 유독 힘을 못쓰고 있는 스윙 기술에 대한 썬의 광고판입니다. 저도 아주 가끔 들려보는데, 오늘 들어가보니 소식들이 많이 늘었더군요. 특히 주목을 끄는 점은 J2SE 1.4의 등장과 함께 스윙의 위상 변화-빨라진 속도와 다듬어진 기능-를 적극적으로 알리고 있는 스윙 명장면(Swing Sightings)입니다. 아주 다양한 스윙 애플리케이션과 사용례를 보여주는데 벌써 4회에 이를 정도로 내용도 많고 항상 마지막 부분에서는 재밌는(?) 기사가 실려있더군요. 미국 전산 문화를 피부로 느껴볼 수 있어 삥끗 웃게 됩니다. 그건 그렇고, 이러한 썬의 스윙 전략에서 개발자로서 아주 묘한 기분을 전해주는 것은 바로 자바 웹 스타트의 활용도입니다. 위의 자바 명장면 페이지를 보면 단순히 소개된 애플리케이션이나 사이트의 스냅샵(예제 화면)만 보여주는 것이 아니라 실제로 돌려볼 수 있게 해주는데 여기에 자바 웹 스타트가 쓰입니다. 저도 최근에 스윙을 기반으로 프로젝트를 수행하는 선배의 질문에 몇차례 답한 적이 있는데, Q: 이런이런 것은 안될까? A: 일단 해보죠... 하고 동동동 짜고 나면 그 결과를 선배에게 보여줘야하는데, 저는 일본에 있고 선배는 한국에 있으니 만나서 할 수 없죠. 그래서, A: 선배, 자바 웹 스타트를 설치하세요. 그리고 나서 제가 알려드리는 URL에 접속하세요. Q: OK. 그러면 저는 테스트 예제를 보통의 자바 애플리케이션처럼 다 만들고 나서 자바 웹 스타트로 불러들일 수 있도록 설명서를 쓰고 제 웹 서버에 올리면 끝납니다. 이러한 원격 개발 논의의 도구로 자바 웹 스타트는 매우 훌륭합니다. 이미 FreeHEP 자바 라이브러리 사이트는 자신들의 애플리케이션 프레임워크를 활용한 예제들을 자바 웹 스타트 형식으로 제공하고 있습니다. 특별히 소스나 바이너리를 받아 설치나 컴파일, 커스터마이즈같은 귀찮은 작업을 하지 않아도 단순히 자바 웹 스타트만 깔고 링크를 클릭하기만 하면 예제 프로그램의 실물을 구경할 수 있으니까요. 이미 미국에서는 스윙 명장면 사이트가 보여주듯이 각계 연구에 스윙이 활약하기 시작했으며 자바 웹 스타트도 그 흐름에 일조하고 있습니다. 앞으로 다양한 산학 협동 연구나 대학-연구소의 연구에서 탄력 넘치고 객체 지향적인 자바가 많이 쓰이며 특히 GUI와 그래픽이 많이 소요되는 과학 분야에서 스윙과 자바 웹 스타트가 더욱 멋진 활약을 보이도록 자바 업계의 관심과 지원이 이루어져야하겠습니다. (특히 우리나라에서의 비상용 분야의 자바 지원은 빈약하기 그지없습니다. 아직도 C와 C++로 구현의 곤욕을 치루어야하는 많은 대학생, 대학원생, 그리고 연구원들을 위해 자바의 강력하고 편리한 제반 관련 기술들의 홍보와 한글 문서 제공, 컨퍼런스 개최등이 이루어어진다면 자바의 기반이 더욱 공고히 쌓일 것입니다. 단언컨데 이는 절대 "돈이 안된다"고 우습게 볼 것이 아니며, "기초 과학"을 경시하는 우리나라 과학 기술의 기형성과 일맥 상통하는 현상이기때문에 반드시 지양해야한다고 생각합니다.)
버그 시커(BugSeeker)라는 디버그 전문 프로그램을 소개합니다. 기존의 통합 개발 환경(Integrated Development Environment-IDE)도 물론 디버그 기능을 지원하지만, 간단하게 짜고 디버그를 해보고 싶은 사람에게는 지나치게 무거운 감이 없지 않아 있습니다. 그렇다고 JDK에 기본 포함되어있는 jdb를 쓰자니 영 익숙하지도 않고 뭐가 뭔지 불편할 뿐이지요. 저도 솔직히 고백하건데 단지 공부할때라쳐도 디버그 툴은 거의 아니 전혀 쓰지 않습니다. 그 이유는,
- 디버그툴을 어떻게 쓰는지 잘 모르고,
- 큰맘 먹고 방법을 알아도 System.out.println의 편리함에 익숙해져버린지라 잘 안쓰게 되어 곧 잊어버리는
- 악순환을 반복하고 있습니다.
- 대체로 디버거들이 상용 컨테이너를 잘 지원하지 못하고, 그나마 지원하는 것들도 버전이 낮은 경우가 허다하다.
- 다행이 디버거와 컨테이너의 궁합이 잘 맞는다고 쳐도, 서블릿과 JSP의 특성상 쓰레드와 요청을 넘다들기가 까다롭다.
- 디버거와 연동하다보니 테스트 자체가 심하게 무거워지고 불안한 모습을 보여 마음대로 실험해보지 못한다.
- 단말기 에뮬레이터가 디버거와 함께 잘 돌아가야하는데, 에뮬레이터 자체의 폐쇄적인 구조(어떤 경우에는 자바로 짜여지지 않은 경우도 있다.) 덕분에(?) 설정이 아주 환상적(불가능을 포함)이다.
- 이러한 이유에서였는지 최근에 J2ME 무선 도구(Wireless Toolkit)은 디버그 도구까지 지원하고 나섰으나 이것은 어디까지나 CLDC+MIDP, 즉 지극히 표준적인 상황을 감안하지 않으면 아무 소용이 없고, 실제 다양한 핸드폰에서 돌려봐야하는 현실과는 여전히 거리가 멀다.
- 웹 애플리케이션과 마찬가지지만 한마디로 "너무 무거워진다."
- 자바 언어 개발 역사가 이제 10년도 체 되지 않았다.
- 자바 개발 도구가 공개, 무료라는 본질은 역으로 말하면 통일적인 디버깅 방식, 상용의 고품질(이런 현상은 국공영와 민영의 차이를 떠올리면 쉽게 수긍이 감)을 기대할 수 없었다는 것이다.
- 따라서 중구난망의 디버깅 도구가 판을 치기는 치는데 결정적으로 아주 쓸만한 물건이 없었고,
- 자바 언어 개발 역사를 비추어보면 아직 자바 디버깅 도구 시장과 요구도 그닥 크지 않았다는 현실,
- 그리고 현업에서 디버그 도구를 거의 쓰지 않는다는... (적어도 내가 경험해본 한국의 개발 현장에서는, 동료 개발자들이 디버그 도구를 쓰는 것을 본 적도 없고, 썼다고(써봤다고) 하는 사람도 없었다.) 관습(?)
- 결론적으로 마인드 부재. (전체적인 개발 과정과 결과의 질(quality)에 대한 외면. 공기(工期) 맞추는데 급급하고 "돌아가기만 하면 된다"는 식의 현실이 디버깅의 중요성을 무시하고, 그결과 불가피한 디버깅 작업의 시간 자체는 늘어나버려 막판 개발 연장과 엉망인(잠재적으로) 결과물의 양산을 부추긴다.)
- 코드 생산 기술은 배운다. 하지만 디버깅은 배우지 않는다. 현업에서 터득해라...라고 하기에는 너무도 무책임한 현실이다. 결국 System.out.println이다. 프로젝트에서 실무 개발자들에 중요한 것은 개발 환경이다. 그 개발 환경에 적합한 디버깅 도구 환경을 숙지하고 적시적소에 테스트와 디버깅을 가미한다면 개발은 가속력을 십분 얻는다. 처음에는 익숙해지느라 시간도 걸리고 도구 사주랴 가르치랴 비용이 더 드는 것 같지만, 결국 "조삼모사"와 같은 꼴이나 다름이 없다. 일주일 개발하는 것도 아니고, (일주일 개발한다고 해도 필요하지만) 몇달, 몇년을 할 일에 근시안적인 태도를 밑바닥 개발자들은 절실히 깨우치거늘 왜 윗분들은 감감 무소식인걸까.
앞서 버그 시커라는 범용 디버거(웹쪽은 좀 약했지만)를 소개했었는데, 오늘 자바스크립트 닷 컴에서 오는 뉴스 메일을 받아보니 톰켓 전용 디버기인 Communique JSP Debugger (cqjd)가 있어서 한번 받아서 돌려봤더니 썩 괜찮더군요. 원리는 버그 시커와 마찬가지로 JPDA를 썼는데 흥미로운 점은 디버거 자체는 자바가 아닌 C++으로 되어있다고 합니다. 그래서 그런지 UI도 상당히 윈도우틱(?)하고 빠르군요. JSP소스에 정지점을 설정하고 그 JSP페이지를 부르면 자동으로 해당 페이지의 실행과 동시에 디버깅이 이루어집니다. 점점 디버깅 도구들이 많이 나오는 것을 보면 그간의 자바 디버깅이 얼마나 힘들었던지가 역으로 증명되는 셈이군요. 만든 회사는 스위스에 근거하는데 제품명은 묘하게 불어를 썼군요. (하긴 스위스는 불어, 독어, 이탈리아어 공용 지대니까.) CQJP를 띄우기전에 톰켓의 work디렉토리에 있는 기존의 JSP 번역 소스와 컴파일 클래스를 싹 다 지우시기 바랍니다. 안그러면 JSP의 로컬 변수가 관찰되지 않는 등의 오동작이 일어나기도 합니다. (너무 당연한 얘기여서 그랬는지 문서에는 그런 지적이 없더군요.) 그리고 J2SE 1.4(멀린)에서는 -classic 옵션이 java에서 빠졌습니다. CQJP문서에 보면 -classic 옵션을 달아서 톰켓을 실행하라고 하는데 멀린과 함께 쓰시는 분들은 -classic 옵션을 빼세요. 커뮤니크 JSP 디버거(CQJP)는 여러모로 번뜩이는 아이디어가 두드러집니다. 우선 대개의 디버거들이 순수 자바내지는 자바 GUI를 쓰는 통에 디버깅 대상 자바 애플리케이션과 함께 뜨면 무척 무거워지는 현상이 일반적이죠. 그런데 CQJP는 JPDA 구조의 인터페이스만을 활용할 뿐, 자기자신이 자바여야할 필요성이 없음을 인지하고(실제로 JPDA는 오히려 네이티브 코드와의 연계를 많이 설명하고 있음) 아주 깔끔하게 타켓 애플리케이션과 날아다니고 있습니다. 특히나 무겁고도 무거운 서블릿 컨테이너들은 디버깅할 때 아주 쥐약이죠. 제이빌더에도 디버거와 서블릿 컨테이너가 함께 들어있지만, 완전 자바화된 제이빌더에 서블릿 컨테이너에 디버거 연결까지 온통 자바 프로세스로 떠버리면 제아무리 좋은 개발환경이라도 설설 기기는 마찬가지입니다. 개인적으로 아주 상쾌한 모습을 보여주었던 제이빌더 3에 애착이 가는데요, 이식성도 좋지만, 사실상 거의 윈도우즈 운영체계하에서 개발 작업을 하는 입장에서는 빠른 작업 속도가 더 절실합니다. CQJP는 톰켓에 TOMCAT_OPTS라는 옵션만 살짝 추가하면 되기때문에 일말의 복잡한 내부 설정 변경이나 기타 위험스러운 건드림(?)은 전혀 필요없습니다. 역시 JPDA의 존재는 여기서 빛을 발하는데 대신 JVM이 JDK 1.3이상이기를 요구하니 트레이드오프가 없지는 않군요. 이밖에도 작고도 간편한 운영방식의 면면이 이 디버거의 미래를 밝게 하고 있다고 생각합니다. 꼭 이 제품이 잘 팔리거나 대박을 내진 않더라도, 다른 디버거들에게 뭔가 자극이 될 수는 있겠죠.
포르테 포 자바 3가 J2SE 1.4 베타2와 함께 번들되어 나왔습니다. 가장 큰 특징이라면 역시 J2SE 1.4의 GUI강화를 그대로 이용할 수 있다는 점이고, 특히 휠마우스 지원은 순수 자바 개발 도구로서는 처음이지않나 싶군요. 아주 편리한 개발이 가능한 공개무료 도구입니다. 하지만 아직까지도 JSP에서는 들여쓰기(indentation)을 지원하지 않고 있군요. JSP작업이 많은 우리나라 현실에서 다소 맥빠지는 현상이기는 하지만, 여전히 장점이 많은 프로그램입니다. 포르테 2보다 더 커진 덩치덕분에 다소 무거워진 느낌도 들지만, 필요없는 컴포넌트나 모듈은 뗄 수 있기 때문에 자신이 필요한 것들만 모아 띄우면 충분히 가볍고 빠른 작업을 할 수 있다는 것도 넷빈(NetBean)기반의 포르테적 특징입니다. 아직은 포르테 포 자바 3 + 멀린(J2SE 1.4)의 합작이 시작 단계여서 버그와 미비점을 썬도 고백하고 있지만, 곧 패치를 통해 어느정도 쓸만한 수준으로 보안토록 한다니 올 4/4분기안으로 좋은 결과가 나오리라 점쳐봅니다.
특집!-멀린의 64비트 지원능력은 얼마나 될까요? 썬 울스라 스팍 IIe 500MHz, 메모리 256MB (대강 썬의 블레이드 100 웍스테이션급) 에서 J2SE 1.4 베타2를 32비트 버전 + 64비트 지원으로 설치해보았습니다. 미리 필요한 패치를 모두 끝낸후(특이하게 썬 솔라리스 운영체계용 J2SE은 설치전에 J2SE를 위한 운영체계 패치를 따로 해주죠. 아무래도 자신들이 만든 운영체계다보니 JVM에 최적화된 뭔가(?)를 하는 것인지...) 설치는 리눅스 수준으로 수월했습니다. 이제 두근거리는 64비트 테스트, 다음과 같은 예제를 우선 돌려보았습니다.
public class TestLoopInt
{
public static void main(String[] args)
{
long startTime = System.currentTimeMillis();
int a = 0;
for (int i = 0; i < 100000000; i ++)
{
a+= i;
}
long endTime = System.currentTimeMillis();
System.out.println(endTime + " - " + startTime + " = " + (endTime - startTime));
}
}
|
bash-2.03$ java TestLoopInt 1002730686089 - 1002730685273 = 816 bash-2.03$ java -d64 TestLoopInt 1002730695734 - 1002730695715 = 19 |
public class TestLoopLong
{
public static void main(String[] args)
{
long startTime = System.currentTimeMillis();
long a = 0;
for (long i = 0; i < 1000000000; i ++)
{
a+= i;
}
long endTime = System.currentTimeMillis();
System.out.println(endTime + " - " + startTime + " = " + (endTime - startTime));
}
}
|
bash-2.03$ java TestLoopLong 1002730896823 - 1002730850432 = 46391 bash-2.03$ java -d64 TestLoopLong 1002730921008 - 1002730904822 = 16186 |
가을이 끝나갑니다. 요사이 자바에 대한 위상 논쟁이 활성화되고 있습니다. 그만큼 자바를 아끼는 분들이 많다는 증거겠지요. 무척이나 어려운 시기, 곧 추운 겨울마저 다가옵니다. 자신의 의견을 개진하는 것은 물론 진정한 민주주의의 실천으로 무척 바람직하지만, "무엇이 절대 옳다"는 전제아래 모든 이를 압도하려는 자세는 이제 충분하지 않았나싶습니다. 남을 이해하려고 얼마나 노력을 해보았습니까? 그 과정의 훈훈함이 올 겨울을 따뜻하게 하기를 빕니다.
"도망치면 안된다." - 에반겔리온, 신지
TAG :
최신 콘텐츠