일반 자바의 특징

대부분의 자바입문 서적의 초반부는 반드시 다뤄지는 내용이다.
장점들만 언급되어 있지만 확실히 자바는 뛰어난 언어이기는 하다.


1) 자바는 객체지향적이다.(Object-Oriented)

"객체지향"이라는 말은 산업분야에서 가장 남용되고 있는 말 중의 하나이다. 그러나, 객체지향적인 설계는 매우 강력하다. 그 이유는 인터페이스들의 정의를 명확하게 해줄 뿐만 아니 라 재사용 가능한 "software IC"들을 제공해주기 때문이다.

간단히 말해서, 객체지향적인 설계란 데이터와 그 데이터에 대한 인터페이스의 설계에 초점을 맞추고 있는 기술이다. 이것을 목수일에 비교한다면, "객체지향적인 목수"는 그가 만들려는 의자에 주관심이 있고, 부차적으로 그 의자를 만든데 사용되는 도구에 관심을 갖는다. 반면, "비객체지향적(non object-oriented) 목수"는 주로 그의 도구들에 관심을 갖는다. 또한, 객체지향적인 설계는 어떻게 모듈들이 "plug-and-play"될지 에 대한 정의를 위한 방법이기도 하다.

Java의 객체지향적인 특성들은 본질적으로는 C++의 특성을 가지며, 동적인 메소드를 지원하기 위해서 Objective C(nextstep에서 사용되는 C)의 특성을 보다 확장한 것으로 볼 수 있다.

자바는 프로그래밍 언어 중 객체 지향(OO) 패러다임의 일종이다. 자바와 C++처럼, 이러한 패러다임에 충실한 언어는 똑같은 기본철학을 갖고 있지만, 구문과 형태면에서는 서로 다르다. 간단히 말해 객체 지향 언어는 객체들 사이의 상호 작용을 묘사한다. 하나는 객체는 상태와 행동으로 이루어진다. 객체의 상태는 데이터 요소와 각각의 해당 값으로 이루어지며, 객체의 행동 은 해당 데이터 요소에서 작용하는 함수(객체 지향 용어로는 보통 메소드라고 한다.)로 이루어진다.

자바와 기타 객체 지향 언어는 전통적인 절차적(procedural) 언어에 비해 이점이 많다. 객체는 연관된 데이터와 함수를 하나의 결합단위로 캡슐화하기 (encapsulation) 때문에 데이터 종속(data dependency)을 국소화하고, 변경의 영향을 줄이고, 기타 유지 관리 작업을 수행하기가 쉽다. 또한 객체 지향 언어는 정보 감추기(information hiding) 기능을 제공하여 꼭 필요한 경우 에만 객체가 데이터에 접근하도록 제한할 수 있다. 따라서 정보 감추기를 활용하면, 다른 객체의 메소드가 우연히 승인 없이 객체의 상태를 수정할 지도 모를 경우를 줄일 수 있다. 마지막으로, 아마 가장 중요한 것으로 객체 지향 언어 자원은 재사용할 수 있다. 잘 설계한 객체를 본래 그대로 재사용할 수 있을 뿐 아니라, 새로운 객체 역시 기존 객체의 하위 클래스를 만들어서 쉽게 만들 수 있고, 이를 통해 기존코드를 재사용하고, 중복되는 구현, 테스팅, 디버깅을 제거할 수 있다.

모든 언어 패러다임은 애플리케이션 설계에 많은 영향을 준다. 그래서 자바로 구현한 시스템은 일반적으로 객체 지향 시스템이다.

이것이 절대적인 요구사항은 아니다. 다시 말해서 더욱 전통적인 절차적 또는 기능적 설계를 객체 지향 언어로 구현할 수도 있다.

그러나 객체 지향 설계가 좀더 직관적으로 객체 지향 언어의 구현과 대응하기 때문에 객체 지향 시스템이 일반적이다.

기타 객체 지향 언어와 마찬가지로 자바는 객체 템플릿(template) 개념을 지원한다. 이와 같은 템플릿을 자바에서는 클래스(class)라고 한다. 하나의 클래스로부터 복수의 객체를 생성할 수 있다. 어떤 객체 지향 시스템에서건 한 클래스의 활성화 된 객체를, 곧 인스턴스들은 많을 수 있다. 각 개별 객체는 자신만의 내부 상태와 인터페이스를 유지 한다. 이 말은 모든 객체는 강력한 자율성을 갖는다는 것을 의미한다.

객체지향 애플리케이션을 실행하는 동안 객체는 어떤 작업을 완수하기 위해 하나의 메소드를 호출할 것이다. 메시지를 객체로 전송하면 메소드가 시작된다. 메시지를 받으면, 객체는 메시지 내용에 따라 적절한 메소드를 호출한다. 자바는 간단한 단일상속(single-inheritance)-복수 상속이 아닌-을 사용하여 시스템 객체의 계층을 구축한다.

자바의 큰 장점은 각 객체가 독립적이라는 것이다. 따라서 모든 모듈은 그대로 재사용할 수 있습니다. 또한 각 모듈은 확장할 수 있으며, 이것은 프로그래머가 새로운 절차와 새로운 하위 클래스를 모든 객체에 추가할 수 있다는 것을 의미한다.

또한 자바를 이용해서 문제를 논리적, 직관적, 특징적 객체로 분해할 수 있다. 객체 지향 설계는 전통적인 절차적 또는 기능적 설계와는 근본적으로 다른 관점에서 문제에 접근한다. 예를 들어 차량 엔진 생산을 지원하는 프로그램에 대해, 기능적 설계에서는 주로 개조 엔진 생산에 필요한 도구와 작업에 초점을 맞춘다.

