[지디넷코리아]새로운 용어를 만드는 것은 쉬우면서도 어려운 일이다. 웹2.0도 그렇다. 누가 감히 웹이라는 일반화된 명사에 버전번호를 붙일 생각을 했겠는가?

그러나 한번 물꼬가 트이면 일반화까지는 일사천리다. 더욱이 1990년대 중반부터 대중화에 성공한 인터넷 관련 기술에 있어 2000년대 중반은 확실히 전환점으로 삼기 충분했고, 거기에 2.0이라는 접미사는 훌륭한 조합이었다. 우연인지는 몰라도 올해 많은 자바 기술이 큰 변화를 겪었다. 자바 웹 서비스를 이루는 새로운 표준들이 대거 등장하여 필자는 그것들을 한 데 묶어 자바 웹 서비스 2.0이라고 부르기 시작했다(weblogs.java.net/blog/iasandcb/archive/2006/03/java_web_servic.html 참조).

그런데 이번에는 또 다른 새로운 이름이 필요한 때가 되었다. 작년과 올해에 거쳐 자바의 모든 면에서 새로운 국면을 맞게 된 탓이다. 그래서, 나는 다시 과감히 자바에 ‘2.0’이라는 버전을 붙여보고자 한다. 1부에서는 자바 2.0이 자바 1.0과 어떻게 다른 지와 자바 2.0 시대에 개발자들이 주목해야 할 것은 무엇인지에 대해 알아보자.

새 이름을 얻은 자바 플랫폼

자바의 이름이 바뀌었다. J2ME, J2SE, J2EE, 자바가 실험실 수준을 벗어나 본격적으로 주목을 받던 1990년대 말부터 쓰이기 시작하여 격변의 IT계에서는 보기 드물게 오랜 수명을 누린 이름이다.

마이크로소프트(이하 MS)의 윈도우만 봐도 윈도우 95, 98, 2000, 2003이라는 연도 기반 이름과 더불어 중간중간 ME, XP, 이제는 비스타(Vista)까지 쓰이며 버전 번호라는 일반적인 명명법과는 거리가 먼 행보를 거듭해 왔다. 서비스 팩이라는 수단으로 밋밋한 이름에 힘을 주는 센스도 선보였다.

그에 비하면 자바는 J2SE만 보더라도 1.1에서 1.2로 현대화된 이후로 1.4와 1.5에 이르면서 상당히 큰 변화가 있었음에도 계속 1.x의 버전 번호를 고수해왔다. 개인적으로 J2SE에서의 2라는 숫자는 매우 제한적이라고 생각했다. 도대체 언제까지 자바2라고 할 것인지 궁금하기까지 했다. J2SE 1.4는 코어 플랫폼에 있어 가장 많고 중요한 API 추가가 있었고, J2SE 1.5는 자바 언어 자체에 심대한 발전이 있었다. 이미 이때부터 2라는 테두리로 묶기에는 커져버렸던 것이 아닐까? 그래서 필자는 J2SE 1.4부터는 1.4대신 4.0을 써야 하는 것이 아닌가 하는 생각이 들 정도였다.

이런 작은 단위의 버전 업이 안정감을 나타낼 수는 있겠지만 동시에 더딘 성장세를 시사할 수도 있는 탓이다. 실제로는 대폭 변했는데도 버전 번호를 낮춰 별로 변한 것이 없다는 식의 태도는 오히려 점점 더 많은 문제를 해결해야 하는 범용 소프트웨어에 있어 답답하다는 인상을 주기에 충분했다.

J2EE도 상황은 마찬가지여서 1.2로 시작하여 1.3에서 EJB 2.0으로 크게 도약한 분산 컴포넌트 기술은 1.4에서 웹 서비스 지원의 추가로 날개를 달았지만 여전히 1.x라는 빈약한 버전을 가지고 있었다.

