spring로 검색한 결과 :: 시소커뮤니티[SSISO Community]
 
SSISO 카페 SSISO Source SSISO 구직 SSISO 쇼핑몰 SSISO 맛집
추천검색어 : JUnit   Log4j   ajax   spring   struts   struts-config.xml   Synchronized   책정보   Ajax 마스터하기   우측부분

회원가입 I 비밀번호 찾기


SSISO Community검색
SSISO Community메뉴
[카페목록보기]
[블로그등록하기]  
[블로그리스트]  
SSISO Community카페
블로그 카테고리
정치 경제
문화 칼럼
비디오게임 스포츠
핫이슈 TV
포토 온라인게임
PC게임 에뮬게임
라이프 사람들
유머 만화애니
방송 1
1 1
1 1
1 1
1 1
1

spring로 검색한 결과
등록일:2008-03-12 10:53:40
작성자:
제목:J2SE 1.5 환경에서의 개발 능력 향상과 새로운 개발 언어의 특징


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)를 통해 이루어졌다. 수정 사항들이 현 시점에서 정확하게 구현이 될 것인지, 또 개발자들은 어떤 형태로 참여하게 되는지 궁금하다.

 

A:AJSR(14, 201 및 175)과 관련한 전문가 그룹이 현실적으로 구현 가능한 초안을 다듬었다. 이 초안의 전체적 내용은 최종 릴리즈와 별 차이가 없을 것이라고 확신한다. 가장 바람직한 개발자의 참여 방법은 우선 제시된 안을 살펴보고 관련 전문가 그룹에게 의견을 전달하는 것이다. Generics에 관한 최근 초안의 내용은 http://jcp.org/aboutJava/communityprocess/ review/ jsr014/에서 볼 수 있다. 또한 http://developer.java. sun.com/ developer/earlyAccess/adding_generics/에서 임시 버전의 컴파일러를 다운받아 활용하면 generics에 대한 이해를 높일 수 있고, 시험 작업을 시도하는데 도움이 될 것이다
.
다른 언어로 작성된 제안서 초안의 내용은 http://www.jcp.org/ en/jsr/detail?id=201에서 확인할 수 있다. 페이지 끝부분에 있는 3.1절의 내용을 참조하기 바란다. 이밖에 JSR-175(Metadata) 관련 초안도 곧 나올 예정이다(http://www.jcp.org/en/jsr/detail?id =175).

 

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

 

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

 

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

 

A:주요 특징을 간단하게 말하면 다음과 같다.

● 일반화 용법(Generics) - 컬렉션과 관련하여 컴파일 시 데이터 타입의 안전성(Compile-time Type Safety)을 제공하며, 성가신 캐스팅(데이터 타입 변환) 작업이 필요 없다.

● 향상된 for 반복문(Enhanced for loop) - 성가신 반복 작업과 이로 인한 오류 발생을 신경 쓰지 않아도 된다.

● 기본 데이터 타입/랩퍼 데이터 타입의 자동 변환 처리(Autobox-ing/ Unboxing) - 예를 들어 int 같은 기본 타입과 Integer 같은 랩퍼(Wrapper)를 수동으로 변환할 필요가 없다.

● Typesafe enums - 잘 알려진 Typesafe Enum 패턴(Effective Java, Item 21)의 이점을 제공하며, 복잡성 및 오류 발생 가능성이 없다.

● Static Import - 클래스 스코프를 가진 정식 정적 멤버(Static Member)를 피할 수 있으며, Constant Interface 안티패턴(Effective Java, Item 17)의 단점을 걱정할 필요가 없다.

● 메타데이터(Metadata) - 툴을 통해 소스 코드의 주석으로부터 반복 사용 코드를 생성하게 함으로써 코드 작성의 수고를 덜 수 있다. 이는 결국 프로그래머들이 말하는 “반드시 실행되어야 하는 것을 툴로 하여금 수행하게 만든다”는 개념의 선언형 프로그래밍과 연관이 있다.

 


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하는 방법을 예로 들어보자.

 

void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}


이번에는 동일한 방법에 ‘enhanced for’문을 이용한 경우다.

void cancelAll(Collection c) {
for (Object o : c)
((TimerTask)o).cancel();
}


이 명령문을 소리 내어 읽을 때 콜론(:)은 ‘in’으로 발음한다. 아마도 새로운 키워드인 foreach와 in을 사용하는 것이 더 자연스러운 것일 수도 있겠지만 이들은 불안정하다는 단점이 있다. 즉, 새로운 키워드를 식별자로 사용한 기존의 소스들이 깨질 수 있다.

 

Q:Qgenerics와 ‘enhanced for’ 루프의 결합이 가능한가?

 

A:물론이다. 기존 내용에 generics를 추가한 다음 예를 살펴보자.

void cancelAll(Collection<TimerTask> c) {
for (TimerTask task : c)
task.cancel();
}

상당히 괜찮지 않은가? 이제 부팅을 위한 compile-time type safety가 제공된다.

 

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을 버리는 것인데, 이 두 가지 대안 모두 나름대로의 장점을 지니고 있다.

 

널(null)을 0으로 변환 또는 대체(unbox)하면 위의 한 경우처럼 애플리케이션의 모양새는 좋아지지만 실제 오류를 찾아내지 못할 수 있다는 단점이 있다. 누군가가 더 좋은 방법을 알고 있다면 이 문제에 대한 논란을 종식시키기 위해서라도 JSR-201 전문가 그룹에 알려주기 바란다.

 

Q:일반적인 int enum 패턴과 비교했을 때 새로운 typesafe enums의 장점은 무엇인가?

 

A:이에 관한 부분은 본인 저서의 ‘Item 21’에서 상세하게 다루고 있으니 여기선 아주 간략하게 설명하겠다.

● int enums는 어떠한 타입의 safety도 제공하지 않는 반면에 typesafe enums는 compile-time type safety를 제공한다.

● 열거형에 적절한 네임 스페이스를 제공한다. int enums의 경우에 네임 스페이스와 유사한 효과를 보기 위해서는 상수를 앞에 붙여야 한다.

● typesafe enums는 안정적인 반면 int enums는 클라이언트로 컴파일된다. 따라서 상수의 추가, 제거 및 재요청 시 클라이언트를 재컴파일해야 한다.

● typesafe enums의 경우 인쇄된 값을 정보로 활용할 수 있지만 int enum은 단순히 숫자만 인쇄되어 나온다.

● typesafe enums는 객체이므로 이를 컬렉션에 포함시킬 수 있다.

● 원래 typesafe enums는 클래스이므로 임의의 필드나 메소드를 추가할 수 있다.

 

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문과 관련한 새로운 언어 기능을 활용할 수 있는 것이다.