이에 비해 객체 지향 개조 엔진 조립기는 주로 만들려는 엔진에 초점을 맞추고, 그 다음으로 도구에 신경을 쓴다. 이 시스템은 사용하는 도구의 관점에서가 아닌 데이터 요소와 그것을 정의 한 인터페이스의 관점에서 서술할 수 있다. 자바의 단점은 객체 지향 패러다임에 충실한 기타 언어와 같다.

이러한 약점은 일반적으로 다음과 같다.

- 많은 메시지 전달로 시스템의 과부하가 야기될 수 있다.

- 다형성(polymorphism)은 같은 이름을 공유하는 다양한 메소드의 정의가 가능하고, 이런 다형성 메소드의 오출은 종종 실행 시간까지 결정 할 수 없기 때문에, 객체 지향 언어는 동적 메소드의 결합(binding)을 요구할 지도 모른다.

- 객체 지향 언어에는 자신의 설계 방법론과 원칙이 있고, 순차적으로 활성화되는 객체보다는 복수의 활성 객체를 지원하기 때문에, 프로그래머와 설계자는 새로운 패러다임, 새로운 도구, 새로운 기술을 배워야만 한다.

자바는 C++과 똑같은 기본 기능을 갖고 있지만, Objective C의 동적 메소드 결정 기능을 더 갖고 있다. C++언어의 다소 복잡하고 혼란스런 요소를 상당부분 제거함으로써, 자바는 깔끔하게 간단해지고, 배우고 익히기가 매우 쉬워졌다.

자바의 객체 지향 특성 덕분에 시스템 객체를 쉽게 확장할 수 있다는 특징 말고도 많은 이점이 생겼다. 예를 들어 객체 지향 개조 엔진조립기는 2사이클과 4사이클처럼 여러 엔진 하위 클래스를 만들어낼 수 있다. 이 하위 클래스는 개솔린, 메탄올, 니트로로 세분화할 수 있다.

2) 자바는 분산적이다.(Distributed)

Java는 HTTP나 FTP와 같은 TCP/IP프로토콜을 이용해서 쉽게 복사할 수 있는 루틴들의 확장 라이브러리를 가지고 있다. Java 응용 프로그램들은 프로그래머들이 로컬 파일 시스템에서 파일 을 접근하는 것과 같이 손쉽게 네트워크 상에서 URL들을 이용해 객체들을 열거나 접근할 수 있다.

업무 처리의 분산과 함께 공유와 협조를 위한 정보 분산은 클라이언트-서버 애플리케이션의 주요 특성이다. 근거리 시스템 또는 원거리 시스템에 있는 시스템 객체 사이의 관계를 나타낸다. 웹의 경우 이 클라이언트-서버 애플리케이션은 정보 공유와 업무 분산 모두를 이용한다.

자바 프로그래머에게는 다행스럽게도 TCP/IP 프로시저 라이브러리가 자바의 소스 코드와 이진 분산 코드에 포함되어 있다. 이 때문에 프로그래머가 HTTP와 FTP와 같은 프로토콜을 통해 손쉽게 원거리 정보에 접근할 수 있다. 이것은 자바 애플리케이션이 URL을 열어서 웹으로부터 분산정보를 요구할 때 이루어질 것이다. 고퍼(gopher), 뉴스(news), mailto 와 같은 다른 프로토콜들은 WWW에서 잘 알려져 있지만, 아직 자바 언어로 구현하지 못하고 있다.

자바의 분산 작용 덕분에 시스템 업무의 협조와 분산이 가능하게 된다. 또한 원래 분산되는 클라이언트-서버 아키텍처의 중요한 요소입니다. 예를 들어 자바를 이용해, 멀리 떨어진 장소의 다른 엔진 조립기에서, 협조를 지원하는 분산 객체 지향 개조 엔진 조립기 애플리케이션을 구현할 수 있다. 객체 지향 개조 엔진 조립기를 이용하면, 직원들은 한 팀으로 작업을 해서 더 빠르고 경제적인 엔진을 만들 수 있을 것이다.

3)자바는 해석과 컴파일이 모두 된다.

"디저트 위에 얹을 수 있고, 마루 왁스로도 사용할 수도 있습니다." 이 말은 두 가지 용도를 가지는 소비 제품을 설명하기 위해 나온 말이다. 이 말은 자바의 경우에도 똑같이 적용할 수 있다. 자바 프로그램을 플랫폼에 상관없이 이진 바이트코드로 컴파일한 뒤에, 플랫폼에 맞춘 자바 실행 시간 환경으로서 해석할 수 있다. 따라서 컴파일도 되고 해석도 된다.

이것이 개발자에게 주는 도움은 여러 플랫폼에 맞춘 자바 환경에서 실행하기 위해, 단지 하나의 자바 소스 코드만을 컴파일한 바이트코드로 관리하면 된다는 것이다. 예를 들어 자바 프로그램을 개발해서 컴파일했다고 가정하면, 각 컴퓨터에 플랫폼에 맞춘 자바 실행 시간 환경을 설치한 상태라면, 같은 프로그램을 매킨토시, PC, UNIX 컴퓨터에서 실행할 수 있다. <하나의 소스 코드, 다중 플랫폼> 이 점 덕분에 웹용 애플리케이션을 더욱 빨리 개발할 수 있을 것이다.