그래서, J2SE 1.6과 J2EE 1.5부터는 J2라는 약자를 버리고 자바라는 완전한 이름으로 돌아옴과 동시에 1.6대신 6, 1.5대신 5라는 과감한 버전 업그레이드를 단행하게 되었다. 아직도 여전히 J2SE와 J2EE라는 말은 자바 플랫폼의 대명사로 많이 쓰이고 있지만, 새 술을 새 부대에 담듯이 자바SE 6와 자바EE 5는 그 새로운 이름과 함께 ‘2’라는 굴레를 벗어나 도약의 로드맵을 사용자에게 제시하는 첫걸음을 디디게 된다.

한편, 함께 이름을 바꾼 자바 ME는 버전 번호의 큰 변경은 없지만 내실에 있어서는 큰 변화를 더했다. 제약이 많던 CLDC(connected Limited Device Configuration)에서 거의 PC급인 CDC(connected Device Configuration)로 빠른 이전 현상을 보이며 새로운 이름에 걸 맞는 실질적인 변화가 일어나고 있다.

오픈 플랫폼의 가치

자바2.0 시대의 개막이 웹2.0 시대의 개막과 가장 유사한 점은 바로 열린 플랫폼(Open Platform)에선 찾을 수 있다. MS라는 한 기업이 내부적인 절차에 의해 개발하는 방식에 비해, 자바는 매우 일찍부터 많은 개발사 혹은 개발자들과 함께 시장을 키워왔다.

축구 종주국은 영국이지만 월드컵은 세계인의 축제로 발전한 것처럼 자바도 종가인 썬마이크로시스템즈(이하 썬)뿐 아니라 써드 파티들도 함께 성공을 거두는 좋은 자원이 되고 있다. 이런 기술 주도와 사업 성공의 독립성은 전체 시장의 활성화에 매우 중요하다.

닌텐도는 매번 우수한 게임기 하드웨어를 내놓고 거기에 최적화된 게임 소프트로 팬들을 열광시키지만, 저조한 써드 파티들의 활약으로 매번 위험성을 지적 받고 있다. 독차지하기 보다는 서로 나누면서 자라는 것은 자연스럽게 건전한 경쟁으로 이어지고, 그 과정에서 공정한 경쟁의 장을 마련해주는 선 순환이 이루어진 셈이다.

하지만, JCP의 표준화가 아무리 투명한 절차로 진행되더라도, 자바는 여전히 100% 오픈이라는 평가를 받기 어려웠다. 이는 오픈 소스의 대명사인 리눅스와 비교해보면 더욱 확연히 드러난다. 리눅스라는 OS적 오픈 플랫폼에 이은 자바라는 애플리케이션적 오픈 플랫폼의 등장이 장애로 여겨지기도 했다. 물론, 여기에는 두 가지 측면이 있다. 하나는 썬이라는 한 회사가 자바 기술에서 차지하는 비중이며, 또 하나는 그 동안 표준을 강제하며 변종을 억제해 온 통제 시장 구조이다.

그럼에도 불구하고 이제 용단을 내릴 때가 온 것으로 보인다. 먼저 자바EE 5의 참조 구현체(Reference Implementation, 이하 RI)가 글래스피시(GlassFish)라는 오픈 소스 프로젝트로 진행되어 왔다. 사용상의 라이선스도 CDDL(Common Development and Deployment License)로 OSI(Open Source Initiative)가 인증한 라이선스이며 GPL(GNU Public License)보다도 쓰기가 편하다.

또한 자바SE 6의 RI도 머스탱(Mustang)이라는 오픈 소스 프로젝트로 공개되어 있다. 아직 라이선스는 매우 제한적이며 실제 사용도 어렵지만, 이 또한 올해 자바원 컨퍼런스에서 썬의 CEO인 조나단 슈왈츠가 조만간 글래스피시처럼 될 것이라고 공식 발표했다.

