Bloch씨는 Core Java Platform Group 소속 기술자로서 유명한 Java Collections Framework를 설계, 구현한 당사자다. Bloch씨는 Software Develop-ment Magazine의 Jolt Award 대상을 수상한 ‘Effective Java Programming Language Guide’의 저자이기도 하다. 또한 그는 Carnegie-Mellon University의 컴퓨터 사이언스 박사 학위를 소지하고 있으며 다양한 기사들과 연구 논문을 낸 바 있다. 누구보다도 자바에 대해 잘 알고 있는 그에게 자바 프로그래밍 언어의 향후 전망에 대해 들어본다.

Q:J2SE 의 기능상 개선 사항은 호환성에 영향을 미치지 않고도 보다 정확하고 안전하게 그리고 신속하고 쉽게 프로그램을 개발할 수 있도록 하는데 초점이 맞추어져 있다. 그렇다면 J2SE 1.5(Java 2 Platform, Standard Edition 1.5)에서 개선된 자바 언어의 특징은 무엇인가?

A:새 로운 언어 기능들은 모두 한 가지 공통점을 가지고 있다. 즉, 공통된 표현 형식이 사용되고, 이를 위한 언어적 지원이 제공된다. 다시 말해 프로그래머가 아닌 컴파일러가 반복 사용 코드(Boilerplate code) 기록 작업을 대신 수행하게 되는 것이다. 따라서 쓰기 및 읽기 작업이 쉬워지며, 또한 프로그래머와는 달리 컴파일러는 절대로 실수를 하지 않으므로 최종 코드에서 버그가 발생할 가능성도 그만큼 줄어들게 된다.
특히 각 부분들을 조합하여 기능을 개선하는 것보다 전체적인 측면에서의 조화에 역점을 두었다. 즉, 새로운 모든 기능들은 서로 간에 잘 조화를 이룰 수 있도록 설계되어 언어의 표현 방식과 안전성 면에서 성능이 대폭 향상되었다.

Q:개발자가 수정하는데 가장 곤란을 겪게 될 사항으로는 어떤 것이 있는가?

A:특 별히 개발자가 수정할 필요가 있는 부분은 없지만, 굳이 한 가지를 꼽으라면 개발 언어의 Generic을 들 수 있다. 선언문에 추가 정보를 제공해야 하는 경우가 발생할 수 있기 때문이다. 이 경우에는 a대신 b와 같이 수정한다.

a. List words = new ArrayList();
b. List<String> words = new ArrayList<String>();

첫 번째 코드를 분석하면 문자열이 아닌 것을 입력하려 하면 컴파일 시점에서 문제가 발생하게 되고 그때서야 수정이 이루어지게 되는 것을 의미한다. 만일 generics가 없다면 여러분의 가장 중요한 고객이 당신에게 문제가 있음을 연락하고 나서야 해당 버그가 발견될 것이다. 또한 당신은 고객의 업무에 사용하는 프로그램이 단지 ClassCastExeption에 걸려 문제가 발생한 것이라고(입력 데이터 형식이 틀려서 문제가 생긴 것이라고) 알려주게 될 것이다.
반면 두 번째 코드는 컬렉션에서 엘리먼트 액세스 시 캐스트 작업이 필요 없음을 뜻한다.

String title = ((String) words.get(i)).toUppercase();

이를 단순화하면 다음과 같다.

String title = words.get(i).toUppercase();

Q:썬 마이크로시스템즈가 지난 2월 10일 J2SE 1.5 베타판을 발표했다. 이번 버전의 수정 부분은 전적으로 JCP(Java Community Process)를 통해 이루어졌다. 수정 사항들이 현 시점에서 정확하게 구현이 될 것인지, 또 개발자들은 어떤 형태로 참여하게 되는지 궁금하다.

Q:새로 향상된 6가지 기능에 대해 간략하게 설명해 달라.

A:새 로운 언어 기능들은 모두 한 가지 공통점을 가지고 있다. 즉, 공통된 표현 형식이 사용되고, 이를 위한 언어적 지원이 제공된다. 다시 말해 프로그래머가 아닌 컴파일러가 반복 사용 코드(Boilerplate code) 기록 작업을 대신 수행하게 되는 것이다. 따라서 쓰기 및 읽기 작업이 쉬워지며, 또한 프로그래머와는 달리 컴파일러는 절대로 실수를 하지 않으므로 최종 코드에서 버그가 발생할 가능성도 그만큼 줄어들게 된다.
특히 각 부분들을 조합하여 기능을 개선하는 것보다 전체적인 측면에서의 조화에 역점을 두었다. 즉, 새로운 모든 기능들은 서로 간에 잘 조화를 이룰 수 있도록 설계되어 언어의 표현 방식과 안전성 면에서 성능이 대폭 향상되었다.

Q:J2SE 의 기능상 개선 사항은 호환성에 영향을 미치지 않고도 보다 정확하고 안전하게 그리고 신속하고 쉽게 프로그램을 개발할 수 있도록 하는데 초점이 맞추어져 있다. 그렇다면 J2SE 1.5(Java 2 Platform, Standard Edition 1.5)에서 개선된 자바 언어의 특징은 무엇인가?

Q:현재 specifics로 옮겨가고 있는 추세이며, generics는 이미 시작됐다고도 볼 수 있다. 그렇다면 요즘의 컬렉션 필터링과 generics를 사용한 컬렉션 필터링은 어떻게 다른가?