자바 이진 바이트코드는 보통의 비해석 언어(noninterpreted language)에 비해 더 많은 컴파일 타임 데이터를 갖고 있다. 이 정보는 계속 유지하고 있다가 실행 시간에 사용하는데, 이때 보 과 견고함(robustness)을 검사할 수 있다. 예를 들어 자바 실행 시간 환경의 중요한 요소인 링커(linker)는 유지하고 있는 데이터를 근거로 하여 검사한다. 자바 언어에 포함된 원거리 프로시저 호출 (RPC) 지원 역시 이렇게 유지한 데이터 스트림에 기초를 둔다. 결국 유지한 컴파일 시간 정보 덕분에 더욱 쉽고 효율적으로 디버깅할 수 있다.

해석 언어는 주는 도움은, 이것이 있음으로 해서 많은 개발 환경에서 발생하는 버전의 불일치(mismatch)문제에 대해서, 개발자는 걱정을 덜 수 있다는 것이다. UNIX의 make 툴을 사용하고 모듈 인터페이스에 대한 일관적이지 못한 정의를 해소함으로써, 이러한 접근 방식 덕분에 개발자들은 여러 대상으로 쉽게 이식할 수 있는 하나의 자바 코드 소스(Source) 집합을 유지할 수 있는 것이다. 또한 프로그램을 해석하는 동안 실행 시간 환경에서 정보를 통합할 수 있도록 허용하는 동적 행동을 지원한다.

4) 자바는 아키텍처와 무관하다.(Architecture Neutral)

Java는 네트워크 상에서의 응용프로그램을 지원하기 위해서 설계 되었다. 일반적으로, 네트워크 는 다양한 CPU와 OS를 가진 시스템들로 구성되어 있다. Java응용프로그램이 네트워크상의 어디에서든지 수행이 되기 위해서는 컴파일러가 머신구조에 중립적인 오브젝트화일 포맷을 생성해 야 한다. 즉, 컴파일된 코드가 다양한 프로세서에서 수행되어야 한다.

이것은 네트워크뿐만 아니라 독립적인 시스템 소프트웨어 상에서도 마찬가지이다. 현재의 퍼스널 컴퓨터시장에서, 응용프로그램 개발자들은 IBM PC나 Apple의 Machintosh와 호환되는 버전을 독립적으로 개발하고 있다. PC의 경우 서로 다른 다양한 CPU구조가 사용되고 있고 Apple은 68000에 서 PowerPC로 옮겨가고 있는 실정에서 모든 플랫폼에서 돌아가는 소프트웨어를 만든다는 것은 거의 불가능하다. 그렇지만, Java는 다르다. Java로 작성된 응용프로그램은 모든 플랫폼에서 돌아간다.

Java컴파일러는 특정 컴퓨터 구조와 무관한 바이트코드 명령어들을 생성하므로써 플랫폼에 상관없이 수행이 가능하게 된다. 더 나가서, Java는 어떠한 기종에서도 쉽게 인터프리트되고, 수행 시에 머신코드로 손쉽게 변환할 수 있도록 설계되었다.

자바의 아키텍처 중립성은 매력적이지만 새로운 개념은 아니다. 웹분산 클라이언트-서버에서 파생된 것으로, 자바의 중요한 설계상의 특징은 이종(heterogeneous) 네트워크로 이루어진 클라이언트와 서버에 대한 지원이다. 인터넷 구성의 복잡함과 다양함을 인식하기 위해 자바의 바이트코드 이진 객체는 반드시 다양한 플랫폼에서 실행해야 한다. 이러한 목적을 달성하기 위해 선 택한 방법이 자바프로그램에 대한 아키텍처 중립(architecture-neutral) 이진표현이다.

컴파일한 이진 객체는 모든 플랫폼에서 실행될 것이다. 다시 말해, 자바는 단 하나의 소스코드를 갖고 여러 대상 플랫폼에서 실현할 수 있다. 오늘날 WWW 소프트웨어 개발자들은 보통 UNIX 버전을 개발한 다음에, PC 버전 그리고 마지막으로 매킨토시 버전을 개발한다. 이것은 별로 생산적이지 못한 마케팅 전략이며, 엄청난 개발 시간이 걸린다. 또한 프로그래밍 인력들은 각 플랫폼에서는 전문가일 것이며, "비싸고" 전문화된 노동력을 초래할 것이다. 각 플랫폼을 지원하기 위해 많은 개발 시간과 돈을 소모할 것입니다. 아키텍처 중립 포맷을 채택하면, 이러한 경제적 손실을 제거할 수 있고, 개발자들이 개발의 다른 부분에 집중할 수 있다.

아키텍처 중립 바이트코드 객체에는 단조로운 컴퓨터 명령이 들어 있어서, 특정 컴퓨터 아키텍처에 충실하거나 종속되지 않는다. 대신에 명령은 플랫폼 아키텍처에 관계없이 판독하기 쉽고, 비교적 쉽게 해당 플랫폼 고유 기계어 코드로 동적 변환된다.

5) 자바는 이식 가능하다.(Portable)

구조적 중립(architecture neutral)이라는 것은 이식성에 그이상의 의미가 있다. C나 C++과는 달리, 명세(specification)에 어떠한 "종속적 구현(implementation dependent)"이라는 조항이 없다. 기본적인 데이터 유형들의 크기들이 그들에 대한 연산행위에 의해서 정해진다. 예를 들어, "int"는 항상 부호를 가진 2의 보수값을 갖는 32비트 정수를 의미하고, "float"는 32비트 IEEE 754실수를 나타낸다. 현재까지는 이러한 선택들이 유용하다. 그 이유는 모든 가능한 CPU에서 이러한 특성을 공유하기 때문이다.