이와 같이 자바가 리눅스처럼 오픈 소스로 풀린다는 것은 어떤 의미를 가지는 것일까? 글래스피시 프로젝트를 이끌고 있는 사람들 중 한 명인 에드와르도(Eduardo Pelegri-Llopart)는 “RI는 그 동안 장난 수준의 구현(Toy Implementation)으로 여겨져서, 그저 한번 설치하고 간단한 애플리케이션을 돌리는 수준으로 쓰여 왔지만 그것은 오해”라며 잘라 말한다 (http://weblogs.java.net/blog/pelegri/archive/2006/06/what_is_a_jcp_r.html).


그런 선입견을 극복하기 위해 RI를 제품 수준의 품질로 끌어 올리려는 노력이 부단히 이루어져 왔다. 톰캣(Tomcat)의 경우도 초기에는 그야말로 써블릿과 JSP에 관심 있는 사람들에게 학습과 시험의 도구 정도로만 여겨져 왔다. ‘왜 이것을 실제 서비스에 쓸 수 없는가?’라는 각성으로부터 실질적인 기능들이 추가되고 많은 버그들이 고쳐져서 (다음과 같은 포탈에서 쓰일 정도로) 많은 사람들이 실제 서비스에 채택하기에 이른 것이다.

일단 RI가 건실해지고 저변을 넓히면, 다음은 다양한 배포판이 나오며 사용자들을 즐겁게 한다. 즉 RI가 오픈 소스가 되어도 천하를 통일하여 독점하게 된다면 이 역시 아무 소용이 없다. 탄탄한 기초가 창조적인 응용을 낳는 것이 가장 바람직함은 자바의 발전에도 예외가 없는 셈이다.

잘 알려진 것처럼 구글은 자체 개조한 리눅스를 이용하여 서비스를 하고 있다. 그렇다면, 다음은 무엇일까? 구글은 자바에 깊이 관여하고 있다. RI에 기반하여 자체 자바EE 구현과 SE의 구현이 가능할 것이다. 구글뿐만 아니라 플랫폼을 이용하여 서비스를 제공하는 회사라면 누구라도 할 수 있는 일이다. 그렇다면 그 동안 썬이 혼자서 짊어져 오던 자바에 대한 투자가 더 많은 회사들로 확산되어 중복은 피하고 특성은 강화하는 효율적인 집단 개발이 실현되는 것이다.

사용자 작성 코드(User Created Code)

자바 2.0이 웹 2.0과 유사한 또 한 가지 측면은 사용자가 창조의 중심에 선다는 점에서 찾아볼 수 있다. 웹 2.0에서 사용자 작성 컨텐츠(User Created Contents)를 전면에 내세우듯이, 자바 2.0도 개발자 개개인의 블로그를 통해 지식과 코드를 나누는 것이 일상화되어 가고 있다.

더불어 과거(90년대 이전)와 비교해 보면 2006년 현재의 개발 환경은 그야말로 천국이나 다름없다. 게다가 돈을 들여 툴을 살 필요도 없다. 일인당 생산성은 현저히 올라가고, 필요한 지식의 습득과 달성을 돕는 인프라도 급속도로 증가되어왔다.

당장 개발자 개인이 쓰는 개발용 컴퓨터의 사양만 봐도 전에는 하드 디스크드라이브에서나 쓸법하던 용량이 지금은 메인 메모리 용량이 되어버렸다. 노트북이 개발자에게 크게 어필하게 되면서 ‘어디서나 코딩’이 가능해졌다. 굳이 일 중독이 아니더라도 분위기 좋은 카페나 햇살 따스한 야외에서 최고의 창의적 무드를 코드로 승화시켜 볼 수도 있다.

사실 자신이 만든 코드를 올린다는 것은 웹 상의 프로젝트에 참여하는 식의 형식적이며 커뮤니티적인 통로로만 행해지는 것으로 생각되어왔다. 사실 블로그에 자료를 올리듯이 코드를 올린다고 생각하면 그리 대단한 과정을 거치지 않아도 충분하다. 대체로 이런 짧은 코드는 하나의 완성된 애플리케이션이기보다는 기능과 아이디어에 집중된 것이다. 이런 코드의 설명에 글이나 그림으로 살을 붙이면, 코드는 문서화라는 까다로운 작업을 할 필요 없이 훌륭히 완성된다.

기존의 웹이 HTML 작성과 퍼블리싱이라는 다소 거창한 작업을 통해 컨텐츠를 공개했던 것에 반해(특히 HTML은 웹 디자인이라는 요소까지 맞물려 비전문가에게 한계를 심어주었다) 웹 2.0은 글쓰기 플랫폼으로서(예를 들어 태터툴즈와 같은 설치형 블로그) 겉보기와 올리기라는 작업을 줄이고 창작 자체에 집중할 수 있도록 하는 점도 최근 자바가 추구하는 비즈니스 로직 집중과 일맥상통한다.

즉 인프라가 점점 더 두터워지고, 아이디어 공개와 교류가 실시간으로 이루어질 수 있는 공간이 탄생하면서, 자바 2.0은 단순히 프로그래밍 언어가 아니라 알고리즘과 로직의 플랫폼으로 자리매김할 것이다. 스트럿츠와 스프링으로 이어지는 프레임워크의 흐름은 이와 같은 움직임을 대변하고 있다.

그 동안 컴포넌트 컴포넌트 노래를 불렀지만, 마치 자동차 부품처럼 규격화된 컴포넌트가 아닌, 인간의 ‘생각’을 컴포넌트화한다면, 꼭 인터페이스를 맞추는 고정관념을 탈피하여 자유롭고 유연한 재활용의 세계가 펼쳐지는 것이다. 더욱 동적인 시스템을 수용할 수 있는 프레임워크, 그리고 동적일 수밖에 없는 인간의 사고와 요구에 이제 새로운 자바가 부응하기 시작하는 모습이다.

컨버전스(Convergence)

하드웨어 이야기이긴 하지만, 울트라 모바일 PC(이하 UMPC)는 컨버전스의 미래를 보여준다. MP3 플레이어, PMP, PDA, DMB, 네비게이션, 컴퓨터가 합체된 작고 휴대하기 좋은 기기. 여기에 휴대폰 같은 통신 기기까지 가미되면 어디서나 인터넷에 접속하며 화상 통화도 즐길 수 있다. 필자가 늘 꿈꾸던 컴퓨팅 환경도 바로 그런 것이었다.

필자가 평소에 들고 다니는 것은 지갑, 휴대폰, 그리고 회사 출입 카드와 집 열쇠다. 지갑 안은 더 가관이다. 각종 카드와 현금, 명함, 메모 등이 빼곡하다. 휴대폰은 DMB폰이라서 크고 무거운 데다가 출입 카드나 열쇠를 잊고 나오기라도 하면 정말 낭패다. 봄이나 가을 겨울에야 겉옷을 입는다지만, 여름에는 넣을 주머니도 부족하다. 왜 이런 것들이 하나로 합쳐지지 않을까?

아주 극단적으로, 위에서 말한 모든 기능을 가진 기기를 생각해보자. 대략 휴대폰보다는 약간 크지만, UMPC처럼 크진 않고 현재의 휴대폰보다는 넓은 화면과 고운 해상도를 가져 MP3 플레이어, PMP, PDA, DMB, 네비게이션으로 부족함이 없도록 한다. 내부에는 고성능 임베디드 CPU를 탑재하여 멀티태스킹 OS를 지원하고, 그 위에 자바SE급의 자바를 올려 웬만한 자바 애플리케이션은 수정 없이 돌릴 수 있게 한다.

여기에 제 3세대 급의 무선 이동 통신이 가능하여 고속 인터넷 접속을 지원한다. 모든 카드는 이 기기에 특별히 할당된 카드 메모리에 기억되어, 아무리 많은 카드라도 모조리 그 특징과 함께 수록된다. SKT, KTF, LGT 멤버십 카드를 다 가지고 있다면 세 장의 카드를 따로따로 가지고 다닐 필요 없이 이 기기로 제시하고 싶은 카드를 선택할 수 있게 하는 것이다. 명함도 실제 종이 명함이 아니라 이 기기로 주고받고, 모든 출입 통제는 이 기기에 부여된 권한으로 이루어지게 한다.

어떤가? 이 정체 모를 기기, 잃어버리면 끝이지만 그야말로 만능이고 무거운 노트북을 들고 다닐 필요도 없다. 무선 인터넷을 몰래 쓰기 위해 거리를 배회할 필요도 없다. 그런데도 작고 가벼워 늘 들고 다닐 수 있다. 전에는 기능 하나의 기능만 가진 기기조차도 들고 다니기 어려울 만큼 무거웠을 텐데 말이다.

하드웨어 이야기를 장황하게 늘어놓은 이유는 자바에도 바로 이런 현상이 나타나고 있기 때문이다. 개별적으로 존재하던 많은 기술들이 자바EE와 자바SE라는 우산 아래로 모여들고 있다.

<그림 3>을 과거 J2EE 1.4와 비교해보면 점점 더 포함되는 JSR이 많아짐을 느낄 수 있다. 한편으로는 비대해지는 듯 보이지만(실제로 플랫폼 자체의 배포판 크기도 늘고 있다), 자바를 지탱해주는 하드웨어의 발전(CPU, 메모리, 하드 디스크, IO 버스 대역폭 등)에 비하면 오히려 하드웨어를 제대로 활용하기 위한 방향이라고 할 수 있다.

특히 자바SE 6의 포용력은 경이롭다. 자바EE 5에도 포함된 XML과 웹 서비스 관련 기술(JSR 109과 JAXR을 제외한 JAXP, StAX, JAXB, SAAJ, JAX-WS)을 모두 포함하고 있다. 심지어 자바 DB라는 100% 자바 기반 RDBMS까지 내장하게 되었다. 앞에서 예로 들었던 당장은 비현실적인 컨버전스가 자바에서는 올해 가을이면 현실로 다가오는 셈이다. 이제 Java SE 6 하나만 설치하면 네트워크, XML 처리, 그래픽, 그리고 DB의 저장까지 가능하게 되는 것이다.

그렇다면 어떤 일이 가능해지는 것일까? 사용자가 XML을 주면 그것으로부터 일정 정보를 뽑아 DB에 유지하는 프로그램을 짜야 한다고 생각해보자. 전에는 자바SE뿐만 아니라, XML 처리를 쉽게 하기 위해 JAXB도 따로 깔고(단순히 라이브러리뿐만 아니라 스키마를 처리하는 툴도 필요하다), MySQL과 같은 DBMS와 거기에 맞는 JDBC 드라이버도 구해 넣어야 했다.

그런데 이제 그런 인프라 구축 과정이 일체 필요 없게 되는 것이다. 여기에 자바 퍼시스턴스(Java Persistence) API까지 가미되면, XML 처리와 DB 처리에 XML 이해와 SQL 쿼리가 전혀 필요 없는 자바 지향적 프로그래밍까지 가능해진다. 달리 말하면, 자바 2.0의 컨버전스는 단순히 API의 수집이 아니라 개발 방식에 있어서도 통합을 의미한다고 할 수 있다.

한편, 자바ME의 컨버전스는 고성능으로 치닫고 있다. 노키아를 위시한 메이저 휴대폰 메이커들이 기존의 CLDC에서 보다 다양한 기능을 지원하는 CDC로 이전하고 있다. 거기에 많은 부가 패키지를 올려 자바SE에 뒤지지 않는 실행 환경을 제공하기 시작했다. 이는 휴대폰을 구성하는 하드웨어의 폭발적인 발전과 맞물려 있는데, 조만간 CDC조차도 뛰어넘는 자바SE급의 자바 환경이 휴대폰에 올라 갈 지도 모를 일이다.

자바의 활약이 기대되는 매우 흥미로운 곳이 하나 더 있다. 바로 최근에 출시된 블루레이 디스크(Blue-ray Disk, 이하 BD)이다. BD는 DVD처럼 많은 컨텐츠를 섭렵할 수 있도록 다양한 메뉴 시스템을 제공해야 한다. 바로 이 메뉴 시스템을 확장하여 컨텐츠를 운영하는 애플리케이션을 작성하고 실행하는 플랫폼으로 자바가 쓰이게 되었다.

모든 BD 플레이어는 자바를 지원할 것이며, 자바는 단순한 인터렉티브 메뉴 개발뿐 아니라 BD 컨텐츠를 활용한 멀티미디어 애플리케이션에 능히 쓰일 수 있다. 더욱이 BD 전용 플레이어가 네트워크 연결을 지원하거나 PC에서 BD를 보는 경우 자바의 네트워크 기능까지 활용한다면 그 응용성은 상상하기조차 힘들어 질 것이다.

언어적 중립성

자바 2.0의 마지막 특징은 타 언어와의 혼용 지원에 있다. 이 말을 듣고 벌써 ‘닷넷에서 이미 한 거잖아’라고 생각했다면 맞다 바로 그것이다. 그런데 재미있는 것은 닷넷의 다중 언어 지원이 이미 MS가 공들인 프로그래밍 언어들을 한 데 모은 것인 반면, 자바와 함께 하고 싶어 하는 언어들은 자바와는 성질이 다른(특히 동적 스크립트) 언어가 많다는 사실이다.

이와 관련한 JSR인 JSR 223 Scripting for Java Platform이 자바SE 6에 탑재되어 있어, 자바스크립트는 기본으로 지원되고, 그 밖에 그루비(Groovy), 파이썬(Python), 루비(Ruby), PHP등 많은 스크립트 언어를 자바 코드 안에서 실행할 수 있고 그 반대도 가능하다. 자바가 주가 되는 측면에서 바라본다면, 전체 코드에서 일부 코드를 자신이 좋아하는 스크립트 언어로 작성해도 된다.

또 이미 많이 나와 있는 스크립트들을 라이브러리처럼 불러 쓸 수 있다. 그야말로 전에는 생각하기 어려웠던 놀라운 일이다.

머스탱과 글래스피시, 과연 내 맘대로 고쳐 쓸 수 있을까?

머스탱과 글래스피시는 각각 자바SE 6와 자바EE 5의 RI를 오픈 소스로 구현한 것이다. 소스가 있으니 내려 받아 빌드도 가능해야 하겠지만 그 복잡한 코드만큼이나 빌드는 만만치 않다. 머스탱은 현재 솔라리스, 리눅스, 윈도우 세 가지 플랫폼을 지원한다. 세 OS를 빼고 개인이 가장 많이 쓴다고 할 수 있는 Mac OS를 지원하지 않는 것이 아쉽지만, 최근에 맥이 인텔로 CPU를 이주하면서 전보다 훨씬 포팅 속도가 빨라진 것은 반가운 일이다. 사실 맥용 자바SE 플랫폼은 애플이 작업하고 있으나 아직 오픈 소스가 아니어서 아쉬움이 남는 부분이기도 하다. 글래스피시처럼 머스탱도 맥을 공식 지원하기를 기대해본다. 머스탱을 윈도우에서 빌드하려면 비주얼 스튜디오(이하 VS) 2003 프로페셔널이 필요하다. VS 프로는 한두 푼 하는 툴이 아닌 탓에 개인이 정식으로 구입하기에는 장벽이 높다. MS에서는 VS 익스프레스 에디션(이하 VSE)이라는 것을 무료로 배포하고 있다. 그래서, 이 익스프레스 에디션의 최신 버전인 VSE 2005 C++를 머스탱 빌드에 쓰려고 하는 시도가 몇몇 열혈지사들을 통해 이루어지고 있다. 조만간 썬에서 머스탱 빌드에 공식적으로 VSE 2005를 지원하면 윈도우 사용자에게 큰 도움이 될 것이다. 이런 사정으로 인해 개인적인 머스탱 개발은 리눅스가 가장 쓰기 편해 보인다. 실제 리눅스를 쓰면 특별히 컴파일러나 추가 패키지를 깔 필요가 거의 없다. 그런데 산 넘어 산인 것이 웬만한 PC에서도 몇 시간씩 걸치는 완전 빌드 과정이다. 이것은 글래스피시도 마찬가지여서, 필자가 쓰는 초강력 파워맥(CPU 코어 4개, 메모리 8기가)에서도 2시간이나 걸릴 정도이다. 물론 모든 모듈을 다 빌드해야 할 필요성은 드물겠지만, 이토록 엄청난 규모의 프로젝트를 파악하고 자기 것으로 만드는 데에는 많은 시간과 자원의 투자가 필요한 상황이다. 하지만, 여기에도 반전이 있어 PC의 하드웨어는 눈부시게 발전하고 있다. 64비트, 멀티 코어, SSD(Solid State Disk) 등의 기술이 속속 개인 사용자에게 다가가고 있다. 이제 바야흐로 맞춤형 자바의 시대가 다가오는 것이다.

자바는 프로그래밍 언어이기도 하지만 자바 바이트 코드를 실행하는 버추얼 머신이기도 하다. 바로 이 점에서 ‘자바 실행 파일을 꼭 자바로 짜야 하는가?’라는 의문을 낳게 되었다. 이미 닷넷이 CLR(Common Language Runtime)을 통해 보여준 것처럼, 실행 환경과 개발 환경의 분리는 새로운 것도 아니지만 그 동안 자바에 천착한 이들에게는 생소하고 또 두려울 수도 있다.

하지만 자바는 다른 모든 언어가 그렇듯이 언어로서 모든 목적에 100% 부합할 수 없다. 개발에 쓸 언어의 선택은 사용자의 몫으로 돌리고, 자바2.0은 실행 환경으로서 더욱 넓어지는 길을 운명으로 삼으려 한다. 이는 자바SE 7 코드명 돌핀(Dolphin)에서 구제화 될 예정이며, 자바에 있어 일대 전환점이 될 것이다.

꿈이 자라면 현실이 된다.
꿈은 이루어진다. 2002년 월드컵 구호가 아니다. 자바에 대한 많은 꿈들이 현실로 이루어졌고, 또 많은 꿈들이 실현의 후보로 뛰고 있다.

Java SE 7와 Java EE 6을 구성할 신기술들

자바 개발자들의 꿈을 현실에 한걸음 다가서도록 만들어 줄 자바SE 7과 자바EE 6의 정확한 로드맵은 아직 나오지 않았지만, 다음과 같은 기술들이 새로이 추가될 것으로 관측되고 있다. 관심 있는 많은 자바 연구자와 개발자의 참여 바란다. ● Java SE 7 - JSR 277 Java Module System - JSR 292 Supporting Dynamically Typed Languages on the Java Platform - JSR 294 Improved Modularity Support in the Java Programming Language - JSR 295 Beans Binding - JSR 296 Swing Application Framework ● Java EE 6 - JSR 208 Java Business Integration (JBI) - JSR 225 XQuery API for Java (XQJ) - JSR 235 Service Data Objects (SDO) - JSR 283 Content Repository for Java Technology API (JCR) 2.0 - JSR 286 Portlet Specification 2.0 - JSR 299 Web Beans

좀 더 나은 소프트웨어 개발을 향해 우리는 한 걸음 한 걸음 나아가고 있으며, 그것이 개발자가 할 수 있는 좋은 세상 만들기의 지름길이기도 하다. 자바 2.0은 자바를 통해 그 세상을 열어 가려는 사람들의 염원의 결정체이다. 꿈을 꾸는 당신이 가장 소중하다. @

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.