A:우선 요즘에 사용하는 컬렉션 필터링 방법은 다음과 같다.

/**
* Remove the four-letter words from the specified
* collection, which must contain only strings.
*/
static void expurgate(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
String s = (String) i.next();
if(s.length() == 4)
i.remove();
}
}

별 로 훌륭해 보이지는 않는다. 더욱 중요한 것은 런타임 시(실행 중일 때) 실패할 가능성이 있다는 것이다. 사용자가 문자열이라기보다는 문자열 버퍼를 포함하고 있는 컬렉션을 우연히 통과한다고 생각해 보라. 주석에는 클라이언트가 문자열 컬렉션만 처리한다고 쓰여 있지만 결국 컴파일러는 주석이 시키는 대로 작업을 처리할 수 없다.

동일한 방법에 generics를 이용한 경우를 살펴 보자.

/**
* Remove the four-letter words from the specified collection of strings.
*/
static void expurgate(Collection<String> c) {
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}

메 소드 시그니처(Method Signature)를 통해서 알 수 있듯이 입력 컬렉션에는 문자열만 포함되어야 한다. 클라이언트가 문자열 버퍼 컬렉션으로 통과하려 할 경우 프로그램은 컴파일을 수행하지 않는다. 또한 알아두어야 할 것은 메소드는 어떠한 캐스트도 포함하지 않는다는 점이다. 일단 generics 읽기에 익숙해지면 이 방법이 상당히 유용하다는 사실을 알게 될 것이다.

Q:향상된 for 반복문(enhanced for)’에 대해 알고 싶다.

A:컬 렉션 반복(Iterating) 작업은 차라리 하지 않는 것보다 못하다. 왜냐하면 컬렉션 반복 작업이 이루어지는 동안 대부분 구성 요소(Element)를 액세스하는 경우를 제외하고는 반복자(Iterator)를 사용할 일이 없기 때문이다. 반면, ‘Enhanced for’문은 컴파일러로 하여금 반복자를 처리할 수 있도록 한다. 반복자를 사용하여 Timer Task 컬렉션을 Traverse하는 방법을 예로 들어보자.

Q:Autoboxing에 대해서도 설명해 달라.

A:이 미 알고 있듯이 Java 프로그래밍 언어에는 ‘분리형 시스템(Split Type System)’이 사용된다. 이 중 일부 타입으로 기본형(Primitives)과 객체 참조형(Object References)을 들 수 있다. 한편, 기본형은 컬렉션에 포함시킬 수 없다. 컬렉션에 저장할 필요가 있을 경우에는 결국 int 같은 기본형과 integer 같은 랩퍼형 간을 전환시켜주어야 한다. 하지만 이 작업의 결과가 그다지 만족스러울 수는 없다. 다음 프로그램을 예로 들면, 커맨드 라인에 워드 도수분포표가 생성된 것을 알 수 있다. 여기에는 Map이 사용되는데, 이 Map의 키는 워드를, Map의 값은 라인에 각 워드가 발생한 횟수를 나타낸다.

public class Freq {
private static final Integer ONE = new Integer(1);

public static void main(String args[]) {
// Maps word (String) to frequency (Integer)
Map m = new TreeMap();

for (int i=0; i<args.length; i++) {
Integer freq = (Integer) m.get(args[i]);
m.put(args[i], (freq==null ? ONE :
new Integer(freq.intValue() + 1)));
}
System.out.println(m);
}
}

카운트를 늘리는 내부 루프 코드가 얼마나 성가신 것인지 확인할 수 있다. 이제는 ‘autoboxing’, ‘generics’, 그리고 ‘enhanced for’ 루프로 작석한 동일한 프로그램을 비교해 보자.

public class Freq {
public static void main(String args[]) {
Map<String, Integer> m = new TreeMap<String, Integer>();
for (String word : args)
m.put(word, m.get(word) + 1);
System.out.println(m);
}
}

훨 씬 낫지 않은가? 이 프로그램에서 한 가지 주목할 만한 점은 널(null)을 기본형으로 자동 변환하면 0이 나온다는 것을 전제로 한다는 것이다. 하지만 이것이 그런 경우에 해당하는 지에 대한 논란은 지금도 계속되고 있다. 또 다른 대안은 NullPointerException을 버리는 것인데, 이 두 가지 대안 모두 나름대로의 장점을 지니고 있다.

Q:그렇다면 새로운 typesafe enum 언어 기능은 Typesafe Enum 패턴과 어떤 연관성을 가지고 있는가?

A:근사 해석법 차원에서 보면 단순히 패턴에 대한 언어적 지원이라 할 수 있다. 패턴과 관련한 오류 유발성 코드(error-prone code)는 우리에게 익숙한 C/C++ enum 선언과 유사해 보인다.

enum Season { winter, spring, summer, fall }

그 렇지만 기능 면에서 근본적으로 C/C++ enum과는 다르다. 개발자들은 typesafe enums를 통해 앞서 언급한 여러 훌륭한 기능들을 모두 사용할 수 있다. 심지어는 Typesafe Enum 패턴의 치명적 결점을 보완할 수 있다. 즉, switch문과 관련한 새로운 언어 기능을 활용할 수 있는 것이다.