시스템의 일부인 라이브러리들이 인식 인터페이스들을 정의한다. 예를 들어, 추상적인 Windows 클래스와 그것에 대한 Unix, Windows 그리고 Machintosh에 대한 구현이 있다.

Java 시스템 자체는 상당히 이식성이 높다. 새로운 컴파일러는 Java로 작성되어 있으며, 실 행본(run-time)은 분명한 이식경계를 가지고 ANSI C로 작성되었다. 이식의 경계는 반드시 POSIX 이다.

자바 프로그램의 이식성(portability)은 자바의 아키텍처 중립성 덕분이다. 이식성의 또 다른 면은 정수, 문자열, 부동 소수점과 같은 언어의 고유 데이터 구조와 형(type)과 관계된다.

자바는 여러 컴퓨터 종류에 공통적인 데이터형인 IEEE표준을 이용한다. 예를 들어 자바에서 float 데이터 구조는 항상 부동 소수점인 IEEE 745표준에 대응하며, int 데이터형은 항상 부호있는 2의 보수로서 32비트 정수이다. 이 밖에 자바는 빅 엔디언(big-endian)과 리틀 엔디언 (little-endian) 하드웨어 바이트 순서의 종속성과 연관된 문제를 꼼짝못하게 했다. 자바의 이진 바이트코드는 구현상의 종속성이 없기 때문에, 다양한 플랫폼으로 이식할 수 있다.

또한 자바의 실행 시간 환경 역시 이식할 수 있다. 자바 컴파일러는 자바로 작성한 것에 비해, 실행 시간 환경은 ANSI C로 작성했으며, 잘 정의되고 간결한 이식 가능 인터페이스를 갖고 있다. POSIX 표준화 노력은 자바의 이식 가능 인터페이스에 막대한 영향을 끼쳤다.

이식 가능성이 주는 도움은, 매킨토시, PC, 유닉스 컴퓨터에서 실행할 연관 메소드로 추상적인 자바 창 클래스 객체를 구현하는 것이 바로 중복 구현, 테스팅 등을 전부 제거했기 때문이다.

6) 자바는 다중스레드이다.

우리를 둘러싼 세상에는 동시에 많은 일들이 벌어진다. 멀티쓰레딩이란 멀티 스레드 (lightweight process나 실행문맥(execution contexts)들을 가진 응용프로그램들을 작성하는 한 방 법이다. 불행히도, 한번에 많은 일이 일어나도록 프로그램을 한다는 것은 보편적인 싱글 스레드를 갖는 C나 C++스타일의 프로그래밍으로는 어려운 일이다.

Java는 C.A.R. Hoare에 의해서 제안된 모니터(monitor)와 조건부 변수(condition variable) 패러다임에 폭넓은 기반을 둔 동기화 원시명령어(primitive)의 집합을 가지고 있다. 이러한 개념들을 언어에 결합하므로써, 사용하기 쉽고 견고한 언어가 되었다. 이러한 결합 형태의 상당부분이 Xerox의 Cedat/Mesa시스템을 참고한 것이다.

멀티스레드의 다른 이점들로는 보다 향상된 대화형 응답(interactive response)과 실시간으로 동작한다는 것이다. 그러나, 사용하는 플랫폼에 따라 제한이 있다. Java가 혼자 수행되는(stand alone) 환경에서는 좋은 실시간 특성을 보인다. Unix, Windows, Macintosh나 Windows NT등의 환경에서는 실시간 응답에 제약이 있다.


자바 바이트코드 이진 객체는 복수의 동시 실행 스레드로 구성할 수 있다. 이것을 실행 컨텍스트(execution contexts) 또는 라이트웨이트 프로세스(lightweight processes)라고도 한다. C와 C++는 단일 실행 스레드 패러다임에 속하는 언어로서, 스레드에 대한 언어 수준(language-level) 지원을 제공하지 못한다. 하지만 자바는 다중스레드에 대한 언어 수준 지원을 제공하여 더욱 다양하고 강력한 프로그래밍 접근을 유도한다.


자바는, 1974년 앤소니 C. 호어(Anthony C. Hoare)가 운영 체제 이론의 모니터 조건(monitor-condition) 패러다임에서 첫 선을 보인, 일련의 복잡한 동기화 요소를 활용한다. 이 요소들을 통합했기 때문에, 자바 프로그램의 다중스레딩 구현은 단순하며 매우 견고하다. 자바 언어 사양에 따르면, 다중 스레딩 기능의 상당 부분은 제록스(Xerox) 세다 메사(CedarMesa) 시스템에 의한 것이다.


이 밖에 다중 스레딩이 주는 도움은, 실시간으로 작업을 처리해서 사용자는 더욱 빠른 대화 응답을 얻게 된다는 것이다.


하지만 자바 언어 사양은 실행 시간 컴퓨팅 플랫폼과 기타 플랫폼의 특성에 따라 이러한 이점들이 제한된다. 예를 들어 기초가 되는 운영 체제가 병렬스레드를 지원하지 않는다면, 자바의 다중 스레딩 효과는 충분히 발휘되지 않는다. 하지만 이런 제한이 없는 독립형 자바 애플리케이션은 뛰어난 실시간 응답력을 보여줄 수 있다.


7) 자바는 동적이다.(Dynamic)


