1998년도 자바 가이드

이 기사는 지금까지 있었던 자바 관련 기사 중 가장 심층적인 기사로서 다각적인 측면에서 자바에 접근하여 4개의 범주에서 제품 평가를 했다. 그 외에 개요와 역사에 관하여 알아본다.

Virtual Lab(http://www.zdnet.com/vlabs/jmark20.html)에 가면 JMark 2.0이라는 벤치마크 프로그램을 받을 수 있다. 이 프로그램을 가지고 직접 시험해 보기 바란다.

자바 가이드

“자바가 정말 뭐쯤 되나?” 하고 의심한다면 독자는 다른 많은 사람들과 같은 쪽에 있는 것이다. 자바는 끊임없는 선전과 거품 때문에 필요 이상의 관심을 받아왔다. 하지만 우리가 조사한 거품 뒤의 자바는 상승세를 타고 있음을 보여주고 있었다. 사용된 4개의 범주-응용프로그램, 환경, 애플릿 툴, 그리고 개발 패키지 측면에서 검토한 자바는 위의 질문의 답을 가지고 있었다. “자바는 정말 뭐쯤 된다”

정확히 말하면 과장된 기대는 적지 않았다. 일부에서 예측했던 것처럼 Microsoft Windows를 대체하지는 못할 것으로 보이며 이동 통신 기계등에서도 뚜렷한 진척을 보이지 못했다. 가격을 낮추면서, 컴퓨터 업무와 관리를 단순화 할 것으로 예상되었던 NC(Network Computer)는 어디에서도 찾을 수 없다.

“Write once, run anywhere”이라는 자바의 가장 기본적인 주장은 어떤가? 이 문구는 자바의 중심 메시지이기 때문에 Sun에서 등록하여 사용하고 있다. 이 개념은 프로그래머들이 한번 만든 소프트웨어는 기계와 운영 체계에 상관없이 어디에서나 실행할 수 있다는 것이다. 그러나 자바에 경험이 있는 개발자들이라면 다 알듯이 이 개념은 현실 세계와는 차이가 있다. 가상 기계와 양대 산맥을 이루는 브라우저들 사이에서 자바는 같은 방식으로 구현되지 않았다.

거기다가 자바 초기의 지원자들도 등을 돌리고 있다. 그들의 불만은 자바 프로그래밍이 자원을 많이 사용하고(Resource Intensive), 사용자들의 열악한 인터넷 환경에서의 긴 다운로드 시간이다.

그렇다면 왜 우리가 “예, 한 자바합니다.”라고 하는가? 그것은 위의 모든 것에도 불구하고 자바는 혁신적인 기술로는 아니지만, 전산의 길을 느리지만 두드러지게 바꿀 수 있는 가장 가능성 있는 진보적인 툴이기 때문이다. 이제는 모든 선전들을 정리하고 여러분의 조직 어디에 자바를 적용할 수 있는지를 결정할 때이다.

우리는 이 4단계 기사에서 선전들과 제품들을 평가한다. 자바는 중요하지만 다른 새로운 기술과 마찬가지로 현재의 전산 환경이 당면한 모든 문제들을 해결할 마술 지팡이는 아니다.

자바는 정말 무엇인가?

자바가 무엇을 할 수 있는지를 이해하기위해서는, 먼저 자바가 정말 무엇인지를 이해하는 것이 중요하다. 단순히 보면 자바는 프로그래밍 언어이다. 그러나 윈도우가 단순한 GUI(Graphical User Interface) 이상인 것처럼 자바도 그저 코드를 작성하는 하나의 방법 이상이다.

자바 언어는 표면적으로는 C++와 비슷하다. 그래서, C++ 프로그래머들은 자바의 구문을 쉽게 배운다. 그리고, “Java Development Packages” 기사에서 나타났듯이, 자바의 개발 패키지들은 C++에서 사용되는 RAD 방식과 흡사하다. 그러나, C++와는 달리 자바는 바탕부터 객체 지향적이다. 이 것은 프로그래머들이, 좀 더 관리하기 수월한 코드를 작성할 수 있는, 좋은 객체 지향 프로그래밍을 사용하도록 한다.

C++와 C처럼, 자바 프로그래밍 언어라는 것에는 런 타임 라이브러리들이 포함되어있다. 이 라이브러리들은 사용자 인터페이스 관련 작업이나, 네트워크에서의 통신 등을 위한 표준 모듈들을 제공한다. 이 런 타임 라이브러리에서의 일관성은 “write once, run anywhere” 주장을 달성하는데 있어 매우 중요한 요소이며, Sun사와 Microsoft사 간의 소송의 원인이기도 하다.

실제로 96년 말에, Sun에서는 엄격한 검증 작업에 따라 자바 제품을 검증하는 100% Pure Java 제안을 시작하였다. 이 검사를 통과하는 제품은 100% Pure Java라는 명칭이 붙여지고 표준 자바 기능만을 사용하였고, 이론적으로, 제대로 적용된 자바에서 실행된다는 보증이 따라다닌다.

현재 Sun은 120이상의 제품을 보증하고 있다. 그러나 여기에는 한가지 문제가 있다: 범용적으로 사용되는 자바 VM들 중에서 Sun의 적합성 요구를 통과하는 것은 하나도 없다는 것이다. Netscape은 97년 말에, 브라우저가 완전하게 적합하지 않다는 이유로 자바 상표의 표기를 중단하였다. Sun 과 Microsoft사는 아직 Microsoft 사의 Internet Explorer를 두고 법정 공방을 하고 있다.

새로운 플랫폼으로의 자바

자바와 자바 VM은 함께, 자바 프로그램이 기계나 운영체제에 상관없이 실행될 수 있는 서비스들을 제공한다. 이런 관점에서, 자바는 새로운 플랫폼으로 자리 잡았다.

그렇다면 윈도우가 당연한 PC 플랫폼으로 여겨지고 있는 이때에, 왜 새로운 플랫폼이 필요할까? 그 이유 중 하나는 윈도우가 당연히 지배적이지만 만장일치의 선택은 아니기 때문이다. 많은 시스템에서 사용할 수 있는 코드를 작성할 수 있는 능력은 매우 중요한 것이다.

추가로, 새로운 플랫폼은 기술적으로 아무 연고도 없는 상태에서 시작한다는 장점을 가지고 있다. Windows/Intel PC 구조는 편재하는 상황에도 불구하고, 8088 프로세서와 DOS 1.0으로 거쳐 올라가는 뿌리가 단점으로 작용하기도 한다.

물론, 이 단점은 소프트웨어 호환성에 있어서 윈도우의 가장 큰 장점이기도 하다. 이것은 자바가 윈도우를 대신하여 범용 OS로 사용되지 못하는 이유이기도 하다. 현재 있는 윈도우 플랫폼에 대한 투자와 계획이 너무 많고 이 모든 소프트웨어를 다시 작업해서 얻을 수 있는 장점은 너무 적다.

실제로, 자바 응용프로그램 기사에서 시사된 바 대로, 오늘날의 자바 프로그램들은 기존에 있는 윈도우 소프트웨어를 대체할만한 제품을 제공하지 못하고 있다. 그 한 예를 보면, Corel사에서는 자사의 윈도우 프로그램을 자바 애플릿으로 만들려고 시도하였으나 실패로 끝났다. 그 이유는 윈도우 프로그램들은 그렇게 쉽게 단순한 모듈로 변경되지 않기 때문이다. 자바 개발자들은 부분별로 가져 다 짜 맞추는 자바 프로그램이 더 잘 돌아간다고 말하고 있다.

언어 그 이상의 자바

만약에 자바가 단순한 프로그래밍 언어였다면, 업계에서는 자바가 소개되었을 때 하품을 하고 있었을 것이다. 그러나 자바를 호기심의 대상으로 만드는 것은, 자바는 가상 기계(VM)라는 것 안에 포함되어있는 런 타임 환경이기도 하기 때문이다.

본질적으로 VM은 자바 프로그램과 실행되고 있는 기계 사이에 위치하여 프로그램에게는 자바 코드를 실행할 수 있는 추상적인 컴퓨터를 제공하며 기계와 소프트웨어 하부구조에 상관없이 특정한 상태를 보장한다. 자바 컴파일러는 자바 프로그램을 특정한 기계를 위한 어셈블리 언어로 바꾸는 것이 아니고 플랫폼에 중립적인 “Byte Code”로 바꾼다. 이 코드는 기계에 따라 설치된 VM이 단번에 해석한다.

또한 자바 VM은 자바 프로그램이 할 수 있는 일을 제한하는 샌드 박스라는 것을 제공하여 보안 규정을 적용한다. 예를 들어, 자바 애플릿은, 실행되고 있는 기계의, 임의의 파일에 접근할 수 없다. 가장 최근에 나온 자바 개발 도구인 JDK 1.1은 애플릿이 제한된 시스템 자원을 요구할 수 있도록 해주는 일관된 방법을 제공하지 않는다. 이 기능은 올 연말에 나올 JDK 1.2에서 사용 가능하다.

로컬 파일에 접근하기 위한 일관된 기법의 부재는 자바가 기존의 프로그램을 성공적으로 대체하는데 있어서 큰 걸림돌이 되고 있다.

자바 VM은 플랫폼과는 독립적인 전산 환경을 개발하려는 업계의 첫 시도는 아니었다. 그러나 다른 시도들이 실패한 반면 자바는 넓은 관심을 끌었다. 그 이유는 VM은 Navigator 2.0에서부터 브라우저와 같이 배포하였기 때문이고 이로 인해, 자바는 전례 없는 시장 침투를 이룩할 수 있었다.

“자바 환경” 기사에서 보여주겠지만, 각각의 플랫폼에 있는 VM들은 더 이상 비슷한 점이 없다. 이것은 이질적 환경에서의 자바 배포에 있어서 디버깅 작업을 매우 힘들게 한다.

호환성 문제는 좋아지기 보다는 나빠지는 분위기다: JDK 1.1은 JDK1.0에서부터 많이 변하였다. 즉 두 제품간의 호환성의 보장이 안 된다는 것이다. 그리고 VM에서의 JDK 1.1 지원은 예상외로 느리다. Netscape에서는 일부분만이 적용되었고 Internet Explorer 4.0에서는 많이 적용 되었다.

더욱이, 모든 VM들이 제대로 작동한다고 해도, “write once, run anywhere”이 꼭 만병통치약은 아니다. 사실은 개발자의 앞길에는 장애물로 나타나기도 한다. 자바 VM 은 일반적으로 기계의 기본 사용자 인터페이스 도구(Command Button 이나 Drop Down Box 등)을 사용하여 프로그램을 표현한다. 그러므로 자바 프로그램은 주어진 플랫폼에서의 사용자들에게 익숙한 형태로 행동한다. 그러나 이것도 플랫폼과 플랫폼간의 사용자 인터페이스 일관성을 무시하게 되고, 시험 과정에서 심각한 문제를 야기한다.

추가로, “write once, run anywhere”는 최소 공배수 방식을 적용한다. 자주 사용되는 예제를 보면, 모든 컴퓨터들이 마우스의 오른쪽 버튼을 제공하지 않는다. 그렇다고 프로그래머가 모든 플랫폼을 위한 팝 업 메뉴를 제공하여야 할까?

기계 코드에 비하여 자바 VM들은 매우 느리다. 그나마 PC 플랫폼의 버전 3.0 브라우저에 있는 Just-in-Time(JIT) 컴파일러의 출현은 속도의 결점을 다소나마 완화 시킬 수 있을 것이다. 그러나 많은 어플리케이션에서 자바는 아직도 C++로 컴파일 된 코드와 경쟁할 수 없다.

JDK 1.1의 핵심적인 추가 사항은 자바 빈(JavaBean)이다. 자바 빈은 자바의 구성 모델로서, 재사용 가능한 구성 모듈들을 쉽게 작성할 수 있게 하여준다. Microsoft 사의 ActiveX도 비슷한 장점을 제공하지만, 빈은 ActiveX 보다는 윈도우 중심 세계에 초점을 덜 맞췄고 좀 더 이동성이 높다. 그러나 ActiveX는 모든 프로그래밍 언어를 지원한다는 장점이 있는 반면, 빈은 자바만을 감싸기 위해 설계되었다.

자바가 사용될 곳

자바는 기업체에서의 엑스트라 넷에서 사용하면 될 것이다. 자바의 플랫폼 교차 사용 약속의 뜻은 이론적으로는, 수요자와 공급자가 사용하고 그들의 환경에 대하여 걱정하지 않아도 될 수 있는 어플리케이션을 작성할 수 있다는 것이다. 자바 애플릿이 빠르게 다운로드되는 것은 소프트웨어 설치 과정을 생략하게끔 한다. 그러나 이곳의 장애물은 훨씬 높다. HTML 은 자바보다 다양한 플랫폼들을 지원하기 때문이다.

자바의 또 다른 사용 처는 트랜잭션 프로세싱 시스템의 미들 티어이다. 서버나 클라이언트가 아니고 실제로 주문서를 작성한다거나 청구서 처리 작업 등의 “비즈니스 로직” 구현에 사용된다. 자바의 플랫폼 중립은, 이론적으로, 한번 작성한 코드는 자바 사용이 가능한 모든 시스템에서 실행할 수 있다는 것이다. 비록 애플릿을 동시에 다른 플랫폼에서 실행할 필요는 없지만, 윈도우나 NT에서 유닉스 서버로 코드 변경 없이 이동할 수 있다는 것은 장점일 수 있다.

또한 백 엔드 개발 환경으로의 자바를 무시할 수 없다. 자바 빈은 최소한의 변경으로 재사용할 수 있는 범용적인 비즈니스 모듈을 제공하고 자바의 단순함은 프로그래머의 생산성을 높일 수 있을 것이다. 여하튼 간에, 자바의 장단점에 상관없이, 많은 사용자들이 즐겨 사용한다는 것은 논란의 여지가 없다.

자바를 사용할 만한 또 다른 곳은, 트랜잭션 처리 시스템의 프론트 엔드인 단일 목적 어플리케이션으로, 종전의 “Dumb” 단말기의 대체로 사용되기도 한다. 이 부분은 NC가 크게 성공할 수 있는 부분이다. 실제로, IBM은 이 부류의 시장에 판매를 하였다.

이런 환경에서는, 범용 PC는 불필요하거나 아니면 오히려 역효과를 내기도 한다. 그리고, PC 의 저렴한 가격은 NC의 가격 장점을 깎아 내리고, 네트워크 연결의 속도는 지역 저장소를 사용하기에는 느리기 때문에, NC를 가정에서 사용한다는 기본 개념은 성공할 가능성이 적다.

내장 된 장치에 대하여 알아보자. 내장 된 장치들은 용도가 제한될 수도 있고, 용량과 크기에 제약사항이 있을 수 있기 때문에 자바가 해결해야 될 문제가 많다. 이런 사항들은 플랫폼 독립성이 그리 중요하지 않은 전용 하드웨어의 필요성을 설명한다. 그러나 TCI는 자사의 텔레비전의 조정기에 자바를 사용하는 계약을 맺었고 노키아는 휴대폰에 자바를 사용하는 비슷한 계약을 체결했다.

이 시점에서, 자바 기술에 희망이 있다는 것은 명백하다. 그러나 또한 자바에 관한 과장 선전도 많았기에 자바의 현실을 짚어보는 일도 필요하다. Sun사는 Microsoft사의 아성을 무너뜨릴 수 있는 가능성에 집중하기 보다 현실의 문제점들을 해결하는 데 주력하여 자바의 성공을 확실히 할 수 있다.

더 나아가서, Sun은 Java Compatibility Kit을 대중에게 공개하고, 다른 업체들의 호환성 검증을 허가해야 할 필요가 있다. 이런 공공 시험은 더 많은 가상 기계의 탄생을 촉진시킨다. 또한 Sun은 추후의 JDK 버전들은 현존하는 코드와 호환성을 가진다는 것을 개발자들에게 재 확인 시켜줄 필요가 있다. 이 전 버전들과의 호환성 문제는 계약에 가장 큰 걸림돌이었다.

만약에 자바를 선택하고자 한다면, 먼저 제한된 시험을 시작해야 한다. 특히 서버쪽을 시험하여야 한다. 시험 중 특이성을 기록하고 지원해야 하는 모든 플랫폼에서 잘 작동하는 기술의 “안전 목록”을 만들어야 한다. 정확한 객체 지향 프로그래밍 기법을 따르고 재사용 측면에 중점을 두고 객체의 인터페이스를 조심스럽게 설계 해야 한다. 그리고 난 뒤, 자바가 더 큰 프로젝트에 적합하다고 판명이 나면 시험단계를 바탕으로 하여 만들어 나가면 될 것이다.

자바의 역사

자바의 7년

가전 제품 도구에서부터 인터넷 귀염둥이까지의 7년

• 1991 년 1 월
  • James Gosling 이 가전 제품에 사용하기 위하여 “Oak” 이라는 이름으로 자바를 시작한다.　

• 1993 년 3 월 ~ 8 월　
  • Sun 은 Oak을 Time Warner Interactive TV 프로젝트용으로 초점을 재 조정한다.

• 1994 년 6 월
  • 소 규모 운영 체계용으로 기술의 초점을 조정하여 “Liveoak” 을 시작한다. 한달 후, Oak의 가능성을 인터넷 쪽으로 재 설정하고, 자바의 현재의 기능에 초점을 맞춘다.

• 1995 년 5 월 23 일
  • 1995 년 SUNWORLD에서 자바가 발표된다. Netscape이 첫번째로 자바를 승인한다. Sun 이 자바 브라우저의 알파 버전을 내 놓는다.

• 1995 년 9 월 18 일
  • 자바 애플릿을 지원하는 Navigator 2.0의 시험 제품에 의해 자바는 플랫폼이 생겼고 웹에서 그 존재를 알릴 수 있게 되었다.　

• 1995 년 10 월
  • EARTHWEB 은 개발자들을 위한 자바 자원 디렉토리이며 소식 사이트인 Gamelan을 시작한다.　

• 1995 년 10 월 24 일
  • PC 잡지에서 처음으로 자바에 대한 기사를 게재한다. “INTERNETWORKING” 칼럼에서 자바는 분산 컴퓨팅, 편한 소프트웨어 업그레이드, 그리고 웹 화면을 대화식으로 만들고 틈이 없게 만드는데 매우 중요하다고 기재한다.　

• 1995 년 12 월 4 일
  • IBM이 자바의 라이센스를 취득하여 자바를 하드웨어와 소프트웨어적으로 확장 시키려는 결심을 한다.　

• 1995 년 12 월 7 일
  • Microsoft가 자바의 라이센스를 취득할 것임을 공개한다. 자바를 윈도우용으로 최적화 시키겠다는 Microsoft사의 의향은 앞으로 2년이 넘게 있을 불화의 씨가 된다.　

• 1995 년 12 월 13 일
  • Symantec사가 자바의 라이센스를 취득하며, 첫번째 윈도우 95와 NT용 자바 개발 환경인, Symantec Cafe를 발표하고 이 제품은 성공한다.　

• 1995 년 12 월 19 일
  • 자바는 개발자에게 자유와 간결한 언어와 다능성을 준다는 이유로 PC 잡지에서 주는 Technical Excellence Award를 획득한다.　

• 1996 년 1 월 9 일
  • Sun 은 자바 기반의 제품을 개발하고 제 3 사 개발사들과 일하기 위해 JavaSoft를 설립한다.　

• 1996 년 1 월 23 일
  • Sun은 자바 애플릿 뷰어, 자바 컴파일러 그리고 자바 가상 기계가 포함된 자바 1.0 프로그래밍 환경(JDK 1.0)을 처음으로 출시 한다.　

• 1996 년 4 월 9 일
  • PC 잡지에서 분석한 JDK 1.0 기사에 의하면, 교차 플랫폼 기능 때문에 가능성은 있지만, 언어와 개발 환경을 보면 호텔 커피숍 에스프레소에 자판기 커피를 비하는 것이라고 볼 수 있다.

• 1996 년 5 월 29 일
  • 제 1회 JavaOne 개발자 회의에 6,000명 이상의 사람들이 참석했다. Corel사는 WordPerfect와 Quattro Pro의 자바 버전을 포함하는 Java Office Suite의 개발 의향을 발표한다. 이 계획은 결국 실패한다.　

• 1996 년 6 월 11 일
  • PC Magazine이 자바와 자바 툴에 대한 첫번째의 중요한 기사를 PC Tech 섹션에서 다룬다. 결론: 개발자들은 가능성에 대하여 기뻐할만하다. 그러나, 언어와 툴은 아직 원시적이다.

• 1996 년 10 월 22 일
  • PC Magazine이 자바 환경에서의 검사를 수행한다: Microsoft Internet Explorer 3.0이 최고의 자바 성능을 보였다. Navigator 3.0은 새롭게 추가된 just-in-time 컴파일러 덕분에 2.0보다 속도가 월등히 빨라졌다.　

• 1996 년 10 월 29 일
  • 자바 엔터프라이즈 컴퓨팅의 시작에는 JavaStation 네트워크 컴퓨터의 발표도 포함되었다. Sun사는 자바 스테이션의 선전을 널리 할뿐 출고하지는 않는다.　

• 1996 년 12 월 11 일
  • Internet World에서, Sun사는 100개 이상의 업체의 보증을 받은 100% 순수 자바 개시를 발표한다. 여기에 Microsoft는 빠져있었다.　

• 1997 년 2 월 18 일
  • JDK 1.1이 발표된다. 자바 빈, 인쇄 그리고 데이터베이스 사용이 가능한 향상된 언어이다.　

• 1997 년 3 월 17 일
  • Sun사는 자바의 공개 가능한 내역의 (Publically Available Specification)제공자가 되기 위해 ISO/IEC Joint Technical Committee 1에 신청한다.

• 1997 년 4 월 2 일
  • 제 2회 JavaOne에는 10,000명 이상의 인원이 참가했다. Sun 사는 다음의 제품을 발표한다.

    JavaStudio : 자바 빈을 위한 비주얼 컴포넌트 빌더.

    Enterprise 자바 빈 : 자바의 가능성 확장

    Personal 자바 : 자바의 뿌리인 생활용품을 위한 버전　

• 1997 년 5 월 27 일
  • 처음으로 자바가 PC Magazine의 머리기사에 실렸다. 내용은 자바 환경과 1세대 어플리케이션에 관한 것이었다. 결론: 자바 어플리케이션 사용의 흥분도 제한된 기능과 이름난 불안정성을 압도하지는 못했다.　

• 1997 년 8 월 27 일
  • Sun사의 CEO, Scott McNealy가 The Wall Street Journal과의 인터뷰에서 말한 내용이다. “불, 전기, 운송 수단 등 그 무엇과 비교해도 자바의 생산은 견줄 수 없는 속도로 발생했다.　

• 1997 년 10 월 7 일
  • IE 4.0 등의 Microsoft 제품의 자바 호환 검사 탈락을 예로 들며 Sun사는 자바 인가의 위반으로 Microsoft사를 고소한다.

• 1997 년 11 월 3 일
  • Lotus는 자바 기반의 플랫폼 독립의 데스크 탑 생산성 애플릿인 eSuite WorkPlace(1월에 Kona로 시작)를 발표한다. 애플릿은 IBM의 NC인 Network Station 1000용으로 설계됐다.　

• 1997 년 12 월 16 일
  • 자바 빈과 자바 2.0을 위한 Visual Cafe가 PC Magazine의 Technical Excellence Award를 수상한다. James Gosling과 자바 팀은 올해의 인물상을 수상한다.　

• 1998 년 1 월
  • 가장 큰 케이블 제공자인 Tele-Communications Inc.는 자사의 디지털 셋 톱 박스의 운영 체계로 PersonalJava를 선택한다. 자바를 원래의 자리로 돌아오게 하는 것이다. 그러나 TCI는 Windows CE도 같은 목적으로 허가를 얻어낸다.

어플리케이션

비록 자바가 많은 주목을 받았지만, 근래에 와서야 이제 서서히 어플리케이션에서 사용되기 시작했다. 본사는 생산성 업무, 금융 업무, 인터넷 업무 그리고 유틸리티 프로그램들을 포함하는 광범위한 분야에서 20개 이상의 자바 어플리케이션을 조사했다.

늦게 시작했지만, 자바는 서서히 기성 어플리케이션에서 두각을 나타내기 시작했다. Sunsoft는 120개 이상의 어플리케이션을 순수 자바 목록 100에 올려놓고 있다.

질문 : 어떤 종류의 어플리케이션에서 자바를 사용하나(혹은 할까)?

조사 결과를 보면 드디어 자바가 데스크 톱에서 영역을 넓혀가고 있다는 것을 알 수 있다. 그리고 다양한 종류의 어플리케이션을 찾았다.

환경

자바가 약속하는 것은 문법에 맞게 작성된 어플리케이션은 제 버전의 자바를 실행하는 모든 운영체계에서 작동할 것이라는 것이다. 많은 발전을 보았지만 시험 결과는 자바가 아직은 사용자들이 원하는 수준에는 못 미치는 것으로 나타난다. 뒤에 있는 자바 환경의 성능 검사 결과를 보고 어느 제품이 Editors’ Choice(편집자의 선택)가 되는지 확인해보기 바란다. 가상 실험실 (www.virtual-labs.com)에 가면, 검사에 사용한 벤치마크 프로그램인 JMark를 받을 수 있다.

자바 환경, 혹은 가상 기계는 모든 운영 체계에서 작동할 수 있다. 그러나 자바 어플리케이션이 같은 식으로 실행되지는 않는다.

PC 실험실의 시험 결과

시험에서, 자바 윈도우 환경이 가장 빨랐고 종합적으로 최상의 호환성을 선보였다.

그러나 모든 어플리케이션을 실행하는 자바 환경은 없었고 모든 환경에서 실행되는 어플리케이션도 없었다.

자바 환경

자바가 약속하는 것은 문법에 맞게 작성된 어플리케이션은 제 버전의 자바를 실행하는 모든 운영체계에서 작동할 것이라는 것이다.

Larry Seltzer, PC Magazine

April 7, 1998

많은 발전을 보았지만 시험 결과는 자바가 아직은 사용자들이 원하는 수준에는 못 미치는 것으로 나타난다. 어떤 면에서 보면 자바는 빠르게 성장하는 기술이다. 그러나 마지막으로 자바 환경을 검사한지 대략 1년이 지난 뒤에도 자바는 조금밖에 바뀌지 않았다. 검사된 모든 제품들은 시중에서 베타 제품을 구할 수 있다. 그 뒤로 모든 제품들은 향상되었지만 자바 기술 전체로는 많은 진보가 없었다.

가상 기계라고 불리는 자바 환경은 자바 애플릿들과 어플리케이션들을 실행하기 위해 호스트 운영 체계에 설치된 연산 플랫폼이다. 이 기사를 위해 우리는 모든 환경들이 Sun의 Java Development Kit (JDK) 버전 1.1을 지원하는 것을 필요로 했다. 이로 인해 자바6개의 다른 업체에서 5개의 다른 운영 체계의, 총 18 개의 구성이 생기게 되었다. 여기에는 2개의 Linux 기반의 환경들도 포함되었다. 이 환경들은 Netscape의 사전 공개된 버전과 Blackdown Consulting이 구현한 JDK 1.1.3이다. 그러나 둘 다 검사를 마칠 수는 없었다.

작년과 마찬가지로, 우리의 검사 결과는 자바가 아직 약속을 만족시키려면 갈 길이 멀다는 것을 보여줬다. 성능은 갈수록 느리고, 호환성은 플랫폼간에 불규칙적이다. 또한, 다른 플랫폼들에서 사용할 수 있는 내용물들과 비교하여 사용할 수 있는 현실적 자바 프로그램은 별로 되지 않는다. 우리의 벤치마크 시험은 윈도우 기반의 환경들이 가장 빠르고 자바와 호환이 가장 잘 되서 Sun사 자체의 가상 기계보다 우수하다는 것을 입증하였다.

호환성 향상

자바 호환성에 대해 이야기 하면, 이것은 주로 Sun사의 규약과의 호환성에 대해 말하는 것이다. 그러나 우리는 또한 12개의 시중에 나와있는 업무 기반의 자바 애플릿에 대한 우리 고유의 호환성 시험을 수행하였다 (작년에는 3개의 애플릿을 시험하였다.) 작년에는 반 이상이 실패하였다. 비록 올해의 시험 결과가 대단한 향상을 보여주었지만, 36%가 시험에 실패했다. 어떤 프로그램들은 적재되었지만 설명할 수 없는 상태를 보여주었다.

비호환성의 많은 실례가 그리 이상할 것은 없다. 자바는 짧은 시간 안에,동일한 업무를 수행할 수 있는 복수의 메소드들을 포함한 크고 복잡한 언어가 되었다. 예를 들면, 개발자는 여러 개의 자바 플랫폼에서 실행될 수 있는 UI 코드를 작성하기 위해 4 개 이상의 세트 중 하나를 선택해야 한다: 원조 AWT(abstract Window Toolkit), JDK 1.1의 향상 부분을 포함한 새로운 AWT, Personal Java에 있는 Personal AWT, 곧 예정된 Java Foundation Classes(JFC)와 JDK 1.2용으로 계획된 SwingSet 등이 있다.

또 다른 중요한 요인은 라이센스에 관한 사항이다. 업체들은 자바 환경을 그들의 플랫폼에 포팅 할 때 가상 기계에 수정을 가한다. 이 수정 사항들 중 일부는 자바가 제대로 작동하게끔 하는데 필요하지만, 나머지는 최적화를 위한 것이다. API는 복잡하기 때문에 이런 변경 사항들에 의해 쉽게 호환성에 문제가 생길 수 있다.

JIT와 자바의 속도

자바 성능도 또한 복잡한 문제이다. 검사 결과, 환경마다 속도의 차이가 크다는 것이 밝혀졌다. 올해에는 그 차이가 전에 비해 그리 크지 않는데 이것은 가상 기계가 향상됐기 때문이다. JDK 1.1 환경만 검사 함으로서, 우리는 느리고, 덜 안정되고, 호환성이 떨어지는 적용 환경들을 제외시켰다. 특히 윈도우 3.1에서 실행되는 제품들을 제외시킬 수 있었다. 지금까지 나와있는 윈도우 3.1용 자바의 JDK 1.1 버전은 없고 우리가 아는 바로는 개발 중에 있는 것도 없다.

그렇다 하더라도, 올해에는 많은 성능 향상을 볼 수 있었고, 특히 Just-in-Time Compilers (JIT) 부분에서 성능 향상을 볼 수 있었다. 보통은, 자바 가상 기계는 Byte Code (바이트 코드)라 불리는 형식으로 컴파일 되어 있는 자바 코드를 바이트 단위로 해석하여 명령을 처리한다. JIT는 메소드 호출 단계에서 이 프로세스를 가로챈다. 자바가 메소드를 실행하기 전에, JIT가 이것을 번역하거나 원시 코드로 컴파일 한다. 그리고 난 뒤, JIT는 원시 코드를 캐시하여 메소드가 불릴 때마다 컴파일을 하는 것을 없앨 수 있다.

척 보면, JIT 가용 자바도 원시 코드보다 빠를 수 없을 것으로 보이고 우리도 이것이 아마 사실일 것이라고 생각한다. 결국은 같은 명령이 수행되는데, 처리 시간과 확장 메모리 사용 측면에서 보면 원시 프로그램은 JIT 컴파일의 부하가 없기 때문이다.

자바 프로그램은 다른 언어들이 컴파일 시에 하는 많은 결정을 실행 시로 늦추기 때문에 자바를 원시화로 컴파일 하기 힘든다. 예를 들면, JDK 1.1의 반사 기능은 실행 시에 객체가 다른 객체들의 속성과 메소드들에 대해 알 수 있게 한다. 보통은 실행 중에 이런 기능을 가능하게 하는 객체의 정보는 원시적으로 컴파일 된 프로그램에서는 제거된다. 그러나 원시적으로 컴파일 되 자바는 이 모든 정보를 실행모듈에 집어 넣어야 하기 때문에, 다른 언어에서는 없는 부하가 생긴다.

그럼에도 불구하고, JIT가 원시 코드에 비해 성능면에서 가지는 장점도 있다. 다른 언어와는 달리, 자바 JIT는 실행 환경에 관한 정보를 관찰하고 이에 대응할 수 있다. 예를 들면, JIT는 현재 MMX 가용 프로세서에서 실행되고 있는 것을 주시하고 필요한 곳에서는 MMX 명령을 사용한다. 그렇지 않으면 Virtual Call(가상 호출)같이 부하가 많은 특정 명령들이 좀 더 효율적으로 구현될 수 있다는 것을 파악할 수 있다. 그리고 최근의 JIT들은 Garbage Collection이 잘 구현되어 있어 어느 종류의 Garbage Collection이라도 JIT 기반의 코드에서 더욱 효율적으로 수행된다. 이것은 레지스터들이 유효한 자료들만 가리킬 수 있도록 도와준다.

우리는 이런 이론적인 상황을 시험하여 JIT 기반의 자바 코드가 원시 코드보다 우수한지를 보기로 했다. 먼저 JMark 2.0 벤치마크 시험 프로그램에 있는 4개의 정밀 검사를 Win32/x86 코드로 컴파일 하기 위해 Symantec Visual Cafe와 Acute를 사용했다. 그리고 이것의 성능을 예 전 시험에서 가장 빠른 브라우저로 판명된 Microsoft Internet Explorer 4.0의 성능과 비교하였다. IE 4가 3개의 시험에서 앞섰고, 나머지 한 개에서도 별 차이 없었다. Symantec과 의논하고 다른 시험 결과를 고려해보니, 자바의 원시 컴파일은 아직은 이른 단계로 보인다. 다른 비공식 검사에서 병행 자바와 원 C++ 버전으로 작성된 프로그램의 성능을 비교하였다. 결과를 살펴보면, C++ 코드가 JIT 기반의 자바보다 성능에서 확실한 우위를 차지하고 있다.

이 기사는 자바 환경의 성능을 검사하기 설계된 벤치마크 프로그램인 JMark 의 2.0버전의 첫 발을 기념하는 것이다.

애플릿 툴

다운로드 받아 브라우저에서 실행하는 아주 작은 자바 애플릿은 정적인 웹 화면을 대화형의 공간으로 바꿔준다. 사용하기 쉬운 신(新) 자바 애플릿 툴은 누구나 이런 애플릿을 생성할 수 있도록 한다. 총 7개의 툴을 조사하였다. 어느 제품이 편집자의 선택으로 뽑히는지는 뒤 부분으로 가면 알 수 있다. 기능 요약은 다운로드 받을 수 있다.

자바는 아직 데스크 탑 부분에서 검증 되야 할 부분이 많지만, 웹 화면에 상호 작용 기능을 추가하는 자바 애플릿을 쉽게 생성할 수 있다.

PC 실험실의 시험 결과

자바 툴들이 완숙해지면서 전문화 되었다. 이번 시험에서 BeanMachine이 사용 편이성에서 최우수로 평가됐다. 이 제품은 광범위한 애플릿을 생성하는데 적합했다. Jamba는 멀티미디어 애플릿 생성부문에서 탁월했고 전문 웹 설계자들을 겨냥하고 있다.

조사 결과 ---- 1998년 2월까지: 9,045 자바 가동 웹 사이트가 있다.

이 사이트들에는 다음과 자원으로 구성되어 있다:

• 244 개의 실업(實業)과 금융
• 329 개의 예술과 오락
• 1,515 개의 게임

자원은 자바 애플릿, 예제, 혹은 정보를 담고있는 웹 사이트 내의 공간으로 정의된다.

개발 패키지

하나의 프로그램으로 많은 환경에서 실행할 수 있다는 것은 개발자들에게 있어서는 매우 매력 있는 여건이다. 우리가 조사한 패키지들은 최신의 자바 기능들을 지원하며 시각적 기능과 엔터프라이즈급 능력을 갖추고 있다.

거의 모든 자바 개발 패키지들은 RAD 방식을 제공한다. 다수의 제품은 서버쪽 개발용 툴을 제공한다.

PC 실험실의 시험 결과

제품들을 평가하는 과정에서, 기능과 사용 편이성의 최상의 조화를 고르려고 했다. 각각의 패키지들은 대부분의 업무를 충분히 지원하지만 적응성, 확장성, 그리고 시각적 생성 툴의 개수에서 차이가 난다. 다음은 제품들의 목록이다.

• Sybase PowerJ Enterprise Version 2.1
• JBuilder Client/Server Suite
• Visual Cafe for Java 2.1
• VisualAge for Java
• Sun Java WorkShop 2.0
• CodeWarrior Professional

조사 결과

500,000 명의 프로그래머들이 구입한 자바 프로그래밍 툴을 일상적으로 사용하고 있다. - 1996년 수치의 두 배 이다.

125,000 - 25% 는 자칭 ‘Hard-Core’ 라고 함

서론

하나의 프로그램이 이질 환경에서 실행된다는 것은 개발자들에게는 매우 끌리는 사항이다. 우리가 조사한 최고의 패키지들은 최신의 자바 기능들을 지원하며 시각적 기능과 엔터프라이즈급 능력을 갖추고 있다.

2년 전에만 해도, 자바 프로그래밍 언어는 단순히 웹 화면에서 동영상 그래픽을 제공하는 평범한 방법이었다. 오늘날, 자바는 “Write once, run anywhere”이라는 약속과 함께 개발자들을 위한 혁신을 이끌고 있으며, 아직 그 약속이 실현되지는 않았지만 그 가능성이 분위기를 형성하고 있다.

이 전의 자바 개발 툴 조사 뒤로, 새로운 기술과 자바 어플리케이션들이, 자바 빈에 있는 강력한 컴포넌트 모델과 Java Database Connectivity (JDBC)를 사용한 “Servlet”이 있는 서버쪽 자바와의 연결, 그리고 Remote Method Invocation (RMI)을 사용한 분산 시스템에서 실행되는 어플리케이션 등에서 떠 올랐다. 이 제품들을 검사하며 나타난 것은 업체들이 열심히 개발하고 자바의 발전과 발 맞춰가고 있다는 것이다.

자바는 Thin-클라이언트 , 데이터베이스 중심 인트라넷 어플리케이션들과 자바가 여러 개의 하드웨어 플랫폼들을 통합하는 일을 주도하는, 세련된 분산 시스템 등을 생성하는데 우선적으로 선택되는 메소드이다. 자바를 사용하면, 원시 코드의 역할의 개념은 심각한 논쟁과 치열한 소송의 주제가 될 것이다.

자바 혁명이 개발자들의 규칙을 변경했다면, 이 혁명은 툴 업체의 규칙은 더욱 더 확실히 변경하였다. Sun Microsystems사의 고유의 프로그래밍 언어는 업체들에게 힘든 문제를 주었다. 자바 빈, JDK 1.1 지원, JDBC, 분산 시스템용 RMI, 그리고 그 외의 새로운 API 등의 떠오르는 자바 표준들과 기술들에 발 맞춘다는 것은 매우 힘든 일이다. 동시에 자바 컴파일러의 사용 편이성도 또한 필요한데, 이는 자바가 새로운 개발자를 끌어들이기 때문이다.

자바가 많은 사람들에게 활용되면서, 툴 업체들은 무엇이 정말 중요한 것인가에 목표를 맞추기 위해 애쓰고 있다. 자바 빈의 효율적인 재사용 능력일까? 100% 순수 자바 호환성일까? C++ 코드의 마이그레이션 경로일까? 아니면 분산 시스템에서 서버들을 통합하기 위한 방법인 CORBA의 보조 기능일까?

문제들을 복잡하게 하는 것은 Sun이 가지고있는 자바의 전망과 ActiveX에서 원시 코드의 역할을 허용하는 Microsoft사의 접근 방식 간의 긴장감이다. 업체들은 둘 중에 하나를 선택하거나 아니면 Sun사와 Microsoft사의 자바 가상 기계, 모두에서 실행될 수 있는 어플리케이션을 제공한다.

이번 자바 개발 환경에서 업체들은 가장 최신의 자바 기능을 구현하겠다는 의지를 보여주었다. 6개 제품의 거의 모두가 표준 Abstract Windowing Toolkit(AWT) 자바 컴포넌트, 자바 빈 그리고 ActiveX 컨트롤 들의 조합인 컴포넌트들을 폼에서 짜 맞출 수 있는 RAD 컴포넌트 프로그래밍 형식을 강조하고 있다. 컴포넌트 종류에 상관없이 , 자바 개발자들은 어플리케이션들을 시각적으로 설계 하고, 속성을 지정하고, 이벤트 핸들러를 추가할 수 있다.

서론

우리는 곧 선보일 Microsoft J++와 자바 전문가용 SuperCede 2.0을 미리 검토한다. 이 프로그램들은 검토 기간 중에는 시중에 없었다. 이 기사가 나올 때쯤에는 시험 버전이 시중에 나올 것으로 예상한다.

우리는 컴파일러를 내장한 패키지만을 검토하지만, JDK 1.1과 같이 나오는 컴파일러를 사용하는 자바 개발 제품 중 6개를 같이 검토했다.

검토한 툴들은,JDK 1.1 프로그래밍 모델에서 특히 다루기 어려운, 이벤트 핸들링 지원에서 그 차이를 보였다. 이벤트 핸들링이란 프로그램이 마우스 누르기와 같이 사용자나 시스템 이벤트들을 처리하는 방식이다. 기본적으로 프로그래머들은 이벤트와 코드를 연결하기 위해 내부 클래스들을 작성할 필요가 있다. 검토한 툴들의 대부분이 이런 일들을 자동으로 해주고 있다.

이 자바 툴들은 개발자들이 알아야 되는 자바의 수준에서도 차이가 있다. 사용하기 쉬운 툴을 필요로 하는 개발자들을 위해, Visual Cafe for Java 2.1, Database Development Edition등은 툴들은 자바 코드 작성에서 수작업으로 해야 되는 부분을 최소화했다. Sybase PowerJ 와 Visual Cafe등과 같은 툴들은 컨트롤 간에 일어나는 일들을 위저드를 통하여 자동으로 해주기 때문에 개발자들이 자바에 대하여 많이 알지 않아도 사용할 수 있다.

고려해야 하는 기능 중, 다음으로 중요한 부문은 데이터베이스 연결 부문이다. 결국 연결은 JDBC를 통하여 이루어지지만, 공급자들이 개발자들에게서 요구하는 데이터베이스 프로그래밍의 세부사항에는 차이가 있다. JBuilder Client/Server Suite과 Visual Cafe는 JDBC의 세부사항을 파악하여 프로그래밍을 쉽게 하여주는 고급 클래스들을 제공한다. 이 툴들은 또한 인터넷상에서 최소의 프로그래밍으로 데이터를 사용할 수 있는 데이터 인식 자바 빈을 제공한다.

더 나아가서, 검사한 대부분의 툴들은 데이터베이스와 연결하고 데이터베이스 질의에서 기본 폼의 생성을 위한 SQL 질의들을 자동으로 생성하는 위저드를 제공한다. Sybase PowerJ나 JBuilder 등의 자바 패키지를 사용하면, 기능면에서 원시 코드에 뒤지지 않는 데이터베이스 어플리케이션을 단 시간 안에 생성할 수 있고 비교적으로 짧은 개발 기간을 갖게 된다.

배포에 있어서는, 대부분의 툴들이 JDK 1.1에서 사용하는 Java Archive (JAR) 형식을 생성할 수 있는 위저드를 제공한다. 패키지에 따라 실행 속도의 차이를 보였고, 컴파일 속도에는 미미한 차이가 있었다. 산출 프로그램 파일 크기에서는 주목할 만한 차이가 있었는데, Sybase PowerJ가 가장 뛰어난 성능을 보였다.

이번에 검토된 패키지들은 이제 자바를 사용하여 큰 프로젝트를 수행할 수 있다는 것을 보여줬다. 툴들은 이제 개인 웹 페이지 개발자 외에 자바를 사용하여 엔터프라이즈를 통합하려는 팀 단위의 개발자들도 지원한다. 자바를 사용하는 목적의 크기에 상관없이, 필요에 맞는 패키지를 찾을 수 있을 것이다.

편집자의 선택 (Editors' Choice)

Sybase PowerJ Enterprise 2.1

우리가 검토한 모든 자바 개발 패키지는 엔터프라이즈급 어플리케이션 개발에 맞는 기능을 갖추고 있다. 그러나 Sybase PowerJ Enterprise만이 그 기능에 사용하기 쉬운 특성, 그리고 대단한 적응성과 확정성을 같이 갖추고 있기 때문에, 이 제품을 편집자의 선택으로 선택한다.

PowerJ 는 우수한 드래그-앤-드롭 기능을 가지고 있고, PowerJ 고유의 Reference Card 기능을 사용함으로써 어플리케이션을 개발한다는 것은 단순히 메소드, 속성, 그리고 자바 빈의 명령문을 모으는 것으로 대체된다. Reference Card는 개발 시간을 상당히 단축시키기 때문에, 초보자와 전문가 모두 도움을 받을 수 있다.

PowerJ의 다양한 환경 덕분에 개발자들은 개발 환경의 선택의 폭이 넓어진다. 단순히 JDK의 새 버전을 사용하여 업그레이드의 걱정을 없앨 수 있다. PowerJ는 분산 어플리케이션을 생성할 때 그 빛을 더욱 발한다. 자체의 Jaguar CTS 트랜잭션 서버도 성능이 우수하지만 COM, CORBA 아니면 RMI를 사용할 수도 있다.

Borland International의 JBuilder Client/Server Suite은 감투상을 받았다. PowerJ와 마찬가지로, 많은 기능을 제공하지만, 자바 빈 생성 툴이 약하고, 확장성이 떨어지며, 개발자들이 더 많이 자바에 대하여 알아야 한다는 점에서 PowerJ와 같이 완전한 패키지에는 못 미친다.

자바 어플리케이션 작성

현재 시중에 나와 있는 자바 툴들은 RAD 툴의 편이성과 재사용 가능한 자바 빈 컴포넌트, 그리고 공통 개발 업무를 자동화 해주고 데이터베이스 설계와 시스템 분산을 위한 엔터프라이즈 급 기능들을 사용하기 위한 프로그래밍 위저드를 제공한다. 이런 기능들의 조합은 개발자들의 생산성을 높여준다.

자바 빈의 원리

전반적인 전산 업계에 나돌던 자바에 대한 기대감 중에 개발자들을 가장 흥분하게 하는 것은 자바 빈이다. 그러나 자바 빈이란 도대체 무엇이고 왜 그렇게 중요한 것일까요?

간단히 말해서 자바 빈이란 객체 지향적인 자바 프로그램을 구성하는데 사용할 수 있는 재사용 가능한 구성 단위이다. 기술적으로, 자바 빈은 자바 언어에 기반을 둔 시각적 컴포넌트 아키텍쳐를 위한 API 규약에 의해 정의된다. 이상적으로, 자바 빈 컴포넌트 모델을 따르는 자바 컴포넌트는 다른 모든 자바 지원 어플리케이션에서 재사용될 수 있다. 예를 들면, 만약 한 개발자가 대출 상환 이자 계산 프로그램 용 프로그램 객체를 개발하며 자바 빈 모델을 따른다면 , 누구나 이 빈을 자바 빈 규약을 사용하는 자바 어플리케이션에서 사용할 수 있다.

이 것은 지금까지 플랫폼 독립적인 진정한 표준 컴포넌트 모델이 없었던 어플리케이션 개발 환경에서는 매우 중요한 일이다. C++ 와 같은 프로그램에서 컴포넌트를 개발하지만 다른 프로그래머들이 사용하려면 개발자가 사용한 규약을 정확하 알아야 재사용 할 수 있다. 그러나 이 문제가 자바 빈에 의해 해결된 것 이다. 자바 빈은 자바 빈 모델을 따를 뿐 아니라 모든 속성들과 방법을 가지고 다니기 때문이다.

Sun Microsystems사를 대표로 하는 업체들의 협회에서 만든 자바 규약에 따르면 어느 자바 빈이라도 생성 툴에서 시각적으로 다루어질 수 있다. 더 나아가서 모든 빈들은 텍스트 객체들의 글씨체, 다른 컴포넌트들에게 접근이 허락된 자바 메소드나 행동들, 빈들간의 상호작업을 나타내는 이벤트들, 그리고 빈의 지속성 등의 객체 속성 등을 지원해야 한다. 빈은 계승도 지원한다.

IE 4.0 과 Netscape Navigator 4.03 이 나올 때까지 자바는 현실보다는 가상이었다. 이 브라우저들은 자바 빈이 중요한 부분인 JDK 1.1규약을 지원한다.

이제 빈에 대한 지원이 넓어지면서, 자바 빈은 웹 개발자들의 컴포넌트로 선택되어지고 있다. 이런 빈의 성공은 많은 개발자들과 웹 설계자들이 사용하는 툴을 향상시켰고 자바 개발 툴은 프로그래머들이 새로운 빈을 작성하고 기존의 빈들을 사용하여 규모가 큰 어플리케이션을 작성할 수 있게끔 하였다. 툴들은 버튼, 텍스트, 그리고 필드 추가 등의 기본적인 빈 컴포넌트들과 엔터프라이즈 데이터베이스와의 연결을 위한 고급의 빈들도 포함하고 있다. 자바 빈 규약의 장점은 어느 빈 지원 툴을 사용하건 간에 아무 빈들을 플러그하여 사용할 수 있다는 것이다. 더 중요한 것은 프로그래머가 아닌 사람들도 아무런 코딩 없이 자바 애플릿을 작성할 수 있다는 것이다. 구성 툴들을 사용하여 빈들을 구성하면 된다.

자바의 플랫폼 교차 기능에 덧붙여서 빈을 사용하는 것에 대한 장점은 매우 크다. 회사에서는 컴포넌트를 재사용함으로써 중요한 자원들을 비축할 수 있고 값비싼 프로그래머들 대신에 웹 설계자들을 대신 고용해서 애플릿을 개발할 수 있다.

자바 규약에 대한 집착

Plum Hall 이라는 사람은 C++ 개발 툴 검사와 이 툴들이 얼마만큼 C++의 규약을 따르는가의 표준을 만들었다. 이 경험을 바탕으로, Plum Hall의 JVS Validation Suite이라는 툴은 745,000 시험 상황을 포함하는 3,400 자바 프로그램으로 구성되어있으며 자바 컴파일러와 자바 가상 기계를 평가하는데 사용된다. 이 툴을 사용하면 Sybase PowerJ Enterprise 2.1 과 Borland JBuilder Client/Server Suite은 가장 자바 규약을 잘 따르는 반면 IBM의 VisualAge는 약간의 문제가 있는 것으로 나타난다.

Gosling, Joy, 그리고 Steele이 저작한 The Java Language Specification 과 Java Programming Language의 첨부 D가 자바 1.1 플랫폼의 거의 전부를 차지하고 있다. JavaSoft 웹 화면에 있는 몇 개의 HTML 문서와 특정 기능들을 위한 몇몇의 규약이 나머지를 차지한다.

JVS 검사는 4개의 부문으로 나뉜다. Chapter 검사는 The Language Specification 과 Java Programming Language, 첨부 D에 있고 검사는 이 장들에서 설명하고 있는 기능들이 지원되는가를 검사하는 것이다. Negative Chapter는 컴파일러의 문법과 문장 오류를 처리하는 능력을 검사하기 위한 고의 적인 위반을 담고있다. JVS Grinder 검사는 연산자 와 원시적이거나 참조 데이터 종류들을 검사한다. 그리고 JVS Expresso 검사는 복잡한 표현의 평가정도를 측정한다.

표 1은 Chapter와 JVS Grinder검사를 요약한 것이다. 프로그램이 수행에 실패한 것들은 다시 자체만 실패한 것과 다른 툴들도 같이 실패한 것을 나타낸다. 툴 혼자만이 실패한 경우는 많은 툴들이 실패한 경우보다는 덜 바람직한 것이다. 공통적인 실패는 언어가 아직 개발단계에 있다는 것이고 실제 구현은 아직 규약에 반영되지 않았다는 것이다.

우리의 검사에서 IBM의 VisualAge for Java는 새로운 자바 1.1 언어의 기능인 Inner Classes를 지원하지 않는다는 것을 알았다. 또한 VisualAge의 개발 환경은 확장성에 문제가 있음을 드러냈다. 리포지토리에 3,000개 정도의 클래스들이 저장되면 컴파일 시간이 극적으로 길어진다.

Chapter 와 JVS Grinder 검사

퍼포먼스 검사

검사결과에서는 어플리케이션의 파일 크기에는 그다지 큰 차이가 없었다. 그러나 컴파일 시간 향상에서는 주목할만한 것이 이었다. 모든 자바 컴파일러들은 그들의 C/C++ 상대들보다 훨씬 좋은 컴파일 속도를 가지고 있었다. 모의 상황에서 자바 실행 속도는 생성한 개발 툴의 향상 점을 갖추지는 못한 것으로 보였다.

예제 자바 어플리케이션의 산출물 크기

Bytes - 낮은 값이 좋음

컴파일 시간

수치의 의미

자바 개발 패키지를 검사할 때, 우리는 C/C++ 어플리케이션 개발 툴 검사에 비춰서 하였다. 제품들간의 성능차이를 재기위해, 컴파일러들과, 각 패키지들의 산출물의 파일 크기, 그리고 어플리케이션의 실행 속도에 중점을 두었다. 다음은 6개의 개발 패키지들의 검토 결과이다.

어플리케이션을 생성하여 내부적으로나 웹상으로 배포할 경우, 파일 크기는 중요한 고려 사항이다. 우리는 JMark 클래스 파일의 최종 파일 크기를 검토하였다. 19개의 파일들은 34,140부터 50,145 사이에 있었다. 이중 Sybase PowerJ Enterprise 2.0이 가장 작은 크기로 만들었고 Sun Java WorkShop 2.0의 새롭고 빠른 컴파일러는 가장 큰 크기로 만들었다.

검사 기간 중에 Sybase에서 버전 2.1이 나왔기 때문에 우리는 버전 2.0과 2.1 두 가지 다를 검토하였다. 버전 2.1은 크기가 조금 커졌다.

Sun사의 컴파일러는 표준 JDK 버전 보다 빠른 속도로 코드를 생성하였다. 그러나 대신 10에서 50% 정도의 파일 크기가 커졌다. Symantec의 Visual Cafe for Java 2.1, Database Development Edition은 코드 최적화 스위치를 제공하였다. 시험 결과, 최적화된 파일의 크기가 15% 작아졌지만 성능면에서는 크게 달라진 것이 없었다.

프로그램을 작성하거나 수정을 한 뒤 컴파일 하는데 걸리는 컴파일 시간은 개발자들에게 있어서는 중요할 수 있다. C++ 컴파일러들은 윈도우 어플리케이션들을 위하여 컴파일, 링크, 그리고 리소스 컴파일 등의 다단계로 이루어진다. 그러나 자바에서는, 컴파일 단계만 이루어지고, 링크와 리소스 컴파일 단계들은 실행 중에 이루어진다.

자바에서 두 단계가 빠지면서 걸리는 컴파일 시간은 개발자들이 관심을 가지기에는 너무나 대수롭지 않은 시간이다. JMark 예제에 완전히 디버그 하는데 걸리는 시간은 Visual Cafe의 1.3에서부터 Sun JDK 컴파일러의 10초 정도까지 있었다. CodeWarrior Professional 과 PowerJ 2.1은 9.4 초와 8.6초로 Sun JDK 컴파일러와 비슷한 시간대에 있었고 JBuilder 와 Sun의 “Fast Compiler”는 1에서 3초 사이의 시간대에 있었다.

IBM의 VisualAge for Java는 뚜렷한 컴파일 단계가 없기 때문에 컴파일 시간은 보고하지 않았다. 이 프로그램은 코드가 리포지토리에 적재되면서 프리 컴파일을 하기 때문에 시간을 잴 수 없었다.

C/C++ 컴파일과 비교하여, 우리는 모든 패키지들에게서 깊은 인상을 받았다. 가장 느린 컴파일러가 19개의 자바 파일을 컴파일하는 데 걸리는 시간이 10초 내외라는 것은 자바 가 이 부문에서 놀라운 성장을 하였다는 것이다. 빠른 컴파일 외에, 몇몇 제품들은 인터랙티브 디버깅을 제공하였다. 여기에서는 소스 코드의 변경이 디버그할 때 변경된 부분만 재 구성된다. 이로 인해 C/C++등에서 있었던 수정/컴파일/링크 주기의 필요를 줄일 수 있다. 우리 생각에는 자바의 빠른 컴파일 속도가 자바와 C/C++ 중 하나를 선택하는데 있어서 중요한 요인일 될 것이다.

C/C++ 의 실행 속도에서, 가장 중요 한 것은 가장 빠르게 실행되는 코드를 생성하는 것이다. 자바 프로그래밍에서는, 가상 기계와 Just-in-Time 컴파일러가 어떤 제품이 코드를 작성하였나 보다 어떤 어플리케이션이 가장 빨리 실행되는가에 영향을 끼친다.

실행의 속도를 재기 위해, 우리는 JMark 1.02를 컴파일하고 실행하여 그 결과를 조사하였다. JMark 1.02는 11개의 작은 시험들을 포함하고 있다. 이 작은 시험들은 그래픽 기능 등의 자바 가상 기계의 여러 가지 측면을 조사한다. 다른 JMark 특유의 시험들은 자바 컨테이너 클래스 (Stack, Vector, 그리고 Hash Table 시험), 정수 연산(Quick Sort 그리고 Bubble Sort) 그리고 소수점 연산(복잡한 연산과 푸리에 시험) 등을 시험한다. 자바의 다른 중요한 사항들은 Garbage Collection과 복수의 쓰레드 사용 등이 있다.

우리는 추가로 컴파일러들의 다른점들을 조사하기 위해 IE 4.01 과 Navigator 4.04에 있는 자바 가상 기계에서 실행하여 보았다.

단일 가상 기계의 컴파일러의 시간들의 차이는 전체적으로 3%정도였다. 유일한 차이점이라면 Garbage Collection에 있었다. 4번을 실행하면 한번은 다른 세 번 보다 20% 정도 더 걸리는 것을 알 수 있었다. 그리고 모든 패키지가 같은 양상을 띠었다.

GIF파일들을 조회하고 보여주는 AWT Bits와 Images 시험에서는, 시험이 멈추는 상황이 Sun Fast 컴파일러와 VisualAge for Java Viewer in the IDE에서 일어났다. 문제를 확인할 수 없었지만 쓰레드 들 간의 경쟁상태 때문인 것 같았다.

시험 방법

자바 개발 패키지들의 검사를 위한 설정에서, 우리는 개발 툴을 JDK 1.1을 완전히 지원하고 자체의 컴파일러를 내장한 제품으로 제한하였다.

실험실 시험에서 , 자바 컴파일러들의 성능과 기능을 검토하였다. 검사 방법은 종전에 C/C++ 개발 툴들의 시험에 사용되었던 검사를 바탕으로 하였다.

시험은 컴파일러 성능과 산출 코드의 크기에 초점을 두었다. 우리는 다음의 세가지 사항을 측정하였다 : 완전한 디버그 컴파일의 속도, 부분적 디버그 컴파일의 속도, 그리고 실행 속도. 추가로, 산출 클래스들의 크기를 측정하였다.

JMark 1.02 소스 코드와 Java Chess 어플리케이션 소스를 컴파일 시간 검사에 사용하였다. 자바 컴파일러들의 성능을 검사하기 위해 자바 벤치마크 프로그램인 JMark 1.02를 사용하였다. 전에도 자바 가상 기계를 평가하기 위해 JMark 1.02를 몇 가지의 표준 성능 알고리즘에 따라 사용한 적이 있다.

JMark 1.02는 JMark 2.0의 새로운 코드 기반으로 대체되었기 때문에, 우리는 패키지 업체들에게 소스 코드를 사용할 수 있도록 하였다. JMark 2.0벤치마크 검사 코드는, 그 소스 코드가 ZDBOp의 소유이고 업체들에게 개방되어 있지 않기 때문에, 사용할 수 없었다.

각각의 자바 개발 패키지의 기능과 편리함을 검사하기 위해, 우리는 각 업체와 검토자를 뉴욕 시에 있는 PC Magazine 연구실에 초대하였다. 그 목적은 각 제품이 자바 애플릿과 어플리케이션 개발에서 보여주는 확장성, 능력, 유연성, 기능들, 그리고 사용의 편리성을 평가하기 위해서 이다. 우리는 RAD 툴과 통합 개발 환경(IDE), 그리고 개발자가 직접 코드를 작성하지 않아도 되는 위저드들 고려했다. 검사 내용에는 여러 가지가 있었다. 자바 빈을 사용하는 간단한 동화상, 데이터베이스 프로그래밍, 그리고 분산 어플리케이션을 구성하기 위한 엔터프라이즈 급의 기능 평가 등이 포함된다.

각 업체와 개발자는 간단한 동화상을 생성하였다. 여기에는 생성 , 배포, 그리고 자바 빈 사용과 데이터베이스와 자바 어플리케이션 연결과정이 속한다. 간단한 동화상 작업은 여러 개의 비트맵들을 사용하여 웹 화면 향상용 애플릿을 실행한다. 만약 제품에 어플리케이션 위저드나 현존하는 컴포넌트가 있으면 사용하였다.

또한 자바 빈 생성을 심도 있게 조사하였다. 각 제품을 사용하여, 여러 개의 속성을 가지는 기본적인 그리드 빈을 생성하였다. 특별히 이 작업을 개선해 위저드와 BeanInfo 지원을 제공하는 패키지를 찾으려고 하였다.

다음으로는 빈을 JAR파일 형식으로 배포하여 각 제품들의 기능들을 평가하였다. 마지막으로, 각 제품의 화면 설계도구를 사용하여 생성된 빈을 어플리케이션에서 사용하고 각 제품의 자바 빈 사용 기능과 생성 기능을 평가하였다.

데이터베이스 연결 기능에 있어서는 고객 주문 프로그램을 작성하였다. 지역 데이터베이스를 사용하여 프로그램은 주문과 고객을 입력, 수정 그리고 조회 할 수 있도록 하였다. 검사의 이 부문은 각 제품이 위저드, 컴포넌트, 빈, Swing/AFC나 ActiveX 컴포넌트를 사용하여 작업을 완성하는 기능을 보여주도록 한다.

데이터베이스 어플리케이션을 작성하면서 얼마만큼이 자동화 되었고 얼마만큼이 수동으로 입력해야 되는지를 보여주려고 노력했다. 어플리케이션 작성이 끝난 뒤에, 각 업체들은 제품의 분산 기능을 보여주었다. 여러 개의 제품들은 기존의 클라이언트/서버 어플리케이션을 CORBA나 RMI를 사용하여 분산 환경으로 이동할 수 있는 툴이 내장되어 있었다. 결국 오늘날의 자바는 엔터프라이즈 급의 전산에 준비되어있었다.

기능 요약

Sybase Inc.: Sybase PowerJ Enterprise

현 시장에서 찾아볼 수 있는 최상의 확장성, 유연성, 그리고 능력을 갖춘 Sybase PowerJ Enterprise 2.1은 전사적인 자바 개발에 관심이 있거나 강력한 어플리케이션을 만들면서 자바를 배울 필요가 있는 사람들에게는 유일한 선택이 될 것이다. 새롭게 수정된 모든 JDK, CORBA 그리고 ActiveX 컴포넌트 툴들을 플러그인 할 수 있는 PowerJ만의 고유 능력과 엔터프라이즈 자바 빈 지원은 이 툴이 어떻게 개발자가 선택의 문을 열어 놓게 하는지를 보여준다. 단단하게 통합된 개발 환경과 드래그-앤-드롭 기능은 Sybase의 데이터베이스와 클라이언트/서버 개발 제품들과의 일관성을 나타내며 접근하기 쉽게 하여준다.

PowerJ의 드래그-앤-드롭 프로그래밍 기능은 매우 인상적이다. 강력한 Reference Card는 생성하거나 삽입하는 모든 빈을 위한 메소드, 속성, 그리고 명령 구문을 찾아준다.

시험 어플리케이션을 개발하면서, 집을 코드 편집기 창에 갖다 놓으면 Reference Card가 그 빈에 해당하는 모든 행동들을 예제와 함께 보여준다. 그 다음 원하는 속성들과 메소드들을 선택했고 Parameter Wizard가 빈칸 채우는 것을 도와 준다. 그러는 동안 관련된 명령어들이 코드 창에 나타난다.

Reference Card는 자바를 배우는데 있어서는 매우 유용한 도구이고 전문가들에게는 시간을 단축시켜준다. Reference Card를 사용하지 않고 직접 코드를 작성할 수도 있지만, 개발 시간을 단축할 수 있는데 마다할 개발자가 있을는지 모르겠다.

PowerJ는 JDK를 처리하는데 있어서의 그 확장성이 돋보인다. 개발자는 단순히 최근의 JDK를 플러그인 할 수 있어 수정 판으로 업그레이드 하려는 많은 어려움을 피할 수 있다.JDK 1.02 호환 어플리케이션을 생성 할 필요가 있는 사람은 기존의 표준을 따라도 된다. 1.02 버전을 JDK 1.1로 바꿀 필요가 생기는 것에 대비하여 PowerJ는 한번에 전환이 가능하도록 한다.

PowerJ의 인터페이스는 많은 기능을 원하는 개발자들을 위한 툴과 초보자들을 위한 위저드를 통합한 Sybase의 Power++ 환경에 바탕을 두고 있다. 인터페이스는 알아보기 매우 쉽게 되어있다 : 개발자는 단순히 원하는 팔레트를 선택하고, 새로운 빈들을 팔레트에 쉽게 추가할 수 있다. 단지 없는 것은 클래스간의 계승을 볼 수 있는 IBM의 VisualAge에 있는 도표 계층 클래스 뷰 이다.

위저드는 폼, 클래스, 그리고 빈의 생성에서부터 어플리케이션의 목표 타입을 정하는 것까지 모든 부문을 안내 해준다. BeanInfo 클래스를 생성하기 위해서는 클래스 위저드를 실행하여야 한다. JBuilder 나 VisualAge에서처럼 빈을 도입하면 BeanInfo가 자동으로 생성되는 것을 원하기 때문이다.

자바 엔터프라이즈 개발을 위하여, PowerJ 에는 Adaptive Server Anywhere 와 PowerDynamo Web Server 가 포함되어있어 데이터베이스 연결과 웹 어플리케이션을 테스트할 수 있다. COM, CORBA, 아니면 RMI을 사용하여 분산 어플리케이션을 구현할 수 있지만, PowerJ에 번들로 되어있는 Sybase 의 자바-빈 트랜잭션 서버인 Jaguar Component Transaction Server(CTS)사용할수도 있다.

Jaguar CTS 의 간결함은 제품의 능력을 왜곡시켜 보일 수 있다. Jaguar CTS를 개발하기 위해 다른 표준을 배우지 않아도 되며 훌륭한 트랜잭션 처리, 데이터베이스 캐싱, 그리고 확정성을 얻게 된다. 개발자는 단순히 어플리케이션을 생성할 때 Jaguar CTS 목표 타입으로 선택하면 PowerJ 가 알아서 Jaguar CTS 컴포넌트로 구성하며, 필요한 연결 코드를 생성하여 준다. PowerJ와의 조화와 자바 빈 이벤트 모델과 속성들의 순응은 Jaguar CTS를 미들 티어 트랜잭션 서버로 선택하는 최상의 선택이 된다.

데이터베이스 연결은 JDBC를 통한 방법과 Sybase 고유의 모듈인 jConnect를 사용하는 방법이 있다. 또한 Visigenics와 XDB사의 드라이버도 포함되어있다. PowerJ 내에 통합된 미들 티어 컴포넌트는 PowerJ가 JBuilder 보다 우위를 보장 할 수 있도록 한다.

Visual Query Editor(시각적 질의 편집기) 는 데이터 연결 객체를 만드는데 필요한 모든 폼들과 컴포넌트 들을 생성하고, 또한 클라이언트 캐싱을 이용한 배치 질의, 오프라인 수정, 그리고 커서 이벤트 등의 부가 가치 이벤트 들을 제공한다. 이런 기능들이 Jaguar CTS 와 같이 사용되어, 트랜잭션과 롤백을 처리하는데 있어서 보다 좋은 성능과 넓은 유연성을 제공한다.

데이터 연결이 한번 이루어지면, 거의 모든 컨트롤들은 데이터에 연결 시킬 수 있다. 그림 컨트롤을 데이터 필드에 연결하였을 때, 데이터에 변경이 있으면 지정해놓은 그림이 자동으로 나타나게 된다. 또한 질의 객체처럼 형체가 없는 컨트롤들도 바인드 할 수 있다.

PowerJ는 사용하기도 쉽지만, 경험 많은 개발자들의 마음을 끌기도 한다. Visual Cafe와는 달리, 위저드를 사용하지 않고 코드 창에서 직접 작업할 수도 있도록 되어있다. 코딩할 때는 모든 코드를 보거나, 볼 수 있는 코드 창을 제한할 수 있다. 이것은 많은 코드를 가지고 작업을 할 경우에 집중력이 흐트러지는 것을 방지할 수 있다.

PowerJ는 뒤에서, 보이지 않게 모든 코드를 관리한다. 만약 창에서 메소드를 삭제하면, PowerJ는 메소드와 관련 있는 모든 코드를 찾아서 삭제한다. 많은 개발을 하는 프로그래머들을 위해서 PowerJ는 어느 어플리케이션이나 새로운 것을 생성하는데 쓰이도록 템플릿으로 저장 할 수 있도록 한다.

인 컨텍스트 디버거는 애플릿 뷰어나 브라우저에서 디버그 할 수 있도록 한다. VisualAge의 디버거와 같이 코드를 하나씩 실행하는 동안 여러 개의 워처와 검사 도구들을 보여줄 수 있다. 코딩 문제를 해결하기 위해 오류 메시지가 코드 윈도우의 라인 번호와 같이 나타나며 가능한 해결책도 같이 나타난다. 초보자에게는 엄청난 이익이고 전문가에게는 시간을 절약할 수 있는 방법이다. 도움말은 막힐 경우에 많은 도움이 된다. 또한 60개 이상의 어플리케이션 예제들과 프로그래밍 책자가 포함되어있다. 힘과 용이성을 겸비한 PowerJ는 전문가들과 초보자들에게 가장 좋은 선택이 될 것이다.

Borland International: JBuilder Client/Server Suite

Sybase가 자체의 클라이언트/서버 개발 툴 기반 위에 최상의 자바 제품을 만든 것처럼, Borland도 Delphi와 IntraBuilder의 기능이 부여된 JBuilder Client/Server Suite을 내놓았다. 유사한 것은 이것 뿐만이 아니다. JBuilder도 최상의 인터페이스, 강력한 분산 연산 기능, 그리고 양방향 프로그래밍 기능을 선보인다. 그러나 JBuilder의 약점인 자바 빈 생성 툴의 미비함, 초보자들이 접하기 어렵다는 점이 Sybase PowerJ Enterprise 2.1 보다는 다소 떨어지게 한다.

경험 많은 개발자들은 JBuilder를 사용하여 생산성을 높이는데 별 문제가 없을 것이다. IDE는 잘 설계되었고, 탭 화면을 통하여 정보들을 적절하게 보여준다. 코드 창과 설계 환경간에 손쉽게 이동할 수 있다.

툴은 양방향 기능에 의해 돋보인다. 코드 창이나 설계 환경에서 수정을 하면 다른 쪽에도 곧바로 반영된다. 프로젝트에 컴포넌트를 추가하거나 기존의 컴포넌트를 변경할 경우에도 다른 쪽에 변경 사항이 반영된다. JBuilder는 Visual Cafe보다 더 많은 업무를 양 방향으로 처리할 수 있다.

설계 환경에서의 속성 검사 도구는 각 컴포넌트의 내부의 단면도를 제공한다. 검사 도구는 또한 컴포넌트와 관련 있는 모든 이벤트들에 접근할 수 있는 방법을 제공한다. 검사 도구 안에 있는 이벤트를 더블 클릭하면 그 이벤트를 코드 창에 나타낸다. JBuilder는 이벤트를 처리하는데 필요한 기본 코드를 삽입하여 준다. 그러므로 개발자는 없는 부분만 채워 넣으면 된다. 이 것은 매우 간편하지만, 그래도 어느 정도의 코딩은 수작업으로 이루어져야 한다.

또 다른 기능 중의 하나는 AppBrowser이다. 이 브라우저가 다른 제품들에 있는 클래스 브라우저와 다른 것은 원하는 프로젝트의 부분만을 볼 수 있게끔 한다. 그러므로 계승 단계를 거슬러 올라가지 않아도 되고 객체의 부모의 모든 속성들, 이벤트들, 그리고 메소드들을 나타내지 않아도 된다.

계승을 보고자 할 경우에는, 객체를 파고들어가서 부모 클래스의 정보를 볼 수 있다. 프로젝트 급으로 올라가면, 정보들은 배경으로 밀려나서 프로젝트를 깨끗하게 볼 수 있도록 해준다.

또한 프로젝트에는 있지만 AppBrowser에서는 컴포넌트를 빠지게 함으로서, 현재 작업중인 객체에만 신경 쓰면 된다. 컴파일 할 때에는, JBuilder가 알아서 연결된 부분들을 찾아서 같이 컴파일 한다. JBuilder는 클래스나 컴포넌트를 프로젝트에 추가하지 않고서, AppBrowser에서 열어서 작업할 수 있다.

그러나 JBuilder의 모든 부분들이 개발 환경처럼 완숙한 것은 아니다. 특히 Bean Customizer 지원은 PowerJ와 비교가 안 될 정도로 부족하다. 자바 빈 생성, BeanExpress 위저드 등은 아직 초보 단계이다.

JBuilder는 또한 자바를 새롭게 시작하는 개발자들을 위해 설계되지는 않았다. Visual Cafe에서는 코드 창을 한번도 사용하지 않고 어플리케이션 전체를 작성할 수 있다. 그러나 JBuilder를 최대한으로 사용하려면 자바를 잘 아는 것이 매우 중요하다.

JBuilder가 제공하는 툴 중에 돋보이는 툴은 Resource String 위저드이다. 위저드를 사용하면, 이미 작성된 컴포넌트를 몇 초 만에 국제화 할 수 있다. 위저드는 먼저 컴포넌트에 있는 코드를 읽고, 리소스 파일로 지정한 모든 문자열을 없애고, 생성한 파일에서 읽어드리게끔 코드를 수정한다. 리소스 파일에서 사용된 언어를 변경하면 자바 컴포넌트의 언어도 변경하게 되고, 어플리케이션과 코드의 국제화를 단숨에 이루게 된다.

디버깅에 있어서, JBuilder는 필요한 모든 업무를 처리할 수 있는 통합 도구 셋을 갖추고 있다. IDE는 쓰레드, 스택, 데이터, 검사 도구, 그리고 수식 처리 창의 정보의 창에 쉽게 접근할 수 있도록 한다. 이것은 VisualAge의 스크랩북 기능에는 못 미치지만, 어플리케이션 내의 문제를 찾는 데는 아주 유용한 도구이다. 한가지 약점은 브라우저에서 직접 어플리케이션을 디버그할 수 없다는 것이다.

분산 컴포넌트의 대한 JBuilder의 지원은 꽤 강하다. 컴포넌트를 분산시키기 위해 CORBA나 RMI를 사용할 경우, 이 작업을 도와줄 강력한 위저드를 가지고 있다. CORBA 위저드는 개발자로부터 약간의 입력을 받아서 자바 클래스로부터 Interface Definition Language(IDL)을 생성해 내며, 이 IDL 파일을 간단하게 컴파일하여 모든 작업을 마칠 수 있게 한다. 강력한 CORBA 기능은 Visigenics사의 ORB(PowerJ에서 포함되어 있음)와의 강력한 연계에서 나오는 것이며, 이것은 볼랜드 사가 Visigenics사를 인수 함으로서 더욱 발전할 것이다. RMI를 사용하는 방식은 비슷한 위저드를 사용게 되고 산출물에 차이가 있을 뿐 모든 것이 같다.

개발자들은 InterBase 데이터베이스 서버와 DataGateway 미들 웨어를 함께 얻게 된다. 이렇게 함으로서 세련된 자바 솔루션을 만드는데 필요한 하나의 완전한 툴 세트를 얻게 된다.

JBuilder는 자바 어플리케이션 개발을 위해 강력한 시각적 환경을 제공하지만, 소매를 걷어 붙이고 코드를 작성할 만반의 준비는 꼭 필요하다.

Symantec Corp.: Visual Cafe for Java, Database Development Edition

많은 부류의 개발자들을 자바 기술에 접근하게 하기 위한 취지에서 볼 때, Visual Cafe for Java 2.1, Database Development Edition은 가장 앞서가는 개발자들을 제외한 모든 사람들의 요구를 만족할 수 있는 제품이다. 전사적급의 자바 개발은 가능하지만, CORBA나 RMI등을 지원하는 PowerJ와 JBuilder의 힘이나 유연성에는 떨어진다. 거의 모든 함수를 사용하기 위해 위저드를 사용하여야만 하고, 서두의 위저드를 사용하면 고유의 코드를 입력하여주지만, 나중에 코드를 변경할 수 있는 기능은 제한한다.

Visual Cafe의 IDE는 사용이 편하기도 하지만 복잡하기도 하다. 필요한 모든 세부사항을 얻지만 한번에 얻을 수는 없다. 그리고 프로젝트 수행 중, 열어 놓는 창들의 혼란 속에서 미아가 되기 쉽다. 세 개의 창으로 된 클래스 브라우저는 유용하기는 하지만, JBuilder의 어플리케이션 브라우저 창처럼 화면에 계속 존재하지는 않는다.

IDE는 때때로 혼란한 것처럼 보이지만 권장할 만한 것도 많이 있다. IDE 전체가 드래그 앤 드롭을 지원하기 때문에 기존의 코드를 끌어 들이거나, 툴을 선택하고 프로젝트를 진행하는 것을 매우 쉽게 하여 준다. 우리는 간단한 자바 빈을 메모장 프로그램을 사용하여 작성하고 탐색기에서 드래그하여 프로젝트에 추가할 수 있었다. Visual Cafe는 곧 빈의 속성들과 메소드를 보여줄 수 있었고 우리는 아무런 변경 없이 사용할 수 있었다.

계층 편집기(Hierarchy Editor)는 프로젝트 내에 있는 모든 클래스 계층의 도표 화면을 제공하는 유용한 도구이다. 이 도구가 돋보이는 이유는 이 것이 완전한 기능을 가진 편집기라는 것이다. 편집기에서 클래스를 세분화 하는 것은 드래그 앤 드롭을 사용하고, 위저드가 조상 클래스의 속성들과 메소드를 참조할 수 있도록 안내하여준다. 그리고 난 뒤 컴파일 하는데 필요한 기본 요소들로 이루어진 코드 스텁을 생성한다. 추가로 이 모든 것은 즉각 사용할 수 있다.

시각적 설계도구는 인터페이스 개발을 간단히 하기 위해 강력한 RAD 툴을 제공함으로써 IDE의 그 능력을 확대시킨다. 프로그램은 많은 수의 빈 라이브러리를 제공하여 만일에 필요한 컴포넌트들을 곧 사용할 수 있게 하고, 속성 창을 통하여 설계 시 지정 사항을 빠르게 수정할 수 있도록 해준다.

시각적 환경에서 가장 좋은 기능은 상호 작용 위저드(Interaction Wizard)이다. 이 위저드는 JDK 1.1 이벤트 모델에서 외관상으로 컴포넌트들을 간결 하게 하는데 사용된다. VisualAge에, 비슷하지만 더욱 강력한 기능이 있지만, Visual Cafe의 위저드가 사용하는데 더 쉬웠다. 위저드를 사용하여 컴포넌트들 사이에 줄을 그으면 이벤트와 그에 따라 생기는 행동에 접근을 제공하는 대화 창을 불러온다. 몇 번의 마우스 클릭으로, JDK 1.1 이벤트 모델에 대한 이해가 없다고 하더라도, 코드 한 줄 적지않고 모든 이벤트를 적용하게 된다.

Visual Cafe는 또한 데이터베이스 연결을 위한 도구들을 제공한다. 연결은 내장된 dbAnywhere Server를 통한 여러 종류의 데이터베이스와 연결이나 JDBC를 통한 연결이 있다. 데이터 인식 빈들과, 데이터 인식 프로젝트를 위한 템플릿과 위저드가 어플리케이션 작성을 도와준다. 도한 dbNavigator에 있는 창은 데이터베이스의 원하는 깊이까지 들어갈 수 있게 하여준다.

드래그-앤-드롭 기능에서 더 나아가 데이터 인식 필드를 시각적 설계자에 추가하려면, dbNavigator에서 드래그하여 갖다 놓으면 된다. 그 결과로 Master/Detail 관계의 준비가 쉬워졌고, 핵심적인 SQL 프로그래밍이 많이 없어도 복잡한 관계들을 만들 수 있다. Symantec은 RAD 툴이 거의 모든 일을 하도록 하며 힘 안들이고 어플리케이션을 구성할 수 있도록 한다.

예상했던 대로, 자바 빈을 생성하는 것은 애플릿이나 어플리케이션을 생성하는 것보다 어렵다. Visual Cafe의 자바 빈 생성 위저드(JavaBean Creator Wizard)는 빈을 생성하는데 거치는 중요한 단계들을 안내하여줌으로써 작업을 시작할 수 있도록 도와준다. 개발자는 어떤 종류의 빈을 생성해야 할 것인가를 결정할 수 있고, 조상 클래스들로부터는 어떤 속성들과 메소드들을 나타내야 하며, 어떤 것들을 직접 만들 것인지를 정할 수 있다. 위저드는 단지 스텁 코드만을 작성하며 빈칸들은 직접 채워넣을 수 있도록 해두었다. 개발자들은 빈을 완성하기 위해 많은 양의 수준 높은 자바 코드를 작성할 준비를 해두어야 한다, 그러나 코드의 뼈대는 곧바로 컴파일 할 수 있다.

제품의 AutoJAR 기능을 사용하면 빈을 완성하고 배포하는 과정이 쉬워진다. AutoJAR은 손쉽게 JAR 파일은 생성하게 해주고 곧장 프로젝트로 받아들이도록 해준다. 빈에 수정을 가해야 할 경우, AutoJAR을 실행하면 빈이 사용되는 프로젝트에 그대로 반영된다.

Visual Cafe의 디버거는 매우 강력하다. 기능의 손실 없이 애플릿 뷰어, Internet Explorer, 그리고 Netscape Communicator등에서 디버그를 할 수 있다. 디버그 도구들을 사용하여 변수의 값의 변화, 호출, 쓰레드, 코드 한 줄씩 따라가기, 수식 값 평가들을 손쉽게 할 수 있다. Visual Cafe는 단계적 디버깅도 지원한다. 프로그램이 실행되는 동안 소스 코드를 수정하고 수정된 부분을 검사할 수 있다.

그리고 조금의 추가 작업으로 버전 관리 도구, 원시 코드 컴파일, 그리고 RMI도 지원할 수 있다. 비록 다른 패키지처럼 유연하지는 않지만 많은 프로그래머들의 요구를 만족시킨다.

IBM Corp.: VisualAge for Java

자바를 고려하는 숙련된 객체 지향 프로그래머들에게 있어서 IBM의 VisualAge for Java 1.0는 완벽한 해결책으로 보일 것이다. 특히 엔터프라이즈 연결을 필요로 하는 개발자들에게는 더할 것이다. 시각적인 프로그래밍과 디버깅 기능이 강력하며, 프로젝트 중심의 리포지토리는 개발자들이 컨트롤 들을 찾거나 버전을 추적하는데 많은 도움을 준다. 하지만 이 모든 것은 그만한 값을 치루어야 한다. VisualAge는 경험 많은 프로그래머들도 오랜 교육 기간을 보내야 한다. 전체적으로 PowerJ나 JBuilder가 더 나은 기능과 사용의 편리성을 제공한다.

VisualAge의 시각적 프로그래밍 기술은 개발자가 Visual Composition Editor에서 자바 빈 객체들을 정리하고 연결할 수 있도록 하여준다. 이벤트와 메쏘드, 속성의 인자, 등의 여러 가지 연결들을 숙지하면 연결을 성립하는 작업은 단순히 객체들간에 선을 긋고 그 연결의 속성을 정의하는 쉬운 업무가 된다.

시각적 프로그래밍을 하여도 코딩 수작업을 완전히 없애지는 않는다. 다만 결과에 빠르게 다다르게 할 뿐이다. 작업 중에 프로그램은 많은 양의 복잡한 코드를 생성하여준다. 이 코드들은 데이터 사용을 위한 연결 등을 정의할 때 유용하게 사용되고 수작업을 하는데 걸리는 많은 시간들을 절약할 수 있다.

더 나아가서 VisualAge for Java는 JDK 1.1 빈 이벤트 모델을 따르기 때문에 자바 빈을 생성하고 기존의 것을 사용하는데 매우 이상적이다. 시험 작업 중에는 Visual Composition Editor을 사용하여 기존의 판자형의 빈을 격자형의 빈으로 쉽게 확장할 수 있었다. 이 작업은 이벤트 스텁 코드를 시각적으로 작성하고 기능을 지정하는 몇 줄의 코드만 작성하면 된다. 시험 어플리케이션에서는 격자내의 문자의 속성 지정을 위하여 속성 편집기를 리스트 박스 형식으로 추가하였다. 이런 기능은 완성된 빈들의 배포를 쉽게 하여준다.

빈이 생성되거나 외부의 것을 받아들이면, 빈 인포 탭은 집에 관한 모든 속성들을 곧장 사용할 수 있도록 하여준다. 개발자는 보여줄 속성들과 숨겨둘 속성들을 지정할 수 있고, 이 때문에 빈을 사용하는데, 특정한 속성들을 막음으로써 특별한 유연성을 제공할 수 있다. 이 방법은 어떤 툴보다 강력한 기능을 제공하는 것으로 평가된다.

프로젝트의 구성 요소들에 접근하는 데는 여러 방법들이 있지만, 인터페이스가 JBuilder나 Visual Cafe의 방법처럼 직관적이지 못하다. 인터페이스는 탭 화면들과 여러 브라우저들, 그리고 어플리케이션의 구성 요소들을 보고 관리할 수 있는 탐색기 화면들로 구성되어있다. 추가로 애플릿 생성에서부터 엔터프라이즈 연결 작성에 이르는 모든 것을 길잡이 해주는 SmartGuides가 있기 때문에 작업을 시작하기 전에 모든 인터페이스를 숙지할 필요는 없다.

강력한 리포지토리가 프로젝트, 패키지, 클래스, 그리고 인터페이스들의 모든 버전들을 관리한다. 코드는 파일로 직접 저장하지 않고 리포지토리 데이터베이스 안에 분류화 한다. 이 것은 프로젝트의 모든 구성 요소들을 한데 묶어 놓고 자동으로 코드에 버전을 지정하게 하여 조직적인 개발 환경을 도모한다.

코드의 최근 버전들은 VisualAge Workspace에 자리하며 언제나 바로 사용할 수 있도록 되어있다. 구성 요소들의 이전 버전들은 리포지토리에서 복구될 수 있으며 필요하면 추가 클래스 라이브러리들을 현재 작업중인 공간으로 들여올 수 있다. 코드 관리는 쉬우나 리포지토리에서 밖으로 빼 내지 않으면 코드를 따로 볼 수 없다.

데이터베이스 연결에 작업에 있어서, VisualAge는 어느 JDBC 데이터베이스와도 직접 연결하고 최소의 코딩으로 분산 RMI 연결을 생성한다. Data Access Builder는 JDBC 연결들과 경우에 따라서 SQL 규칙을 사용하여 확장하거나 연결 빈을 재사용하여 제한 할 수 있는 표 대칭 생성을 도와준다. 기존의 시스템이나 메인 프레임에 연결할 필요가 있을 경우, VisualAge에 있는 위저드를 통하여 CICS나 C++DLL에 연결하면 된다. VisualAge 데이터 연결은 트랜잭션 처리를 도와준다, 그렇기 때문에 복잡하지만 안전한 데이터 수정 작업을 어플리케이션에서 할 수 있다.

분산 자바 어플리케이션을 생성하기 위해서는VisualAge의 RMI Access Builder를 사용하면 된다. 이 위저드는 분산 클라이언트/서버 환경에서 빈들을 사용할 수 있게끔 하여주는 서버 프록시에 필요한 코드를 생성한다. 이 방법을 사용하여 개발자는 손쉽게 지역 빈을 서버 빈으로 전환할 수 있으며 VisualAge가 복잡한 RMI 호출들을 작성하도록 한다.

서버 빈이 일단 생성되면, VisualAge의 Remote Object Instance Manager를 사용하여 서버 빈을 실행하고 쓰레드와 실행의 진행을 감시 할 수 있다. 이 도구를 사용하면 미들 웨어 트랜잭션 계층을 코딩하지 않고 클라이언트 어플리케이션을 쉬게 분산 어플리케이션으로 전환할 수 있다. VisualAge는 다른 툴과는 달리 RMI만 지원한다.

VisualAge 제품의 디버깅 기능은 매우 다양하다. Visual Cafe에서처럼, VisualAge의 On-the-Fly Debugger는 어플리케이션의 실행을 중단하지 않고도 코드를 변경하고 계속 작업하게끔 하여준다. 단계적 컴파일러는 변경된 코드만 재 컴파일 한다.

VisualAge에 있는 자바 가상 기계는 코드를 계속해서 컴파일하고 실행하지 않고서도 개발 환경에서 프로그램을 실행할 수 있게 하여 준다. 만약에 코딩 오류가 있다면 이것들은 자동으로 해결되지 않은 오류 탭에 저장되고 개발팀에 있는 다른 개발자들이 언제나 참조할 수 있다.

스크랩 북은 애플릿 뷰어에서 애플릿 전체를 실행하지 않고서 클래스의 코드 블록을 시험할 수 있는 유용한 도구이다. 이 도구는 디버깅 기능도 함께 가지고 있으며 실행 중에 변하는 값들을 추적할 수 있다. 필요에 따라서는 복잡한 자바 코드를 검사하는 문법 검사 도구로 사용하기도 한다.

VisualAge는 RAD 환경, 그리고 유용한 디버깅 기능 등, 자바 개발자에게 제공할 것들이 많다. 그러나 제품을 배우는 데는 전문가들을 빼놓고는 시간이 걸릴 것이다.

Sun Microsystems Inc.: Sun Java WorkShop

Sun Microsystems사의 Sun Java WorkShop 2.0은 JDK 이벤트 모델과 JDBC를 많이 아는 개발자들에게 가장 알맞은 도구로써 미세한 코딩은 경감하지만 코딩을 많인 하는 개발자들을 위해 설계되었다. 다중 플랫폼 지원과 원격 디버깅 등을 사용하여 엔터프라이즈 급의 인터넷 어플리케이션을 생성할만한 능력을 갖추긴 하였지만 이 기능들은 다른 패키지에서도 찾아볼 수 있다. 시각적 도움을 주는 GUI Builder for Forms가 있지만 대부분의 시각적 프로그래밍은 Studio에서 할 수 있다.

Java Studio와 WorkShop은 자바 어플리케이션을 생성하고 배포하는데 있어서 좋은 팀은 되지만 최상의 조합은 되지 못한다. 좀 더 통합적인 해결책이 대부분의 개발자들에게는 더 좋은 선택이 될 것이다.

개발 환경은 HotJava 브라우저인데 이것은, 작업 공간이 그리 세련되지 않다는 뜻으로 PowerJ의 사용자 편의 인터페이스와는 상반된다. Sun은 개발에서부터 배포까지의 모든 작업들을 브라우저-인터페이스 모양으로 보여주길 원했고, IDE는 확실하게 웹상에서 작업하는 느낌을 주었다. 그러나 불행히도, 많은 브라우저 바탕의 어플리케이션이 가졌던 흐리멍텅한 반응도 같이 가졌다. 시험 기계(펜티엄/166 프로세서, 64M 램, 윈도우 NT 4.0)에서 프로젝트를 변경하고, GUI 설계 편집기를 열고, 그 외에 기본적인 함수들을 사용했을 때 마치 우리가 웹에서 개발하는 것처럼 많이 기다려야 했다. IDE는 몇 차례 단절되는 적이 있었지만 재 부팅하지 않고 계속 진행할 수 있었다.

Visual Java GUI Builder는 격자 도면 관리자를 사용하여 RAD를 지원한다. 일관된 화면 형태는 윈도우, 버튼, 문자 열, 그리고 데이터베이스 연결을 생성하는데 많은 도움이 된다.

WorkShop은 자바 빈을 생성하고 사용하며 BeanInfo 파일, 커스터마이저, 그리고 JAR파일 생성 등의 빈의 모든 분야를 처리한다. 데이터 인식 문자 박스 빈 같은 컴포넌트를 시각적으로 생성하기 위해서는 Java Studio를 사용해야 한다. Java Studio로 작성된 코드를 수정하려면, 코드를 저장한 뒤 WorkShop으로 수입해야 한다.

데이터베이스 연결을 생성할 때는 한가지 선택이 더 있다. 번들로 나온 제품인 Object Design의 PSE for Java는 자바를 위한 데이터베이스 지원을 제공한다. Java Studio는 Flat-File과 JDBC 호출을 사용한 관계형 데이터베이스 접근을 제공한다.

시험 데이터베이스 어플리케이션을 생성하는 작업은 일부는 시각적으로 이루어졌지만 대부분은 코드를 직접 작성해야 했다. 라벨, 필드, 버튼 등은 GUI Builder를 사용하여 작성하지만 어플리케이션의 중심 로직은 대부분 손으로 직접 작성하였다.

개발의 목표는 애플릿, 빈, 자바 어플리케이션, 아니면 독립적인 어플리케이션 일수 있다. 순수한 자바 애플릿, 빈, 어플리케이션이라면 어느 JDK 1.1 지원 브라우저에서나 실행될 것이다. WorkShop은 JDK 1.1.3을 지원하며 그 자체도 자바로 작성되었다. 그러나 이 뜻은 ActiveX 컴포넌트들을 작성할 수도 없고 사용할 수도 없다는 것이고, 이 것은 윈도우용으로 개발을 할 경우 약점이 된다. 개발자는 HP UX, SCO UnixWare, Solaris Intel, Solaris SPARC, 그리고 Win32용으로 개발을 할 수 있다. 그 외에 많은 협력업체 제품들을 찾을 수 있을 것이다.

컴파일을 할 때는 자바 가상 기계에 있는 JIT 컴파일러에 추가로 두개의 독립적인 명령어 컴파일러들이 있다. Javac 컴파일러와 함께 다름 컴파일러는 더욱 빠른 실행 속도를 냈지만 코드의 크기가 보다 컸다.

WorkShop의 디버깅 기능은 보통의 수준이었지만 몇몇 고급 기능도 있었다. 스텝 인투, 오버, 아웃, 조건 과 빈도 브레이크 외에 네트워크 상에서의 원격 디버깅과 다중 쓰레딩을 포함하고 있다. 컴파일러 오류는 다른 창에 나타나며 이 오류들은 원래의 소스 코드와 하이퍼링크 되어있다.

WorkShop에 독특한 것은 Profiler라는 성능 평가 툴이다. 이 도구를 사용하면 자바 애플릿, 어플리케이션, 아니면 빈에서의 병목 지점을 쉽게 찾아낼 수 있다. 실행중의 성능을 평가한 뒤, 수집된 정보들을 볼 수 있다. 데이터를 볼 때는 통계적으로 보던지 도표로 볼 수 있다. JDK 컴포넌트는, 원하는 모듈에 집중하기 위해, 걸러질 수 있다.

프로젝트 관리자는 개발자들의 모든 프로젝트들을 손쉽게 접근할 수 있도록 한다. 그리고 서브 프로젝트를 정의할 수 있도록 한다. 그러나 개발자는 한번에 오직 하나의 프로젝트만 작업을 할 수 있다. 팀 개발은 PVCS등의 버전 관리 시스템 통하여 지원한다. 다른 파일 시스템 기반의 버전 관리 시스템도 사용할 수 있다.

프로그램의 소스 브라우저는 프로젝트 안에 있는 파일을 그리고 파일 안에 있는 클래스들을 보여준다. 파일들은 로컬 경로 대신 URL을 가질 수 있어서 웹 사이트에서 발표할 수 있다. 생성될 수 있는 프로젝트의 종류는 애플릿, 독립 어플리케이션, 패키지, 그리고 자바 빈 컴포넌트이다.

자바 WorkShop 2.0 은 자바 개발자들에게 GUI Builder, 다중 플랫폼 지원, 원격 디버깅, 성능 평가 도구 등의 유용한 도구를 제공한다. 그러나, 많은 코드를 직접 작성해야 하기 때문에 JDK 이벤트 모델과 JDBC에 대하여 많이 아는 개발자들에게만 많은 도움이 된다.

Metrowerks Inc.: CodeWarrior Professional

Metrowerks사의 CodeWarrior Professional 2.0은 훌륭한 교차 플랫폼 지원과 능숙한 개발 환경을 제공하지만, 다른 경쟁 제품보다는 많이 뒤떨어진다. CodeWarrior는 기본적인 RAD 툴의 시각 설계와 데이터베이스 연결 위저드가 없다. 이 기능들은 모든 다른 패키지에 들어있으며 특히, 오늘날의 개발자들에게 있어서는 많이 사용되는 도구중의 하나이다. Metrowerks는 RAD 지원을 추가할 예정이다. 그때까지는, 누가 뭐래도 CodeWarrior은 가장 코드 중심적인 툴이고 오직 자바 전문가만을 위한 프로그램이다.

CodeWarrior를 사용하려면 먼저 JDK 1.1 프로그래밍 규정에 익숙해야 한다. CodeWarrior는 중심 자바뿐 아니라 제품에 번들로 제공되는 여러 개의 추가 패키지에 관한 도움말과 자습서가 풍부하다. 도움말과 자습서는 CD-ROM으로 제공된다. 문서와 예제 코드도 함께 제공된다.

RAD 스타일의 시각적 컴포넌트 지원이 없어도, CodeWarrior의 프로그래밍 환경은 일하기 편한 환경이었다. CodeWarrior의 IDE는 훌륭하지만 개발 작업을 쉽게 해줄 매크로의 지원이 없다. 그러나 자주 사용되는 명령어를 위한 툴 바와 핫키 지정은 가능하다. C/C++, 자바, 그리고 파스칼의 문자 반전 기능은 기본이고 개발자에 의해 확장될 수 있다. 돋보이는 것은 소스 파일을 쉽게 비교할 수 있는 기능이며, 두 파일간에 차이점은 반전되어 나타난다.

시각적으로 컴포넌트를 작성할 수 없기 때문에, 수작업으로 코드를 작성하여 생성하고, 크기를 조정하고 각각의 컴포넌트의 이벤트들을 처리해야 했다. JDK 1.1 프로그래밍에서 사용되는 이벤트 처리 모델과 내부 클래스들을 사용하는 컴포넌트들의 이벤트 처리에 대한 지원이 없어서 코드 작성 작업은 지루하고 장황하다.

데이터베이스와 연결하려면 JDBC를 사용하는 코드를 직접 작성해야 하고 데이터베이스와 관련된 많은 작업들을 일일이 수작업으로 하는 것은 제품으로서는 약점이 된다.

하지만 어플리케이션 생성에 있어서 모든 것을 혼자 다 하는 것은 아니다. 자바 코드를 작성하고 관리하는 것을 도와줄 몇몇의 도구가 있다. 그 중 클래스 브라우저는 그 기능이 돋보인다. 이 도구를 사용하여, 자바 빈 설계에서부터 데이터베이스 프로그래밍까지의 모든 종류의 자바 프로그래밍 규약에 요구되는 클래스들과 메쏘드들을 추가할 수 있다. 그러나 전문적인 지식은 개발자 자신의 것을 사용해야 한다. 클래스 집합을 구성하는데 있어서, 계층 창은 클래스들의 단면도와 계승 관계들을 뚜렷하게 보여준다.

CodeWarrior는 복수의 언어와 교차 플랫폼 개발과 교차 플랫폼 배포를 용이하게 하는 점이 주목할 만하다.모든 프로젝트의 시작은 CodeWarrior 프로젝트 관리자이고 자바와 C++ 타겟을 짜 맞출 수 있으므로, 자바에 있는 원시 메쏘드들을 사용하여 작업할 필요가 있는 개발자들에게는 최선의 선택이 될 것이다.

복수의 플랫폼에서의 팀 개발을 허용하기 위해, CodeWarrior는 박스에서 꺼내 곧장 윈도우 95, NT 4.0 그리고 Mac OS에서 돌아간다. 모든 환경에 필요한 도구들은 같은 CD-ROM 안에 있고, 자바 소스와 프로젝트 파일은 플랫폼간에 공유될 수 있다. CodeWarrior는 또한 BeOS, PalmPilot등 다수의 운영체계를 위한 버전들을 가지고 있다.

교차 플랫폼 배포에 관해서는, CodeWarrior 어플리케이션을 마이크로소프트 자바 가상 기계와 Sun Microsystems JDK 1.1.4 자바 가상 기계에서 실행할 수 있다. 이 뜻은 ActiveX나 순수 자바를 사용한 어플리케이션과 애플릿들을 같은 도구로 작성할 수 있다는 것이다.

CodeWarrior는 또한 같은 도구로 다양한 범위의 자바 기술을 구현할 수 있도록 해준다. 완제품은 마이크로소프트사의 JDK 2.0, JDK 1.1.4를 포함한 여러 종류의 Sun 개발 툴, 서버쪽 자바 컴포넌트 작성을 위한 Sun Servlet Developer’s Kit, 그리고 고급 인터페이스 설계를 위한 Sun의 Swing 컴포넌트의 베타 버전 등이 포함되었다.

프로젝트를 설정하고 코드를 작성하고 난 뒤, 프로젝트를 컴파일하는 것은 쉬운 일이다. 소스 코드의 문법을 미리 한번 검사해보는 프리 컴파일은 인상적이다. 프로젝트 창에서는, 디버그를 할 모듈과 하지 않을 모듈들을 지정할 수 있다.

프로젝트를 성공적으로 만들고 난 뒤, CodeWarrior의 디버거를 접하면 그 기능의 우수성을 느낄 수 있을 것이다. 단지 아직 주 개발 환경과 통합되지 않았다는 것이 흠이다. 시험 중에 찾아낸 것은 디버깅 애플릿은 Netscape 보다 IE에서 더 잘 작동한다는 것이다.

기본적인 디버거 기능들은 모드 있고, 추가로 자바의 예외 상황이 일어나면 그것을 알아낼 수 있다.

CodeWarrior가 가지고 있는 위저드 중에 하나는 배포 위저드이다. 이 위저드는 JAR 파일의 압축된 형태와 압축되지 않은 형태 둘 다를 지원한다. 이 프로그램은 개발자가 주어진 자바 컴포넌트 안에 어떤 모듈들이 있는지를 찾는 작업을 도와줄 단위를 제공한다고 볼 수 있다.

시각적인 설계도구와 데이터베이스 위저드가 없다는 사실은 많은 개발자들로 하여금 다른 패키지를 찾게끔 할 것이다. 그러나,자바 기술의 하부 단계 접근이나 교차 언어, 교차 플랫폼 기능 등을 원하는 상위 단계 프로그래머들에게 있어서, CodeWarrior는 꼭 고려해봐야 할 제품이다