Posted by 김덕태 on August 11, 1997 at 19:29:48:
김 형 국 wrote:
>
> 썬(Sun Microsystems)사가 망하지 않는 이상
> 좀 있으면 자바에 generic definition 기능이 추가됩니다.
> (너무 확신에 찬 발언인가 ?...)
저는 그런 정보를 본 적이 없습니다.
어디서 그런 정보를 얻으셨는지 모르겠지만, 단지 추측이
아니시라면, 정보 소스를 알려주시기 바랍니다.
그런 일이 일어날 가능성이 매우 희박하다고 생각하고 있기때문입니다.
우선, generic definition이란 것이 정확히 어떤 것을 의미하는 것으로
사용하신 것인지는 모르겠으나, #define, typedef와 같은 alias기능과
C++의 template과 같은 generic type definition 2가지를 의미하는 것으로
보겠습니다.
1. #define의 기능
- 상수를 정의하는 용도
자바의 클래스 상수로 충분
- 함수를 정의하는 용도 (보통 속도때문)
자바의 보통 메쏘드로 충분 (속도를 올리기위해서는 final로
메쏘드를 선언하고, 컴파일할 때 javac -O으로 컴파일하면
보통 inline이 되어 매크로와 같은 속도 개선 효과를 가지나,
이는 자바의 HotSpot 기술과 같은 실행시에
최적화하는 기술이 일반화될 때는 그럴 필요가 없어집니다.
따라서, C/C++ 설계 마인드보다는 휠씬 더 인간적입니다.
그런일은 궁극적으로 컴퓨터가 해 줄 일이지,
사람이 할 일이 아니기때문입니다.)
- 언어의 일부 문법을 바꾸어주는 기능
이것이 과연 바랍직할까요?
이걸 남용하면, 거의 다른 언어처럼 보여서 이해하기
곤란한 프로그램이 되면서도, 그 기능성은 충분하지 못합니다.
이런 용도는 자바 언어를 확장하는 것보다는
특정 용도에 맞는 자바 확장 문법을 따로 정의하고
이를 처리하는 전처리기를 만들어, 이 전처리기에 의해
자바 소스 코드를 생성하는 것이 더 강력하며 편리할 것입니다.
이미, 자바용 컴파일러-컴파일러나 JDBC보다 더 편리한
자바에서의 embedded SQL은 이러한 방향으로 나가고 있습니다.
2. typedef 기능
이전에 제가 올린 예제 프로그램과 같이 클래스나 인터페이스로 가능합니다.
3. template 기능
- C++의 class template, function template은 그 기본적인 개념은
상당히 깔끔하고 강력하며, 컴파일시에 좀더 엄밀하게 형검사를
할 수 있다는 등의 장점이 있습니다. 또한, 이를 이용하여
만든 STL (Standard Template Library)로 인해 C++의 확산에
중요한 요소가 되었다고 알려져 있습니다.
- 그러나, 현재의 template은 상당히 복잡한 문법을 가지며,
어느 시점에서 template instance를 만들어내야 할 것인가가
엄밀하게 표준화되어 있지 않아서, 사용 환경마다 저마다
다른 방식을 사용합니다.
자바에 template이 도입된다면, 이들 문제가 해결되어야 할 것이나,
쉬운 문제는 아니라고 생각하며, 깨끗한 해결책이 과연 존재하는 지
저로서는 잘 모르겠습니다.
- 자바에서는 STL에 대응하고, 그 기능성을 갖는, 그러나 기존의
문법만으로 만든 표준 패키지인 Collection API를 준비하고 있습니다.
(java.util에도 Vector나 Stack등이 있지만, 라이브러리 전문가가
만든 것이 아님을 알 수 있습니다. 좀 조잡하지요.)
그래서, 이 분야에서 두각을 나타내는 objectspace사의
jgl (Java Generic Library) 패키지를 모델로 하여 수정을 가한 후,
표준화 될 것입니다.
따라서, template을 자바에 도입해야만 하는 절대적 필요성은
일단 없는 셈이므로, 도입되지 않을 가능성이 높다고 봅니다.
- 자바에서 template에 대응하는 방법은 모든 배열과 객체는 모두
Object 클래스의 하위 자료형이라는 것과 이들 참조형의 형변환,
실행시 형변환 검사, Integer와 같은 wrapper 클래스에 의존합니다.
가령, java.util 패키지의 Vector 클래스는 Object 클래스의 객체 배열을
갖는 객체를 정의하는 데 사용되나, 언급한 기능을 사용하여
Date 객체의 Vector, int 값의 Vector를 모두 하나의 클래스인 Vector로
해결합니다.
이와 같이 사용했을 때의 문제점은
1. 기본자료형 자료를 사용할 때는 wrapper 클래스 객체를 만들어
변환시켜야 한다.
예) Vector vec = new Vector(); vec.addElement(new Integer(3));
2. 컴파일시에 완전하게 자료형 검사가 이루어지지 않고, 실행시간에
자료형 검사가 이루어진다.
예) int i = ((Integer) vec.elementAt(0)).intValue();
// vec.elementAt(0) 참조값이 나타내는 객체의 실제 자료형이
// Integer가 아니면, ClassCastException 발생
3. 소스 코드에서 Vector라는 자료형만으로는 어떤 자료형의
객체로 이루어진 것인지를 알기 어렵다.
예) vec에는 어떤 자료형의 객체가 들어가있는 것일까?
==> 문서화해야 합니다.
Vector vec = new Vector(); // Integer의 Vector
이와 같이 프로그래밍하는 것이 자바에서는 일반화된 방법입니다.
문법 자체는 복잡하지 않으면서도 강력하지만,
사용하기엔 다소 불편하지요.
자바의 의미론이 C/C++보다 쉽다라고 단정적으로 말하기는 곤란합니다.
그러나, C/C++와 비교한다면 다음 각 부류에 따라 달라질 것입니다.
1. 프로그래밍 언어를 처음 접하는 초보자
C/C++는 클래스 개념없이 배우고, 사용할 수 있으며,
후에 클래스와 같은 OOP개념을 추가적으로 배울 수 있습니다.
즉, 단계적으로 배울 수 있으나, 자바에서는 클래스, 객체,
참조값의 개념에 일찍 익숙해져야 하므로, 더 여려울 수
있습니다.
그러나, 후에 비슷하지만 약간씩 다른 다양한 언어 기능 및 이를 지원하는
복잡한 문법 구조와 그 의미에 익숙해지는 데 어려움을
겪게 될 것이며, 또한 그동한 배운 언어의 풍부한 기능성을 제대로
이용해보지도 못하는 경우가 많을 것입니다. (특히, C++)
2. C/C++에 경험이 있는 자
C/C++의 의미론과 자바의 의미론의 차이가 상당하기 때문에
자바에서의 클래스, 객체, 참조값의 의미를 자세히
알 필요가 있으며, 그렇지 않으면 문법상 겉보기에 비슷하다하여
의미론도 비슷하다고 생각하면 상당히 혼란에 빠지게 됩니다.
자바의 메모리 모델과 객체등에 대해서 좀 자세하게
소개된 책을 먼저 보시면 상당히 쉽게 자바를 이해할 수 있으나,
그런 책이 거의 없더군요. (저 역시, 처음에 자바를 접할 때 이때문에
상당히 혼란스러웠습니다.)
자바의 (논리적) 메모리 모델은 쓰레드마다 스택이 있고,
각 쓰레드가 실행하는 메쏘드의 모든 지역변수와 매개변수는
해당 스택에 저장됩니다.
생성된 모든 객체는 무조건 힙에 저장되고 쓰레드사이에 공유됩니다.
클래스 변수와 메쏘드 몸체는 메쏘드 영역이라는 영역에 따로
저장되고 클래스가 로드되면, 오직 한번 초기화되고, 객체들 사이에
공유됩니다.
객체에 접근하기 위해서는 반드시 해당 객체의 클래스, 인터페이스
자료형의 참조값을 얻어야 하며, 이를 통하여 접근할 수 있습니다.
추상적인 객체 지향 개념을 장황하게 소개하는 책보다는
이런 의미론에 대해 그림과 곁들여 구체적으로 소개하는 책을
찾아서 공부하십시오.
3. 문법에 익숙한 자.
C/C++의 문법은 문법 자체만으로도 배워야 할 것이 끊임없습니다.
어느 책에선가 본적이 있는 데, 아무리 C언어에 능숙한 프로그래머라
할지라도, 때로는 특정 C 프로그램의 결과에 대하여 의아하게
생각한다고 하더군요. C++는 한 술 더 뜹니다.
하지만, 이보다 더 심각한 것은 그리고 가장 골치아프게 하는 것은
C/C++ 언어와 표준 라이브러리 사양 문서의 곳곳에 산재하는
`behavior undefined', `implementation dependent'입니다. 정말 싫더군요.
엄밀한 표준 사양 문서를 보아도 확실하게 어떻게 동작한다는 것을
알 수 없으면, 이해하기 곤란하고 표준 사양에 맞추어
프로그래밍하기도 상당히 곤란하기때문입니다.
따라서, 때로는 특정 컴파일러나 실행환경에서 어떻게 동작하는 지를
따로 조사해보아야 하며, 종종 프로그램 버그의 중요한 요소가 됩니다.
또한, 표준 ANSI C, C++ 라이브러리는 그 양이 적지 않음에도 불구하고,
이것 만으로 의미있는 프로그래밍을 하기가 거의 불가능합니다.
의미있는 프로그래밍을 하기 위해서는 플랫폼마다 따로 정하는
라이브러리 표준에 따라 프로그래밍해야 하나, 많은 경우 사실상 비슷한
일을 하는 것을 전혀 다르게 프로그래밍해야 한다는 것입니다.
예를 들어, MFC, Motif, X Window, POSIX, SVID, BSD, Win32 API 등등등
매우 많지요.
`라이브러리는 언어이다'라는 말이 있을 만큼, 특정 프로그래밍 언어에서
충분한 기능성을 제공하는 표준 라이브러리의 존재 여부는 프로그래밍
편리성, 용이성, easy to learn의 관점에서 언어의 문법보다 휠씬 더 중요한
요소가 될 수 있습니다.
물론, 하나의 환경 및 하나의 컴파일러만을 사용하는 사람에게는 이것은
그다지 중요한 요소가 아니라고 생각할 것입니다.
그러나, `요람에서 무덤까지', `배움에서 구현까지' 이것이 가능할 까요?
더 많은 플랫폼에서 동작할 수 있는 프로그램, 다양한 플랫폼에서
분산되어 무리없이 동작하는 프로그램의 요구가 확산되는 추세는
이를 더욱 어렵게 할 것입니다.
따라서, 자바 언어를 주축으로 프로그래밍하고,
자바가 할 수 없는 것은 C, C++로 작성하여 네이티브 라이브러리, 혹은
네이티브 프로그램으로 만들어서 하는 방식이 바람직하다고 봅니다.
즉, C/C++에서 곤란한 것을 때로는 어쌤블리어로 작성하듯이
자바에서 곤란한 것은 C/C++로 작성하는 것이며, 이는 C/C++를
어쌤블리언어 처럼 사용하는 것입니다.
그렇다고, 모든 자바 프로그래머가 C/C++를 능숙하게 다룰 필요는 없습니다.
대부분의 C/C++ 프로그래머가 어쌤블리 프로그래밍을 할 필요가 없듯이...
그 이유는, 많은 경우 특정 플랫폼의 어쌤블리에 특화된 프로그래머가
어쌤블리언어를 섞어서 만든 C/C++ 라이브러리를 제공하고
일반 프로그래머는 이를 가져다 사용하는 것으로 충분하기 때문입니다.
이는 자바의 경우에도 마찬가지여서, 표준 패키지라고 하는 것들도
대부분 그 밑바탕은 네이티브 라이브러리로 작성되어 있고, 이는
자바 가상 머쉰을 구현하여 제공하는 썬사를 주축으로한 여러회사,
집단, 개인이 해줍니다.
또, third party 패키지도 이와 같이 구현된 것일 수 있습니다.
--
Deogtae Kim (김덕태)
CA Lab. CS Dept. KAIST