많은 면에서, Java는 C나 C++에 비해서 보다 동적인 언어이다. 이것은 변화하는 환경에 적응 하도록 설계되었기 때문이다. 예를 들어, 생산환경에서 C++를 이용할 경우의 중요한 문제가 코드 가 항상 구현되는 방식에 따른 부작용(side-effect)이다. 만일, 회사 A가 하나의 클래스 라이브러리를 생산하고, 회사 B가 그것을 구입해서 제품을 만들었다고 하면, 회사 A가 라이브러리를 변경하여 새로운 버전을 내놓으면 회사B는 B가 만든 제품에 대해서 재컴파일을 수행하고, 새로운 버전 을 배포해야 한다. 만일, 최종 소비자가 A와 B제품을 각기 독립적으로 구입했다면, 문제가 생긴 다.


예를 들어, 회사 A가 자신의 제품에 대한 업그레이드를 실시하면, 회사B의 모든 제품은 문제가 생긴다. 이 문제를 C++로 해결가능하나, 이 문제는 대단히 어려운 문제이며, 언어의 객체지향적인 특성을 이용하는 것이 효과적이다라는 것을 의미하지는 않는다.


후에 모듈간의 상호관계를 만듦으로써 Java는 이러한 문제를 해결할 수 있으며, 보다 직접적으로 객체지향적인 패러다임을 이용할 수 있다. 라이브러리들은 그들의 클라이언트들에게 어떠한 영향을 주지 않은 채 자유롭게 새로운 방법들과 변수들을 첨가할 수 있다.


Java는 인터페이스들을 인식한다. - 이는 클래스와 유사한 Objective C에서 빌려온 개념이다. 인터페이스는 객체가 반응할 메소드들의 집합에 대한 간단한 명세(specification)이다. 이것은 어떠한 인스턴스 변수나 구현들을 포함하고 있지 않다. 인터페이스들은 다중상속될 수 있으며, 일반적 인 클래스 상속구조와는 달리

융통성을 가지며 사용될 수 있다.


클래스들은 런타임 모습(representation)을 가지고 있다. Class라는 클래스가 있는데, 이 클래스의 인스턴스는 런타임 클래스 정의들을 포함하고 있다. C나 C++프로그램에서 사용자가 한 객체 에 대한 포인터(사용자는 포인터가 가리키는 객체의 유형을 모른다.)를 가진다면, 그 객체를 알아 낼 방법이 없다.

그러나, Java에서는 런타임 유형 정보(type information)를 이용해서 알아낼 수 있다. 컴파일 시간과 실행시 모두에 cast가 체크되므로, 사용자는 Java에서의 cast를 신뢰할 수 있다. 반면, C나 C++의 경우는 사용자가 올바르게 하고 있는지를 단지 컴파일러가 신뢰한다.


이름을 포함하는 문자열(string)이 주어졌을 때, 클래스의 정의를 알아보는 것도 가능하다. 이것 은 사용자가 데이터 유형 이름을 계산할 수 있으며, 그것을 수행중인 시스템에서 동적으로 손쉽게 연결(link)시킬 수 있다는 것을 의미한다.


자바 프로그램은 동적으로 설계했기 때문에 컴퓨팅 환경의 변화에 동적으로 적용할 수 있다. 예를 들어 대부분의 보통 C++ 개발은 다른 업체가 소유하고 개발한 클래스 라이브러리에 많이 의존하고 있다. 이렇게 운영체제나 윈도윙(windowing) 시스템과 함께 배포되는 많은 제 3자의 (third-party) 라이브러리는 동적으로 링크되어 있고, 이 라이브러리에 의존하는 애플리케이션과 별도로 팔거나 배포한다. 따라서 이러한 라이브러리를 갱신하면, 이것에 의존하는 기존 애플리케이션은 다시 컴파일하거나 다시 배포받기 전까지는 쓸모 없게 될 것이다. 이것이 소프트웨어를 유지하는 데 또 하나의 부담이 된다.


자바는 모듈을 결합하는 일을 지연함으로써, 이러한 문제점을 없앴다. 이로 말미암아 프로그래머가 객체 지향 패러다임 개념을 충분히 활용할 수 있다. 라이브러리에 있는 기존 클래스에 대한 새로운 메소드와 인스턴스 변수는 현재 프로그램, 애플리케이션, 클라이언트 파괴하지 않고도 추가할 수 있다.


이것은 자바 인터페이스는 인스턴스 변수나 메소드 구현을 배제한 채 객체 사이의 상호 작용을 지정함으로써 가능하다. 자바 클래스는 프로그래머가 실행 시간에 클래스형을 검사(실행 시간 형 식별, 곧 RTTI라고 하는 과정)하여, 검사 결과에 따라 동적으로 클래스를 연결할 수 있도록 표현된다. 이것은 C++에서는 제공하지 않는 것이다. 또한 이 실행 시간 표현은 실행 시간 말고도 컴파일 시간에 데이터 구조변환(cast)을 실행 시간 환경이 검사할 수 있도록 하여 별도의 오류 검사를 제공한다.



8) 자바는 튼튼하다.(Robust)


Java는 다양한 방면에서 신뢰성이 있어야만 하는 프로그램들을 작성하기 위해서 만들어졌다. Java는 가능한 많은 문제들에 대해서 초기에 체크를 수행하고, 후에 동적인 체크(dynamic checking)를 수행한다. 그리고, 오류가 발생한 상황들은 제거한다.


C++과 같은 강력한 형(type)기반 언어의 장점중의 하나는 컴파일을 수행하는 동안에 체크를 수행하므로써, 버그가 초기에 발견될 수 있다는 점이다. 불행히도, C++은 컴파일시간에 C로 부터 많은 틈새(loophole)를 상속한다. Java에서는 선언(declaration)을 필요로 하며, C처럼 묵시적인 선언들은 지원하지 않는다.


링커(linker)는 형(type)을 알고, 컴파일러에 의해서 행해진 많은 유형체크과정을 반복한다. 그 이유는 버전의 불일치로 인한 문제점들을 해결하기 위해서 이다.


Java와 C/C++간의 가장 큰 차이는 Java는 포인터 모델을 가진다는 점이다. 이 모델은 메모리를 덮어쓰거나 데이터를 망가뜨리는 가능성을 제거하는 특성을 갖는다. 그리고, 포인터 연산 대 신에 진정한 어레이(array)를 갖는다. 이것은 이후의 체크과정을 허용한다. 그리고, Java에서는 케스팅(casting)에 의해서 임의의 정수를 포인터로 변환하는 것이 불가능하다.


Lisp, TCL, Smalltalk와 같은 동적인 언어들이 종종 프로토타입을 만들기 위해서 사용된다. 그 이유는 견고하기 때문이다. 즉, 사용자는 메모리의 반환, 할당, 다른 데이터 영역의 침범 등을 걱정 할 필요가 없다.

프로그래머들은 상대적으로 메모리를 다루는 문제에 대해서 두려움을 갖지 않게 된다. Java는 이러한 특성을 가지고 있다.


동적인 언어들이 프로토타입을 만드는데 좋은 이유는 사용자가 초기에 만들 시스템에 대한 모 든 결정을 내릴 것을 요구하지 않기 때문이다. Java는 이와 상반된 특성을 갖는다. 즉, 사용자가 명백하게 선택할 것을 요구한다. 이러한 선택들은 많은 보조적인 도움들을 수반한다. 당신이 메소드를 작성하였고, 만일 그것을

잘못 사용한다면 컴파일 시간에 그 사실을 알 수 있다. 당신은 메소드의 사용시 오류에 대해서 근심할 필요가 없다. 그리고, 클래스들 대신에 인터페이스들을 사용함으로써 많은 융통성을 가질 수 있게 된다.


애플리케이션이 튼튼할수록 신뢰도도 커진다. 이것은 소비자뿐만 아니라, 소프트웨어 개발자 입정에서도 바람직한 것이다. 자바와 C++와 같은 대부분의 객체 지향언어는 엄격히 데이타 형을 검사한다. 이 말은 대부분의 데이터형 검사가 실행 시간이 아니라 컴파일 시간에 이루어진다는 것이다. 이로 말미암아 애플리케이션에서 많은 오류와 비정상적인 상황을 막을 수 있다. 따라서 C++의 엄격한 형검사는 무너질 수 있지만, 자바는 그렇지 않다. 결국 자바 링커를 이용하면, 모든 컴파일러 형 검사 작업을 반복함으로써 인터페이스와 메소드의 버전이 일치되지 않는 것을 막을 수 있다. C++와는 달리 자바는 명시적(explicit) 메소드 선언을 요구하며, 이

때문에 애플리케이션의 신뢰도가 높아진다.


C와의 호환을 위해 C++에서 제공하는 암시적(implicit) 선언은 위험의 여지가 있다. 다른 말로 하면, 메소드를 암시적으로 선언하면, 형 정보를 사용할 수 없다. 따라서 C++의 엄격한 형 검사는 무너질 수 있지만, 자바는 그렇지 않다. 결국 자바 링커를 이용하면, 모든 컴파일러 형 검사작업을 반복함으로써 인터페이스와 메소드의 버전이 일치되지 않는 것을 막을 수 있다.


C++와 자바의 가장 중요한 차이점은 자바의 포인터 패러다임은 포인터연산을 지원하지 않는다는 것이다. 자바는 포인터의 연결된 목록(linked lists)이 아닌 배열을 구현한다. 배열의 경우, 범위나 첨자에 대한 검사를 수행해서, 의심스럽거나 유효하지 않은 데이터를 낳을 수 있는 메모리 경계 위반이 일어나지 않도록 할 수 있다. 이것은 정수값을 정수 포인터로 변환하는 것을 자바는 인정하지 않는다는 것을 의미한다.


Tcl, Smalltalk, Lisp와 같은 동적 언어들은 프로그래머가 메모리 관리와 메모리 손상에 대해 걱정할 필요가 없기 때문에, 일반적으로 아주 튼튼한 것으로 간주한다. 이와 비슷하게 자바 프로그래머 역시 메모리를 두려움 없이 처리할 수 있다. 또한 자바를 포함한 이런 언어들에는 쓰레기 수집 (garbage collection) 기능이 있다. 이 기능 때문에 프로그래머들은 메모리 관리에 대한 당혹감과 두려움을 덜 수 있다. 다시 말해서 자바의 쓰레기 수집 기능을 이용해 메모리 손실을 완전히 제거할 수 있다.


자바를 비롯한 동적 언어들은 빠른 애플리케이션 원형화(prototyping)에 적합하다. 왜냐하면 첫번째로 이것들은 개발자가 사전에 모든 구현(implementation)을 결정하도록 요구하지 않다. 비록 자바는 뛰어난 원형화 언어지만, 구현하기 전에 모든 인터페이스를 개발자가 정의해야 한다는 점에서 기타 동적 언어와는 다르다. (이것은 사전에 모든 구현을 결정해야 한다는 말과는 같지 않다. 단지 일부에서 그렇다는 것이다.) 이렇게 함으로써 잠재적 오류가 생기기 전에 컴파일러가 걸러 낼 수가 있어, 메소드를 정확히 호출할 수 있다.


애플리케이션이 튼튼할 수록, 신뢰도는 그만큼 높아지기 마련이다. 곧 메모리 손실이 없도록 하고, 정확하게 메소드를 호출하도록 한다. 또한 자바 애플리케이션이 명시적으로 인스턴스화되지 않은 객체를 참조하는 일 따위의 메모리 위반 상황이 일어나지 않도록 한다.


9) 자바는 안전하다.

자바는 네트워크 환경을 위해 설계한 것이기 때문에, 보안 기능이 많은 주목을 받는다. 예를 들어 네트(Net)에서 다운로드한 프로그램을 실행할 경우 바이러스에 감염된 것일 수 있다. 자바 애플리케이션은 시스템 힙(heap), 스택(stacks) 또는 메모리에 액세스할 수 없기 때문에, 저항력이 강하고 바이러스로부터 안전하다. 자바에서는 사용자 확인 과정을 공용키(public-key) 암호화(encryption) 방법으로 구현한다. 이렇게 함으로써 해커와 크래커(crackers)들이 계정명과 비밀번호와 같은 보호된 정보를 보지 못하도록 효과적으로 막을 수 있습니다.


>안정성

자바는 컴퓨팅 환경을 변경할 만한 내용을 근본적으로 갖고 있지 않기 때문에 안전하다. 다른 말로 하면 프로그램 스택을 변경하거나, 할당하지 않은 메모리를 변경 또는 접근하거나, 운영 체제 커널의 동의 없이 객체와 해당 메소드를 참조하는 코드를 작성할 수 없다. 이것은 자바가 포인터와 암시적 형 강제(implicit type coercion) 기능이 없기 때문이다. 이것은 실행 시간 환경에서 보안 변경을 허용하지 않는 자바 의미론(semantics) 등의 기술, 유효하지 않은 메모리 참조를 막는 자바의 가상 기계 설계, 언어에서 데이터 형 변환금지, 그리고 적합한 의미론과 참조를 보장하는 바이트코드 검사 등을 통해 이루어 진다. 핫자바는 주로 자바 애플릿을 제어함으로써 안정성을 유지한다. 애플릿은 시스템 수준 서비스에 대한 접근을 엄격히 제어하는 NetClassLoader라는 제한적인 클래스 로더(loader)와 함께 불러온다. 예를 들어 NetclassLoader로 불러온 다른 클래스에서 File 클래스를 호출하면, File 클래스는 해당 메소드에 대한 엄격한 제한을 가한다. 핫자바는 애플릿을 통해 파일과 디렉토리에 대한 접근을 제어한다. 예를 들어, 애플릿은 기본적으로 UNIX 시스템의 /tmp/hotjava와 ~/.hotjava라는 두개 디렉토리의 시스템 파링에만 접근할 수 있다. 별도의 파일 디렉토리들은 HOTJAVA_READ_PATH와 HOTJAVA-WRITE_PATH환경 변수를 수정해야만 추가할 수 있다.


>보안성(Secure)

Java는 네트워크환경이나 분산환경에서 사용하기 위해서 만들어졌다. 궁극적으로는 보안 (security)에 많은 초점이 모아지고 있다. Java는 virus-free혹은 tamper-free시스템들의 구축을 가능케 한다. 인증 기술들(authentication techniques)은 공중키(public key)암호화에 기반을 두고 있다.


견고함(robust)과 보안(secure)간에는 강한 상호작용이 있다. 예를 들어, 포인터들의 의미를 변경 한다는 것은 응용프로그램들이 이전에 접근 가능했던 객체의 자료나 자료구조의 접근을 불가능하게 만든다. 이것은 바이러스들의 대부분의 활동들에 대해서 문을 닫는 것과 같은 것이다.


자바는 새로운 객체의 메모리 할당이 new 연산자를 통해 명시적으로 이루어지기 때문에 안전하다. 또한, 메소드 호출은 프로시저를 실행할 수 있는 유일한 방법이다. 이 기능은 객체 지향 패러다임의 일부이다. new연산자는 ClassLoader라는 시스템 수준의 클래스에 의존한다. 이것은 불러오는 클래스에 엄격한 보안 규칙을 적용하다. 그 결과로 ClassLoader 클래스형은 인스턴스화한 모든 클래스에 허용될 기능을 조정하는 역할을 한다. 핫자바는 애플릿 활동을 자세히 관찰한다.

이것은 특정 이벤트에 따라 애플릿 기능을 변경 할 수 있다. 예를 들어 NetClassLoader는 각 애프릿에 의한 소켓 또는 파일 조작에 관한 정보를 관리한다. 의심스럽거나 확인되지 않은 일이 생기면, 핫자바는 애플릿의 행동을 변경하여 잠재적인 보안의 허점을 막을 수 있다.


>신뢰성

자바는 특정 클래스를 불러오기 전에 해당 클래스의 전자 서명을 검사할 수 있는 ClassLoader 클래스형을 제공한다. 이것은 다른 시스템으로부터 클래스를 생성하면, 다른 기능을 부여받을 수 있다는 것을 의미한다. 또한 클래스는 ClassLoader를 검사하여 믿을 만한 클래스로부터 호출한 것인지를 판단할 수 있다. 핫자바는 신뢰성 있는 자바 코드이다. 프로그램에 대한 대중의 신뢰를 얻을 수 있도록 소스코드는 일반인들이 사용할 수 있다. 또한 브라우저로 임의로 변경하는 것을 막기 위해 모든 브라우저 클래스에 전자 서명(signature)을 부여할 계획을 갖고 있다.


10) 자바는 간단하다.


자바의 주 설계 목표는 객체 지향 개발 환경의 빠른 확산을 위해, 가능한 한 C++에 가까운 언어를 만드는 것이다. 또 하나의 설계목표는, 소프트웨어를 개발, 구현, 유지하는 단계에서 이해를 어렵게 하고 혼란을 주는 C++의 모호하고 좋지 않은 기능을 제거하는 것이다. 이런 기능으로는 다중 클래스 상속, 자동 데이터형 강제를 지원하는 다중 정의(overloading)연산자가 있다.


자바의 설계자들이 쓰레기 수집(garbage collection) 기능을 포함시켰을 때 희생을 감수해야 했다. 다시 말해서 프로그래머에게서 메모리 관리라는 짐을 덜어주었지만, 반대로 자바 실행 시간 시스템의 복잡성은 늘어났다. 자바의 쓰레기 수집 기능은 객체 지향프로그래밍의 부담을 줄여주고, 고질적인 소스 코드 버그를 줄이는데 크게 기여했다. 따라서 실행 시간 시스템을 더욱 복잡하게 함으로써(각 플랫폼에 대해서 한번만 구현하면 된다), 자바 설계자들은 자바 애플리케이션을 더 간단하고 더 쉽게 코딩할 수 있도록 하였다.


결국 자바는 작기 때문에 간단하다. 약 175K의 RAM을 요구하는 멀티쓰레딩 지원과 표준 라이브러리를 제외하면, 기본 자바 해석기는 40K의 RAM을 차지한다. 필요한 메모리를 전부 합하더라도, 다른 프로그래밍 언어와 환경에 비교해 볼 때 아주 작은 양이다.


간단함이 주는 도움을 보면, 코드를 입력하고 버그를 잡는데 시간이 적게 걸리며, 문제를 해결하고 소비자를 만족시키는데 더 시간을 투자할 수 있다. 또한 간단하기 때문에, 삽입된(embedded) 시스템이나 오래된 컴퓨터처럼 작고 원시적 메모리 모델만을 제공하는 컴퓨터에서도 자바 프로그램을 실행 할 수 있다. 또한 자바의 간단함으로 말미암아 C++와는 달리 어렵지 않게 배울 수 있어서, 언어를 새로 시작하는 사람을 교육하는데 시간이 적게 걸린다.




11) 자바는 높은 성능을 제공한다.(High Performance)


인터프리트된 바이트코드들의 성능이 일반적으로 적절한 수준 이상이지만, 경우에 따라서는 높은 성능을 요할 때가 있다. 바이트코드들이 수행시 응용프로그램이 도는 특정 CPU의 머신코드로 변환될 수 있다.

컴파일러나 동적로더(dynamic loader)의 정상적인 설계에 익숙한 사람들에게 있어서는 이러한 변환은 동적로더에 최종 머신코드 생성기를 집어넣은 것과 같다.

바이트코드 포맷은 원래 머신코드를 생성하도록 설계되어서, 머신코드의 실제적인 생성은 일반적으로 간단하다. 합리적인 좋은 코드가 생성된다. 즉, 자동적인 레지스터할당이 이루어지고, 컴파일러는 바이트코드 생성시 일종의 최적화를 수행하므로, 좋은 코드가 생성된다.


인터프리트된 코드의 경우, Sun MicroSystems사의 SPARCStation 10상에서 초당 300,000 메소드 콜을 수행한다. 머신코드로 변환된 바이트코드의 경우, C나 C++과 성능 차이가 없다.


바이트코드 객체의 해것에서 괜찮은 성능을 제공하는 경우는 많이 있다. 하지만 어떤 상황에서는 더 높은 성능이 필요하다. 자바에서는 고유 기계 코드로 실행 시간 바이트코드 번역을 제공함으로써 이것이 가능하다.


바이트코드 포맷의 설계는 이것을 고려한 것이다. 고유 기계 코드의 생성은 비교적 간단해서, 훌륭한 기계 코드를 만들어 낸다. 고유기계 코드로 해석하는 바이트코드의 성능은 현재 C와 C++ 컴파일러로 생성하는 기계 코드와 견줄만 하다.


높은 성능 때문에, 클라이언트와 서버 기능을 모두 광범위하게 확장할 수 있는 작고 빠른 프로그램으로서 웹 자바 애플리케이션을 구현할 수 있다.


Summary


Java언어는 프로그래머들이 임의로 사용하는 툴들에 그 능력을 한층 배가 시킨다. Java는 프로그래밍을 보다 쉽게 만드는데, 그 이유는 Java가 객체지향적이며 자동적인 가배지 수집과정을 가지고 있기 때문이다.

이외에, 컴파일된 Java 코드는 컴퓨터 구조에 중립적이어서 Java 응용 프로그램들은 인터넷과 같은 다양한 환경에서 이상적이다. "