01.JAVA/Java2008. 8. 19. 16:49
반응형

Java 맵 컬렉션 클래스의 소개

 

 

Map 인터페이스와 메소드의 이해

 

Java 코어 클래스에는 여러 가지 사전정의된 Map 클래스가 존재합니다. 구체적인 구현 방식을 설명하기 전에 Map 인터페이스를 살펴보고 모든 Map 클래스가 공유하는 공통점이 무엇인지 이해해 보기로 하겠습니다. Map 인터페이스는 모든 Map이 공통적으로 갖는 네 가지 종류의 메소드를 정의하고 있습니다. 그 중에서 별로 중요하지 않은 두 가지 메소드를 살펴 보기로 하겠습니다.

 

표 1: 아래 두 가지 메소드는 오브젝트에 의해 오버라이드(override)되며, Map 오브젝트가 동등(equallity) 조건에 의해 비교될 수 있게 합니다.

equals(Object o) 지정한 오브젝트과 이 맵의 동등(equality) 조건을 비교합니다
hashCode() 이 맵의 해시 코드를 리턴합니다.

 

 

맵 빌딩

 

맵은 엘리먼트를 삽입/제거하기 위한 다양한 뮤테이터(mutator) 메소드를 제공합니다

 

표 2: 맵 업데이트 메소드: 맵의 컨텐트를 변경하기 위한 메소드.

clear() 모든 매핑을 맵으로부터 제거
remove(Object key) 키와 연계된 값을 맵에서 제거
put(Object key, Object value) 지정된 값을 지정된 키와 연계(associate)
clear() 모든 매핑을 맵으로부터 제거
putAll(Map t) 특정 맵에서 이 맵으로 모든 매핑을 복사

 

여기에 별다른 것은 없습니다. 한 가지 참고할 만한 사항은 putAll()이 여러 번의 put() 호출을 사용하는 것보다 효율적인 경우가 드물다는 사실입니다. putAll()을 전달하기 위해 다른 맵을 생성하는데 드는 비용을 고려하지 않더라도 마찬가지입니다. putAll()은 전달된 Map의 각 엘리먼트에 대해 루프를 실행하며, 각각의 키 값을 put()이 실행되는 Map에 추가하는 알고리즘을 실행해야 하기 때문입니다. 하지만 putAll()이 전체 엘리먼트를 추가하기 전에 Map의 크기를 적절하게 설정하는 작업을 수행하는 작업을 수행하므로, 사용자가 직접 Map의 사이즈를 설정하는 것보다 putAll()이 좀더 효율적으로 실행될 수 있음을 참고하시기 바랍니다.



맵의 조회

Map의 각 엘리먼트 별로 알고리즘을 실행하는 방법은 상황에 따라 달라집니다. 특정 쿼리를 만족하는 엘리먼트가 무엇인지 확인하려면, 또는 어떤 이유로든 전체 엘리먼트에 대해 알고리즘을 반복적으로 실행하려면 먼저 Map의 “뷰”를 가져와야 합니다. 뷰에는 크게 3 가지가 있습니다 (표3) 참고

  • 전체 키-값 쌍(key-value pair) — entrySet()
  • 전체 키 — keySet()
  • 전체 값 — values()

앞의 두 가지는 Set 오브젝트를, 마지막은 Collection을 반환합니다. 세 가지 경우 모두 Collection 또는 Set 오브젝트를 직접 반복실행(iterate)할 수는 없으므로, 반복실행을 위한 Iterator 오브젝트를 먼저 가져와야 합니다. 따라서 Map의 여러 엘리먼트에 대해 반복실행을 하기 위해서는 다소 복잡한 구문을 사용해야 합니다.

 

Iterator keyValuePairs =  aMap.entrySet().iterator();
Iterator keys = aMap.keySet().iterator();
Iterator values =  aMap.values().iterator();

 

이 오브젝트들(Set, Collection, Iterator)는 실제로 하부 맵의 뷰로써 존재할 뿐, 전체 엘리먼트의 사본을 포함하고 있지 않다는 점을 참고할 필요가 있습니다. 따라서 조회 작업은 매우 효율적으로 수행됩니다. 반면 Collection 또는 Set의 toArray() 메소드는 Map의 모든 엘리먼트를 포함하는 어레이 오브젝트를 생성하므로, 실제로 어레이 내부의 엘리먼트를 일일이 확인해야 하는 경우가 아니라면 비효율적일 수 있습니다.

아래 예제는 HashMap을 이용하여 간단한 테스트를 실행하고 두 가지 방법을 이용하여 Map 엘리먼트들을 일일이 확인하는데 드는 비용을 비교하고 있습니다 (Test1.java 참고) 

 

int mapsize = aMap.size();
Iterator  keyValuePairs1 = aMap.entrySet().iterator();
for (int i = 0; i < mapsize; i++)
 {
    Map.Entry entry = (Map.Entry) keyValuePairs1.next();
    Object  key = entry.getKey();
    Object  value = entry.getValue();
    ...
 }
Object[]  keyValuePairs2 = aMap.entrySet().toArray();
for (int i = 0; i < mapsize; i++)
 {
    Map.Entry entry = (Map.Entry) keyValuePairs2[i];
    Object  key = entry.getKey();
    Object  value = entry.getValue();
    ...
 }

이 테스트를 수행하는 방법에는 여러 엘리먼트에 대한 실행 시간을 측정하는 방법과 toArray 호출을 이용하여 어레이를 생성하는데 드는 추가적인 비용을 산출하는 방법이 있습니다. 첫 번째 방법에서 어레이를 생성하는데 소요되는 시간을 무시한다면, Iterator를 이용하는 방법보다 toArray 호출을 통해 기존에 생성된 어레이를 사용하는 방법이 30%-60% 정도 빠릅니다. 하지만, toArray를 사용하여 어레이를 생성하는데 수반되는 오버헤드를 고려한다면, 오히려 Interator가 10%-20% 정도 빠른 성능을 보입니다. 그러므로, 컬렉션으로부터 엘리먼트 어레이를 생성해야 할 필요가 있는 경우라면, 각 엘리먼트 별로 작업을 수행하는 대신 어레이를 사용하는 편이 빠릅니다. 반면에 어레이가 굳이 필요하지 않은 경우라면 어레이를 아예 생성하지 않고 Iterator를 사용하는 것이 바람직합니다

 

표 3: 뷰를 반환하는 Map 메소드: 아래 메소드들은 Map 엘리먼트를 조회(traverse)하거나 Map의 엘리먼트를 삭제하기 위한 오브젝트를 반환합니다

entrySet() 맵에 포함된 매핑에 대한 Set 뷰를 반환합니다. 셋에 포함된 각 엘리먼트는 Map.Entry 오브젝트로 구성되며, getKey(), getValue() 메소드의 접근을 위한 key/value 엘리먼트를 포함할 수 있습니다(setValue() 메소드도 함께 제공됩니다).
keySet() 맵에 포함된 키에 대한 Set 뷰를 반환합니다. Set에서 엘리먼트를 제거하면 해당되는 매핑(key, value) 역시 Map에서 제거됩니다.
values() 맵에 포함된 값에 대한 Collection 뷰를 반환합니다. Collection에서 엘리먼트를 제거하면 해당되는 매핑(key, value) 역시 Map에서 제거됩니다.




엘리먼트에 대한 접근

 

맵 액세스를 위한 메소드는 표 4에서 확인하실 수 있습니다. 맵은 (value가 아닌) key를 기준으로 한 액세스에 최적화되는 것이 일반적입니다. 이러한 환경이 Map 정의에 분명히 명시되지는 않지만, 일반적으로 그러하다고 기대할 수 있습니다. 따라서 containsKey() 메소드는 get() 메소드와 유사한 실행 속도를 갖는 것으로 기대할 수 있습니다. 반면 containsValue() 메소드는 맵의 value를 일일이 스캔해야 하므로 훨씬 느린 속도를 보이는 경우가 대부분입니다.

 

표 4: 맵 액세스 및 테스트를 위한 메소드: Map 컨텐트를 변경하지 않은 상태에서 Map 컨텐트에 대한 정보를 조회하기 위한 메소드입니다.

get(Object key) 지정된 키에 관련된 값을 반환합니다.
containsKey(Object key) 맵이 지정된 키에 대한 매핑을 포함하고 있는 경우 True를 반환합니다.
containsValue(Object value) 맵이 지정된 값에 대한 하나 또는 그 이상의 키를 포함하고 있는 경우 True를 반환합니다.
isEmpty() 맵이 key-value 매핑을 전혀 포함하고 있지 않은 경우 True를 반환합니다.
size() 맵에 포함된 key-value 매핑의 수를 반환합니다.

 

HashMap에서 containsKey(), containsValue() 메소드를 이용하여 모든 엘리먼트를 테스트하는데 걸리는 시간을 비교해 보면, containsValue()의 실행 시간이 수십 배나 오래 걸림을 확인할 수 있습니다. (참고 Test2.java) 따라서 containsValue()가 애플리케이션의 성능 문제를 유발할 가능성이 매우 높습니다. 이 경우, containsValue() 이외의 다른 대안을 사용하여 보다 효율적인 방법으로 문제를 해결할 수 있을 것입니다. 이러한 대안이 불가능하다면, 첫 번째 Map의 모든 값을 키로 갖는 두 번째 Map을 생성하고, 첫 번째 Map에 대해 containsValue()를 실행하는 대신 두 번째 Map에 containsKey()를 실행하는 방법을 고려해 볼 수 있을 것입니다

 

 

코어 맵

 

Java는 다양한 Map 클래스를 포함하는 형태로 배포됩니다. Map 클래스는 크게 세 가지 종류로 구분됩니다

  1. 매핑 관리를 위해 애플리케이션에서 사용하는 범용 Map (대부분 java.util 패키지에 구현)
    • HashMap
    • Hashtable
    • Properties
    • LinkedHashMap
    • IdentityHashMap
    • TreeMap
    • WeakHashMap
    • ConcurrentHashMap
  2. 직접 생성하는 대신 다른 클래스를 이용하여 액세스하는 특수 목적의 Map
    • java.util.jar.Attributes
    • javax.print.attribute.standard.PrinterStateReasons
    • java.security.Provider
    • java.awt.RenderingHints
    • javax.swing.UIDefaults
  3. 별도의 Map 클래스 구현을 지원하기 위한 추상화 클래스
    • AbstractMap

 

해시 매핑 테크닉

 

대부분의 범용 Map은 해시 매핑(hash mapping)을 사용합니다. 해시 매핑은 엘리먼트를 어레이에 매핑하기 위한 매우 단순한 메커니즘을 제공합니다. Map을 제대로 이해하기 위해서는 먼저 해시 매핑을 이해하는 것이 중요합니다.

 

해시 맵 구조는 엘리먼트가 저장되는 내부 어레이로 구성됩니다. 내부 저장소가 어레이 형태로 구성되므로, 임의의 키를 이용하여 어레이에 인덱스를 적용하기 위한 메커니즘이 필요합니다. 이 메커니즘은 어레이의 크기보다 작은 어레이 인덱스 값을 생성하는데 사용됩니다. 이러한 메커니즘을 해시 함수(hash function)이라 부릅니다. Java 해시 기반 Map에서, 해시 함수는 임의의 오브젝트를 내부 어레이에 적합한 정수로 변환합니다. 해시 함수를 다른 데서 찾을 필요는 없습니다. 모든 오브젝트는 정수값을 반환하는 hashCode() 메소드를 가지고 있습니다. 이 값을 어레이로 매핑하려면, 값을 양수로 변환한 뒤 어레이 사이즈로 나눈 나머지값을 취하면 됩니다. Java의 모든 오브젝트에 대해 사용 가능한 단순한 해시 함수의 예가 아래와 같습니다.

int hashvalue = Maths.abs(key.hashCode()) %  table.length;

(modulo라 불리는 % 바이너리 연산자는 좌항을 우항으로 나눈 후 나머지값으로 남는 정수를 반환합니다.)

실제로 버전 1.4가 출시되기 전까지, 위의 해시 함수가 해시 기반 Map 클래스를 위해 사용되어 왔습니다. 실제 코드는 아래와 같습니다

int hashvalue = (key.hashCode() &  0x7FFFFFFF) % table.length;

이는 양수 값을 얻기 위해 좀 더 효율적인 메커니즘을 사용하고 있을 뿐, 앞에서 예시한 함수와 동일합니다. 버전 1.4가 출시되면서 HashMap 클래스는 Doug Lea의 util.concurrent 패키지를 기반으로 하는 좀 더 복잡한 해시 함수를 사용하게 되었습니다(Doug Lea의 클래스에 대해서는 뒷부분에서 좀 더 자세하게 설명합니다).


그림1 해싱의 동작 원리


지금까지 해시 매핑의 기본적인 원리를 설명했습니다. 하지만 이것으로 설명이 충분한 것은 아닙니다. 해시 함수는 임의의 오브젝트를 어레이의 특정 위치에 매핑시킵니다. 하지만 서로 다른 두 개의 키가 동일한 위치에 매핑되는 경우는 어떻게 해야 할까요? 이러한 현상을 근본적으로 차단할 수 있는 방법은 없습니다. 해시 매핑에서는 이러한 문제를 충돌(collision)이라 부릅니다. 맵에서는 이러한 충돌을 피하기 위해 인덱스 위치에 링크드 리스트(linked list)를 삽입하고, 각각의 엘리먼트를 링크드 리스트에 추가하는 방법을 사용합니다. 따라서 해시 기반 Map의 기본적인 put() 메소드는 아래와 같이 구현됩니다.


public Object put(Object key, Object value) {  
//Our  internal array is an array of Entry objects   
//Entry[] table;
 //Get  the hashcode, and map to an index
int hash  = key.hashCode();
int  index = (hash & 0x7FFFFFFF) % table.length;

//Loop through the linked list at table[index] to see if
//we  already have this key entry — and if so overwrite it
for  (Entry e = table[index] ; e != null ; e = e.next) {
//Must  check that the key is equal, since the hash
//could be the same for different key objects
if  ((e.hash == hash) && e.key.equals(key)) {
//This is the same key, overwrite the value
//and keep the old value to return from the method
Object old = e.value;
e.value = value;
return old;
}
}

//Still here, so it's a new key, just add a new Entry
//An  Entry object has Object "key" and "value", an int  "hash",
//and an  Entry "next" to point to the next Entry in the list

//Create a new Entry pointing to the start of the previous
//list,  and insert that new Entry into the table
Entry e  = new Entry(hash, key, value, table[index]);
table[index] = e;

return null;
}

다양한 해시 기반 Map의 소스를 살펴보면 그 내용이 서로 상당히 유사하다는 것을 알 수 있습니다. 널 키, 널 값을 처리하는 방법, 내부 어레이의 리사이즈와 같은 별도의 고려사항이 존재하기는 합니다. 위에서 정의된 put() 메소드는 get() 메소드를 위한 알고리즘을 함께 포함하고 있습니다. 삽입 과정에서 키가 이미 존재하는지의 여부를 확인하기 위해 매핑된 인덱스의 엔트리를 검색하는 작업이 필요하기 때문입니다. (get() 메소드는 put()과 동일한 알고리즘을 가지고 있지만 삽입, 덮어쓰기를 위한 코드가 없다는 차이만을 갖습니다.) 링크드 리스트 이외에도 충돌 현상을 방지하기 위한 방법으로, 해시 맵에서 별도의 “open addressing” 접근법이 사용되기도 합니다(본 문서에서는 자세히 다루지 않습니다).



해시맵의 최적화

 

해시 맵의 내부 어레이가 단 하나의 엘리먼트만으로 구성되어 있다면, 모든 엔트리는 동일한 어레이 위치의 링크드 리스트에 삽입되어야 할 것입니다. 이 방법은 매우 비효율적입니다. 링크드 리스트에 대한 선형 검색을 이용한 액세스 또는 업데이트는 각각의 어레이 인덱스가 하나의 오브젝트만을 가진 경우보다 훨씬 느립니다. 링크드 리스트의 액세스/업데이트 속도는 리스트의 사이즈에 정비례하는 반면, 해시 함수를 이용하여 어레이의 단일 엘리먼트를 액세스/업데이트하는 속도는 어레이 사이즈와 무관합니다. 점근적 성능(asymptotic performance, Big-O notation)의 용어에 대응시킨다면 전자는 O(n)이고 후자는 O(1)이 됩니다. 따라서 여러 엔트리가 동일한 어레이 위치에 집중되는 것을 방지하고 어레이의 사이즈를 크게 잡는 것이 유리합니다.

 

Map의 리사이즈

 

해시에서 각각의 내부 어레이 위치를 “버킷(bucket)”이라 부르고, 사용 가능한 버킷의 수(내부 어레이의 사이즈)를 용량(capacity)이라 부릅니다. Map 오브젝트가 임의의 수의 엔트리를 효과적으로 처리하게 하려면, 맵의 리사이즈가 가능해야 합니다. 하지만 리사이즈 작업은 매우 많은 비용이 필요합니다. 어레이의 사이즈가 바뀌면 인덱스 값 또한 바뀔 수 밖에 없기 때문에 리사이즈 과정에서 모든 엘리먼트를 새로운 어레이에 다시 삽입해야 합니다. 이전에 충돌하던 키들이 서로 충돌하지 않는 반면, 이전에는 충돌하지 않던 키들이 서로 충돌할 수 있습니다. Map을 충분한 크기로 늘리는 경우, 충돌의 가능성을 최소화할 수 있으며 따라서 극적인 성능 향상이 가능합니다.

 

1.4.2 JVM에서 많은 수의 엔트리(백만 개 이상)를 HashMap에 추가하는 간단한 테스트를 수행해 보았습니다. 표 5는 그 결과를 보여 주고 있으며, 모든 시간은 ‘pre-sized 서버 모드’에 정규화되었습니다(참고Test3.java). pre-sized JVM의 경우 클라이언트/서버 모드 JVM 모두 동일한 시간을 보입니다(JIT 컴파일 단계의 시간은 계산하지 않았습니다). 하지만 Map의 디폴트 사이즈를 사용하는 경우에는 여러 차례 리사이즈 작업이 발생하며 그 비용은 상당합니다. 서버 모드의 경우 50%나 증가하였으며, 클라이언트 모드와 비교했을 때는 3배나 많은 시간이 걸렸습니다!

 

표 5: pre-sized HashMap과 default sized HashMap에 엔트리를 추가하는데 소요되는 시간

  Client mode Server mode
Pre-sized large 100% 100%
Default size 294% 157%

 

 

Load Factor의 사용

 

각 버킷의 링크드 리스트 사이즈를 추적하지 않고도 리사이즈가 필요한 시점을 결정할 수 있도록 하기 위해, 해시 기반 Map은 별도의 매개변수와 계산식을 이용하여 버킷의 밀집도를 측정합니다. Map은 “로드 팩터(load factor)”라 불리는 매개변수를 이용하며, 로드 팩터는 Map에 리사이즈가 수행되기 전에 얼마나 많은 “로드” 작업이 허용되는지를 결정하는데 사용됩니다. 로드 팩터, 엔트리의 수(맵 사이즈), 용량의 관계는 아래와 같이 정의됩니다.

  • (load factor) x (capacity) > (map size)인 경우 맵은 리사이즈 된다.

예를 들어, 디폴트 로드 팩터가 0.75이고 디폴트 용량이 11이면 11 x 0.75 = 8.25가 됩니다. 이 값에 버림을 적용하면 8 개의 엘리먼트를 얻습니다. 따라서 이 Map에 8 개째의 엔트리를 추가하는 시점에 Map은 보다 큰 용량으로 리사이즈 됩니다. 역으로, 리사이즈를 피하기 위해 초기 용량을 계산할 때에는 추가되는 엔트리의 수를 로드 팩터로 나누고 그 결과에 올림을 적용하면 됩니다.

  • 로드 팩터가 0.75일 때 100 개의 엔트리를 추가하려면, 용량은 100/0.75 = 133.33, 이 결과에 올림을 적용하여 134 (또는 홀수 값이 필요한 경우 135)

홀수 값을 갖는 버킷 사이즈는 충돌의 가능성을 줄여주므로 보다 효율적입니다. 소수(素數)를 적용하는 것이 이상적이지만, 실제로 테스트해 보면 소수가 항상 최상의 결과를 보여 주는 것은 아닙니다(참조Test4.java). 버전 1.4 이후의 일부 Map(예: HashMap과 LinkedHashMap (Hashtable과 IdentityHashMap은 제외))은 2n의 용량을 필요로 하는 해시 함수를 사용하지만, 이러한 Map은 결과값에 가장 근사한 2n 값을 자동으로 계산하므로, 별도의 계산 작업이 불필요합니다.

 

로드 팩터는 시간과 공간의 조율을 위한 변수입니다. 로드 팩터가 작으면 공간을 더 많이 차지하지만 충돌의 가능성이 적어지므로, 액세스/업데이트가 빨라집니다. 0.75 이상의 로드 팩터는 일반적으로 권장되지 않으며, 로드 팩터 1.0은 최소한 하나 이상의 충돌 가능성을 담보합니다. 로드 팩터가 0.50 이하로 내려가면 그 효과는 점차적으로 약해지지만, 맵 사이즈를 효과적으로 관리하는 이상 작은 로드 팩터가 (메모리 비용을 제외하고) 성능에 부정적인 영향을 미칠 가능성은 없습니다. 하지만 Map의 사이즈를 충분히 크게 설정해 놓지 않은 상태라면, 로드 팩터가 작으면 작을 수록 리사이즈가 더욱 빈번하게 발생하고 성능 저하 현상으로 연결될 수 있습니다.

 

 

적절한 맵의 선택

 

그렇다면 어떤 맵을 사용해야 할까요? 동기화가 필요할까요, 그렇지 않을까요? 애플리케이션의 최적화된 성능을 보장하기 위해 가장 중요한 두 가지 고려사항이 바로 이 두 가지입니다. 범용 Map을 사용하는 경우에는 맵 사이즈와 로드 팩터의 두 가지 튜닝 옵션만으로 대부분의 문제를 해결할 수 있습니다.

최적의 Map 성능을 얻기 위한 방법이 아래와 같습니다.

  1. 모든 Map 변수를 Map으로 선언합니다(다시 말해, HashMap, Hashtable과 같은 다른 Map 클래스를 사용하지 않습니다.)
    Map criticalMap = new HashMap(); //GOOD
    HashMap criticalMap = new HashMap(); //BAD

    이와 같이 선선하면 코드의 한 라인만 수정함으로써 특정 Map 인스턴스를 쉽게 대체할 수 있습니다.

  2. Doug Lea의 util.concurrent 패키지를 다운로드합니다. (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html) ConcurrentHashMap을 디폴트 Map으로 사용합니다. 1.5 릴리즈로 이전하는 경우, 디폴트Map을 java.util.concurrent.ConcurrentHashMap으로 변경합니다. 멀티-쓰레드 환경이라 하더라도 Synchronized wrapper를 이용하여 ConcurrentHashMap을 래핑하지 않습니다. 디폴트 사이즈와 로드 팩터를 그대로 사용합니다.
  3. 애플리케이션 프로파일링을 수행합니다. Map이 성능 병목으로 작용하는 경우, 그 원인을 분석하고 Map 클래스, Map 사이즈, 로드 팩터, 키 오브젝트 equals() 메소드 등에 관련한 설정 변경을 시도합니다. 범용적이지 않은 특수 목적의 Map 활용 시에는 예외 없이 특수 목적의 커스텀 Map 구현 방식이 필요하지만, 그렇지 않은 경우라면 범용적인 Map을 이용하여 원하는 성능 목표를 달성할 수 있을 것입니다.

 

맵의 선택

 

어쩌면 여러분들은 좀 더 복잡한 설명을 기대하고 있을지도 모르겠습니다. 조금 여유를 갖고 접근해 봅시다. 먼저, 어떤 Map을 사용해야 할까요? 그 답은 매우 간단합니다. 특정 Map 유형을 필요로 하는 실질적인 설계 요구사항이 도출되기 전까지는 Map을 선택하지 않습니다. 구체적인 Map 구현 방식은 일반적으로 설계 단계에서 결정되지 않습니다. Map이 필요하다는 사실은 알더라도, 어떤 Map이 필요한지는 모를 수 있습니다. Map 인터페이스가 필요한 이유가 바로 여기에 있습니다. 필요한 시점까지 Map 구현 방식의 결정을 미루는 것이 좋습니다. 또 “Map” 선언 변수를 올바르게 활용하였다면, 라인 하나만 변경함으로써 특정 Map의 구현 방식을 변경할 수 있을 것입니다. 이것은 매우 적은 비용을 수반하는 튜닝 방법입니다. 그렇다면 디폴트 Map 구현 방식은 무엇을 선택해야 할까요? 여기에 대해서는 곧 설명하겠습니다.

 

 

맵의 동기화

 

그렇다면 동기화 여부는 어떻게 결정할 수 있을까요? (동기화를 위해서는 synchronized Map을 사용하거나 Collections.synchronizedMap()을 이용하여 unsynchronized Map dmf synchronized Map으로 변환해야 합니다. 두 번째 테크닉에서는 “synchronized wrapper”가 사용됩니다.) 이것은 매우 복잡한 문제입니다. Map이 멀티-쓰레드 동시 액세스/업데이트를 위해 사용될 것인지의 여부를 고려해야 하며, 이와 별도로 유지보수에 관련한 고려가 필요합니다. 예를 들어, 동시 업데이트를 고려하지 않고 Map을 시작하였다가, 나중에 동시 업데이트가 필요해지는 경우를 고려해 봅시다. 이러한 상황이라면, unsynchronized Map으로 시작하였다가 나중에 애플리케이션에 동시 업데이트 쓰레드를 추가하는 시점에 synchronized로 변경하는 방법을 사용할 가능성이 매우 높습니다. 이러한 작업은 애플리케이션의 손상을 초래하며, 이러한 형태의 버그는 그 원인을 확인하고 추적하기가 가장 어렵습니다.

하지만 디폴트로 synchronized Map을 선택하고 멀티-쓰레드 애플리케이션의 실행을 순차화(serialize)하는 경우에는 심각한 성능 저하를 경험하게 됩니다. 해답을 찾기는 무척 어려운 것처럼만 보입니다.


Doug Lea는 뉴욕 주립대학의 컴퓨터 과학 교수입니다. 그는 util.concurrent라 통칭되는 몇 가지 퍼블릭 도메인 패키지를 생성하였으며, 이 패키지에는 고성능 동시 접속 프로그램을 단순화하기 위한 여러 가지 유틸리티 클래스가 포함되어 있습니다. 이 클래스에 포함된 두 가지 Map으로 ConcurrentReaderHashMap과 ConcurrentHashMap이 있습니다. 이 Map 구현방식은 쓰레드로부터 안전(thread-safe)하며, 동시 액세스/업데이트를 위해 동기화를 요구하지 않을 뿐 아니라, Map을 필요로 하는 대부분의 상황에서 유용하게 활용됩니다. 또 이 Map들은 Hashtable과 같은 synchronized Map이나 synchronized wrapper를 사용하는 방식보다 훨씬 더 뛰어난 확장성을 제공하며, HashMap과 비교했을 때의 성능적인 손실은 매우 적은 수준입니다. utl.concurrent 패키지는 1.5 Java 릴리즈를 위한 동시성 유틸리티의 개발을 추진해 온 JSR166의 기반을 이루고 있으며, 1.5 릴리즈는 이 Map을 새로운 java.util.concurrent 패키지에 포함하게 될 것입니다.


결론적으로 synchronized/unsynchronized Map을 선택하기 위해 복잡한 결정 과정을 거칠 필요는 없으며, ConcurrentHashMap을 사용하기만 하면 됩니다. 물론 ConcurrentHashMap이 적합하지 않은 경우도 있을 수 있습니다. 하지만 이러한 경우의 가능성은 극히 적으며 각 케이스 별로 별도로 해결하는 것이 바람직합니다.


저자 - Jack Shirazi

출처 한국오라클

Posted by 1010
01.JAVA/Java2008. 8. 12. 12:09
반응형

개발자가 놓치기 쉬운 자바의 기본원리

  • 전성호(커뮤니티본부 커뮤니티개발1팀), 2006년 10월

초록(abstract)

개발자가 놓치기 쉬운 자바의 기본 원리에 대하여 기본적이긴 하지만 개발하면서 느끼고 경험한 내용을 정리하였다.

목차

1 객체지향의 구멍 static
1.1 Java는 객체지향 언어이다?
1.2 전역변수
2 Java는 Pointer언어이다? (Java에는 Pointer밖에 없다?)
2.1 Java는 primitive형을 제외하곤 모두 Pointer이다
2.2 null은 객체인가?
2.3 String에 대하여
2.4 객체지향의 캡슐화 파괴 주의
2.5 배열에 대하여
2.5.1 배열은 object 인가?
2.5.2 배열의 length는 왜 field(member variable)인가?
2.5.3 final과 배열에 대하여...
2.5.4 "Java에서의 다차원 배열은 존재하지 않는다."
2.6 인수(parameter/argument)전달의 개념
2.6.1 "Java에서 parameter(argument) 전달은 무조건 'call by value' 이다"
2.6.2 "C와 같은 언어는 static linking이지만, Java는 dynamic linking이다."
2.7 GC 에 대하여 잠깐!
2.7.1 "Garbage Collection은 만능이 아니다."
2.8 Java Pointer 결론
2.8.1 "결국 Java에는 pointer가 있는 것인가, 없는 것인가?"
3 상속과 interface의 문제점
3.1 상속
3.1.1 상속에 있어서의 생성자(constructor)
3.1.2 "down cast는 본질적으로 매우 위험하다"
3.1.3 "추상클래스에 final이 있으면 compile error이다"
3.2 interface
3.2.1 "interface는 interface일뿐 다중 상속의 대용품이 아니다."
3.3 상속 제대로 사용하기
4 package와 access 제어에 관한 이해
4.1 package
4.1.1 "package는 '계층구조' 인가?"
4.1.2 "compiler 가 인식하는 class검색 순서(소스코드내 클래스가 발견될 경우 그 클래스의 위치를 찾는 순서)"
4.2 access 제어
4.2.1 "interfacde member의 access 제어"
4.2.2 그렇다면 interface를 다른 package에 대하여 숨기고 싶으면 어떻게 하는가?
5 기타 Java 기능
5.1 Thread
5.1.1 "Multi Thread에서는 흐름은 복수이지만 data는 공유될 수 있다."
5.1.2 "Thread는 객체와 직교하는 개념이다."
5.1.3 "Synchronized 의 이해"
5.1.4 "Thread 사용법의 정석은?"
5.2 Exception
5.2.1 "finally 절은 반드시 어떠한 경우에도 실행되는가?"
5.2.2 "예외의 종류 3가지 (Error, RuntimeException, 그밖의 Exception)"
5.2.2.1 Error
5.2.2.2 RuntimeException
5.2.2.3 그밖의 Exception
5.2.3 "OutOfMemoryError는 어떻게 처리해야 하는가?"
5.3 Object Serialize
5.3.1 "Serialize를 위해서는 marker interface인 java.io.Serializable interface를 implements해야한다."
5.3.2 "super class는 Serializable이 아닌데 sub class만 Serializable인 경우의 문제점"
5.3.3 "transient field의 복원(?)관련"
5.3.4 "Stack Overflow에 주의하라!"
5.4 "nested class / inner class / 중첩클래스"
5.4.1 "중첩클래스의 개념"
5.4.2 "내부클래스는 부모의 참조를 몰래 보유하고 있다."
5.4.3 "local inner class에 대하여"
5.4.4 "anonymous class(무명클래스)에 대하여"
6 이래도 Java가 간단한가?
6.1 method overload 에서의 혼란?
6.1.1 "overload란 이름이 가고 인수가 다른 method에 compiler가 다른 이름을 붙이는 기능"
6.1.2 "그렇다면 overload에서 실제로 혼동되는 부분은 무엇인가?"
6.1.3 (참고) 또다른 혼동, overload한 method를 override 하면?
6.2 상속/override/은폐 에서의 복잡함
6.2.1 "Java class의 member 4 종류"
6.2.2 "override시 method 이름에 대한 함정"
6.2.3 "또다른 나의(?) 실수 - 말도 안되는 오타"
6.2.4 "static member를 instance를 경유하여 참조해서는 안 된다."
6.2.5 "super keyword는 부모의 this"
6.3 상속에 관한 또 다른 문제
6.4 그밖의 함정
6.4.1 "생성자에 void 를 붙인다면?"
6.4.2 "if / switch 의 함정"
7 Java 기능 적용 몇가지
7.1 대규모 개발에서 interface 분리하기
7.1.1 "interface 분리의 필요성"
7.2 Java에서의 열거형
7.3 Debug write
8 Java 5.0 Tiger 에 대하여
8.1 Working with java.util.Arrays
8.2 Using java.util.Queue interface
8.3 java.lang.StringBuilder 사용하기
8.4 Using Type-Safe Lists
8.5 Writing Generic Types
8.6 새로운 static final enum
8.7 Using java.util.EnumMap
8.8 Using java.util.EnumSet
8.9 Convert Primitives to Wrapper Types
8.10 Method Overload resolution in AutoBoxing
8.11 가변적인 argument 개수 ...
8.12 The Three Standard Annotation
8.13 Creating Custom Annotation Types
9 The for/in Statement
9.1 for/in 의 자주 사용되는 형태
10 Static Import
10.1 static member/method import
11 References

1 객체지향의 구멍 static #

1.1 Java는 객체지향 언어이다? #

"Java는 완전한 객체지향 언어이다" 라는 주장을 자주 접하게 된다. 만일 이것이 사실이라면 Java를 사용하는 한 "기존의 절차지향 프로그래밍을 전혀 할수 없을것 같지만 그렇지 않다. 빠져나갈 구멍이 있는 것이다. static을 이용하면 비 객체지향 언어처럼 코딩할 수 있다.

static method는 instance가 아닌 클래스에 속하는 method로, class method라고 부른다. 반대로 static이 아닌 method는 instance method라고 부른다.

static method는 this가 없다. instance method에는 숨겨진 파라미터로 this가 건네진다. (아래 "객체지향에 흔희 있는 오해" 참고) 하지만 static method는 절차지향의 함수와 동일하므로 숨겨진 파라미터 this는 없다. 그래서 static method에서는 전달한 this가 없으므로 instance method를 호출하거나 instance field를 참조할 수 없는 것이다.

(참고) 객체지향에 흔히 있는 오해

  • 오해1. "객체지향에서는 객체끼리 서로 메세지를 주고 받으며 동작한다." 라는 말을 듣고 다음과 같이 생각할 수 있다. "객체지향에서는 객체가 각각 독립하여 움직인다는 것인가, 그러면 각 객체에 독립된 thread가 할당되어 있단 말인가?" 그렇지 않다. "메세지를 보낸다"라는 것은 단순히 각 객체의 함수 호출에 불과하다.

  • 오해2. "객체지향에서는 method가 class에 부속되어 있다"는 말을 듣고 다음과 같이 생각할 수 있다. "그러면 instance별로 method의 실행코드가 복제되고 있는 것이 아닌가?" 물론 이것도 오해다. method의 실행코드는 종래의 함수와 동일한 어딘가 다른곳(JVM의 class area)에 존재하며 그 첫번째 파라미터로 객체의 포인터 this가 건네질 뿐이다.

  • 오해3. "그렇다면 각 instance가 method의 실행코드를 통째로 갖고 있지 않는 것은 확실하지만, method의 실행 코드의 포인터는 각 instance별로 보관하고 있는것이 아닌가?" 이것은 약가 애매한 오해이긴 하다. JVM 스펙에서는 class영역에 실행코드를 갖고 있으며, method 호출시 별도의 stack frame이 생성되어 실행되고 실행 완료시 복귀 주소를 전달한다.

1.2 전역변수 #

static에서 public field는 전역변수(global variable, 글로벌 변수)이다. 여기서 "글로벌 변수는 왜 안 되는가"에 대해 잠깐 생각해 본다. 우리는 흔히 "글로벌 변수는 될수있는한 사용하지 않는 것이 좋다"라고 한다. 그 이유는 글로벌 변수는 어디서든 참조할 수 있고 값을 변경할 수 있기 때문이다.

또한 파라미터나 리턴값으로 교환해야 할 정보를 글로별 변수를 경유(사용)하여 건네주면 함수의 역할이 불분명 해지고 흐름도 애매해 진다. 마지막 이유로는 "글로벌 변수는 하나밖에 없다"는 것이다. 이는 어디서 이값을 변경했는지 알 수 없게 하는 지름길이고 실무에서도 간혹 발생하긴 하지만, 이 하나밖에 없는 변수가 버전업으로 두개가 필요하게 되었을때 확장도 대형 프로젝트에서는 힘들어진다.

따라서 static에서 public은 final을 붙여 상수로 사용해야지 그 외의 용도는 자제하는 것이 좋을 것이다.

  • (참고) final 초기화에서의 주의점. 예를 들어 다음과 같은 코드를 보았을때 우려되는 점은 무엇인가?

public final static Color WHITE = new Color(255, 255, 255);

위의 코드는 java.awt.Color에서 발췌한 것인데, final 변수는 한번 초기화 되면 변경이 불가능한데 object로 초기화 할 경우 WHITE라는 필드가 변경될 수 없는 것이지 그것이 가리키는 객체는 아니라는 점이다.

과거 신규 서비스 개발시 final 변수 필드에 설정파일을 읽어 cache하는 singleton class의 특정 member 를 이용하여 초기화 할 경우 이 멤버값이 변경되면 final 변수의 값이 변경되었는데 프로그램에서는 이상한 짓을 하는 원인을 찾기가 상당히 어려웠던 경험을 하고 난 후 부터 이런 코드는 냄새나는 코드로 여겨지게 되었다.

static은 글로벌변수와 동일하므로 남발해서는 안된다. static을 사용할 경우 다음 두가지는 최소한 기억한다.

  1. static field는 final의 경우와 달리 정말 "하나여도 되는지" 여부를 잘 생각해야 한다.
  2. static method는 주저하지 말고 쓰되 다음 두가지의 경우 매우 활용적이다.
    1. 다른 많은 클래스에서 사용하는 Utility Method 군을 만드는 경우. (주로 Utility Class의 method)
    2. 클래스 안에서만 사용하는 "하청 메소드(private method)". 이유를 예를 들어 설명하면, 아래와 같은 조금은 과장된 클래스가 있다고 하자.

                public class T ..                    private int a;                    private int b;                    private int c;                                        private int calc(){                        c = a + b;                        return c * c;                    }                       ....other method or getter/setter...

위의 클래스 T의 경우 내부에서 calc라는 instance 함수를 사용하게 되면 c 의 값이 매번 변하게 된다. 이는 무심코 하는 실수로 클래스내에서 private method는 모든 멤버 instance 변수에 접근 가능하게 되면서 발생한다. c의 값이 변하지 않기를 바랄수 있다. 이때 안전한 방법은 다음과 같이 calc 하청 메소드를 static method로 수정하면 안전하다.

            private static int calc(int a, int b){               int c = a + b;               return c * c;            }

여기서 a와 b는 멤버 변수를 접근할수 없어 전달해야한다.(static에는 this가 없어 instance field를 참조할 수 없다는 것은 이미 위에서 설명했다.) 또한 c도 같은 이유로 사용할 수 없어 로컬 변수로 선언하고 사용하고 있다. 이럴 경우 메소드가 약간 커질수 있지만 instance member 변수를 안전하게 사용할 수 있다는 장점이 있다. 이것은 static을 다시한번 생각하게 하는 좋은 예가 되었을 것이다.

2 Java는 Pointer언어이다? (Java에는 Pointer밖에 없다?) #

2.1 Java는 primitive형을 제외하곤 모두 Pointer이다 #

"Java에는 포인터가 없다" 라고 Java의 장점 이라고 생각하는 것은 입문자도 외우고 있다. 하지만 이 부분은 의외로 Java를 혼란스럽게 하는 주범이라고 생각한다. Java에 포인터가 없기는 커녕 primitive(int, short, char, long...등 JVM의 Heap에 object로 생성되지 않는것들)를 제외하면 "포인터 밖에 없는 언어이다"라는 명제가 성립되게 된다. 사실 여기서 포인터라고 함은 C 의 그것과는 조금 다른 reference(참조)이긴 하지만...

"즉, 자바의 클래스형의 변수는 모두 포인터이다."

2.2 null은 객체인가? #

Java에서 공참조(힙에 실제로 참조되는 object가 없는 참조)의 경우는 당연히 객체가 붙어 있지 않다. 그러나, Java API 레퍼런스의 NullPointerException 항에는 다음과 같이 기술되어 있다.

"object가 필요한 경우 application이 null을 사용하려고 하면 throw된다. 가령 다음과 같은 경우이다."
  • null object의 instance method 호출
  • null object의 field(member variables)에 대한 액세스 또는 그 값의 변경
  • null의 길이를 배열처럼 취득할 경우
  • null의 slot을 배열처럼 액세스 또는 수정
  • null을 Throwable처럼 throw 할 경우

위에서 null object라는 말이 등장하는데 이는 공참조에 객체가 붙어 있지 않은 것이 아니라 null을 가리키는 객체라고 볼수 있다. 즉, 공참조라는 것은 JVM에서 봤을때 아무것도 참조하지 않는것이 아니라 null이라고 하는 object를 참조하고 있는것이다. 그러나 JSL 4.3.1에서는 다음과 같이 나와있다.

"참조값(reference)은 이러한 객체의 포인터나 어떤 객체도 참조하지 않는 특수한 null참조가 된다"

즉, 공참조는 어떤 객체도 참조하지 않는다고 단정하고 있다. 하지만 '==' 연산에 있어 두개의 객체가 모두 null이거나 동일한 객체 또는 배열 참조의 경우 true라고 되어있는것으로 봐서 서로 다른 두 객체가 동일한 null을 참조하고 있으므로 true가 된것이 아닌가 하는 생각을 할 수 있다.

즉, null이 Object의 instance 형태는 아니지만 개념적으로 봤을때 null도 object라고 봐야 하지 않을까?

2.3 String에 대하여 #

String Object에 대한 생각.

            String str = "111222";            String a = "111";            String b = "222";            String c = "111";            String d = b;            String t = str.substring(0,3);  //111

위의 소스를 보고 다음이 참인지 생각해 보자. (==연산자는 포인터의 비교이지 값의 비교가 아님)

  1. str == (a + b) ==> 이것은 두개의 참조와 하나의 참조를 비교했으므로 당연히 false이다.
  2. a == b ==> 이것은 당연히 false
  3. d == b ==> 이것은 동일한 reference이므로 true
  4. a == t ==> a 와 t 는 둘다 값이 "111"이다. 하지만 이것은 서로 다른 참조를 가져 false이다. 그렇다면 다음 5번도 false일까?
  5. a == c ==> 이것은 true이다. 아.. 4번과 혼란스럽다. 이것이 참인 이유는? ==> 이것의 해답은 JSR 3.10.5에 다음과 같이 나와 있기 때문이다.

"동일한 내용의 문자열 리터럴에 관해서는 인스턴스를 하나밖에 생성하지 않는다."

즉, 위의 a와 c 는 '=' 를 이용하여 문자열 리터럴을 생성하게 되는데 a 에서 이미 만들어 놓았으므로 c에서는 그것을 참조한다.

2.4 객체지향의 캡슐화 파괴 주의 #

"object pointer를 반환하는 getter method는 객체지향의 캡슐화가 파괴될 가능성이 있다." 이는 object형의 field(member variable)의 getter에서 이 object를 그냥 반환하면 이 object를 받은쪽이나 참조하고 있는 다른쪽에서 이 object의 내용을 변경하게 되므로 사실 캡슐화(은닉)는 이루어 지지 않았다고 봐야한다.

"이럴 경우 object를 clone(복제) 하여 반환하지 않아도 되는지를 반드시 생각해 본다."

object의 복사에는 shallow copy와 deep copy가 있다.

        //(참고)Member에는 두개의 field(Identity Class 형의 ID와 Family Class 형의 family)가 있다.                 /** shallow copy */        Member shallowCopy(){            Member newer = new Member();            newer.id = this.id;            newer.family = this.family;                        return newer;        }                     /** deep copy */        Member deepCopy(){            Member newer = new Member();            newer.id = new Idetity(this.id.getId(), this.id.getName());            newer.family = new Family(this.family.getFamilyName(), this.family.getFamilyInfo());                        return newer;        }        

위 소스에서 보듯이 shallowCopy 는 object를 복사하여 반환한것 처럼 보이지만, 사실은 Member object만 새로 생성되었을뿐 Member의 field는 newer와 this 둘다 서로같은 힙의 id와 family를 참조한다. 하지만 두번째 method인 deepCopy의 경우 Member의 field를 새로 생성하여 복사하므로 서로 다른 id와 family이다.

"Java에서는 clone이라는 method가 준비되어 사용되는데 이는 기본이 shallow copy임을 명심해야 한다. deep copy를 사용하기 위해서는 clone method를 overload하거나 따로 만들어 직접 기술해야 한다." (참고) object를 immutable(변하지 않는, 불변의 객체)로 만드는 요령
  1. 모든 field(member variable)를 생성자(constructor)를 이용하여 초기화 한다.
  2. 모든 field는 private으로 선언하고, getter method는 만들되 setter는 기술하지 않는다.

즉, 값을 변경하기 위해서는 object를 다시 만들어야만 하는 불편은 있지만 안전하게 사용하려 할때 유용하다.

2.5 배열에 대하여 #

2.5.1 배열은 object 인가? #

JVM에서 배열은 object로 취급되어 object와 같이 aload, astore와 같이 bytecode로 기술되어 진다. int[] iarr = new int10; 에서 보는것과 같이 new로 Heap 영역에 object를 생성하므로 object임을 알 수 있다.

2.5.2 배열의 length는 왜 field(member variable)인가? #

String의 길이를 구할때는 length()와 같이 method를 이용하는데 배열은 object임에도 불구하고 legth와 같이 필드로 되어있다. '이래도 Java가 완전한 객체지향 언어인가' 라는 의심이 들게 한다. 그렇다면 length가 public이므로 array.length = 100; 과 같이 하면 배열 크기가 변경되나?

이것은 컴파일 오류가 난다. length는 final이라 값을 변경 할 수 없다는 것이다. 그렇다면 final field로 한 이유는 무엇이냐는 Java News Group에 찾아보면 대부분이 "효율을 위해서"라고 되어 있다. JIT compiler를 사용하지 않는한은 method보다는 field가 빠른건 당연한 것이다.

그런데 정말 알수 없는것은 byte code에서는 arraylength라는 전용명령으로 컴파일 된다. 즉, length는 Java의 문법이 어찌되었든 JVM레벨에서는 field가 아닌것이 분명하다. 그렇다면 효율을 위해서 field로 했다는 것은 도데체 무슨 소리인가?

전문가들의 대답에는 이것은 Java의 수수께끼 중 하나라고 대답하는 사람이 많다고 한다.^^;

2.5.3 final과 배열에 대하여... #

우리가 흔희 앞에서도 나온바 있지만 final은 값을 변경할 수 없는 것이라고만 생각하지 object로 되어 있을 경우 그 object는 변경 가능하다는 것을 잊곤한다. 배열도 object이므로 마찬가지다.

final int[] iarr = new int[5]; 일경우 iarr = null; 은 에러가 나지만 iarr[3] = 5; 는 에러가 나지 않는다. 즉, final이 지정되어 있는것은 iarr이지 iarr이 가리키는 곳 배열의 요소가 아닌 것이다.

2.5.4 "Java에서의 다차원 배열은 존재하지 않는다." #

가령 2차원 배열 처럼 보이는 int[][] iarr 또는 int[] iarr[] 은 일차원 배열 두개이지 2차원 행열 구조가 아닌것이다. 즉, 두개의 배열은 각각이 배열로 되어 있는 것이지 테이블(행열)형태가 아니다.

2.6 인수(parameter/argument)전달의 개념 #

2.6.1 "Java에서 parameter(argument) 전달은 무조건 'call by value' 이다" #

primitive type의 경우 호출한 쪽의 변수값은 호출 받은 method내에서 값이 변경되어도 변경되지 않는다. reference type의 경우도 reference되는 object에 대해서는 함께 변경되지만 reference pointer는 call by value이다. object를 가리키는 pointer는 call by value로 변경되지만 Heap의 실제 object내용은 변경되지 않는다.

2.6.2 "C와 같은 언어는 static linking이지만, Java는 dynamic linking이다." #

따라서 Java는 Class 파일이 처음에 한꺼번에 memory에 읽혀지는 것이 아니라 런타임시에 그것이 필요해 졌을때 읽혀지고 링킹된다. static field의 영역도 Class가 읽혀지는 시점에 비로서 확보된다. 이렇게 되면 최초 가동시간이 단축되고 끝까지 사용하지 않는 Class의 경우 신경쓸 필요가 없어지게 된다.

따라서 static field는 프로그램이 시작되어 해당 Class가 필요해 졌을때 JVM이 알아서 load/link 해 준다. 즉, static field는 프로그램이 실행되기 시작할 때부터 끝날때까지 계속해서 존재하는 것이라고 보면 된다. (참고) 링킹(linking)의 의미

link된다는 것은 Class가 memory에 loading될 때 특정 메모리 번지에 loading되는데 이 메모리 번지는 loading될때 마다 다른 번지수에 loading된다. 이때의 메모리 주소값(Java에서는 실제 메모리 값이 아닐 수 있다)을 현재 실행중인 프로그램에서 알 수 있도록 하여 해당 Class에 대한 참조가 가능하도록 연결하는 과정이다.

정적(static) link라는 것은 이러한 메모리에 대한 주소 정보를 컴파일 시에 compiler가 미리 결정하는 것이고, 동적(dynamic) link라는 것은 프로그램 수행 중 결정되는 것을 의미한다. 정적인 link의 경우 직접적으로 메모리의 번지값이 할당 되는 것이 아니라 offset값(기준위치로 부터의 index값)으로 연결시킨다.

2.7 GC 에 대하여 잠깐! #

2.7.1 "Garbage Collection은 만능이 아니다." #

Java에는 free가 없다. GC가 알아서 해준다. 하지만 GC 수행중에는 프로그램이 멈추는 것과 동일한 증상이 나타나기 때문에 GC가 자주 발생하지 않도록 프로그램 해야 한다. 서비스 되고 있는 시스템에서도 가끔 시스템이 응답이 늦어지는 시점이 있는데, 이는 GC가 수행되고 있는 중이 대부분이다.

그렇다면 GC가 자주 발생하지 않도록 해야 하는데 가장좋은 방법은 무엇일까? 그것은 바로 불필요한 객체를 생성하지 않는 것이 아닐까?

개인적으로 Java에 free가 없는것이 너무나 든든하게 느껴진다. 이유는 두개의 변수가 Heap내의 하나의 object를 reference하고 있을 경우 실수로 하나의 변수만 free해 버리면 나머지 하나는 dangling pointer라하여 reference pointer가 모르는 사이데 사라져 버려 곤경에 처하는 것을 예방해 주기 때문이다.

참고로 Object class에는 finalizer라는 method가 있어 GC 수행시점에 호출되는 method가 있지만 이것은 GC가 언제 수행될지 알 수 없으므로 과신하지 말아야 할 것이다.

2.8 Java Pointer 결론 #

2.8.1 "결국 Java에는 pointer가 있는 것인가, 없는 것인가?" #

Java는 Heap내의 Object를 참조(reference)하고 있고, 참조는 결국 개념이 포인터와 같은 것이므로, "Java에는 pointer가 없다"는 것은 어불성설이다.
// 이부분에 대해 Object를 이해하시면 족히 이런 문제는 사라질것으로 봅니다.
// 클래스에 대한 인스턴스(object)들은 reference로 밖에 가질(참조될)수 없기 때문입니다.
// 컴파일러 입장이 아닌 언어 자체의 사상을 가지고 쉽게 이해시키는 것이 좋을것 같습니다.

JSR 4.3.1을 보면 다음과 같은 말이 나온다.

"참조값(reference)은 객체의 pointer이거나, 또는 어떠한 객체도 참조하지 않는 특수한 null 참조가 된다"

또한 java.sun.com의 Java programmer's FAQ에 "Java는 pointer가 없다고 하는데, linked list는 어떻게 만들어야 하나?"라는 질문에 다음과 같이 답변이 나와있다.

(답변) Java에 관한 많은 오해중에서 이것이 가장 심각한 것이다. 포인터가 없기는 커녕 Java에 있어 객체지향 프로그래밍은 오로지 pointer에 의해 행해진다. 다시 말새 객체는 항상 포인터를 경유해서만 access되며 결코 직접적으로 access되지 않는다. pointer는 reference(참조)라고 불리며 당신을 위해 자동으로 참조된다.

"Java에는 pointer가 없고 주장하는 모든 서적과 글들은 Java의 reference사양에 모순된다고 봐야 할 것이다."

3 상속과 interface의 문제점 #

3.1 상속 #

3.1.1 상속에 있어서의 생성자(constructor) #

"child의 default 생성자가 있으면 그 생성자에는 parent의 생성자(super()) 호출이 compile시 자동 삽입된다." 따라서 super() 이전에 다른 코드가 있으면 object가 생성되기 이전이므로 오류를 발생하게 된다.

3.1.2 "down cast는 본질적으로 매우 위험하다" #

down cast - child의 type으로 parent를 casting - 는 parent 형태의 type이 정말 child type인지 compile시에는 알 수 없다. 실행시에 type check가 이루어 지므로 runtime시에 ClassCastException이 발생할 가능성이 커진다.

"프로그래밍시 오류는 가능한한 compile시에 처리하는것이 좋다."

3.1.3 "추상클래스에 final이 있으면 compile error이다" #

abstract method가 있는 클래스는 추상 클래스이고 추상클래스는 상속되지 않으면 아무런 의미가 없기 때문이다.

3.2 interface #

3.2.1 "interface는 interface일뿐 다중 상속의 대용품이 아니다." #

interface를 method signature - 추상클래스와 같이 구현부는 없이 선언부만 있는 method - 의 용도로 생각하는것이 Java에서는 옳다. 즉, interface는 final field와 abstract method가 있는 클래스와 동일하긴 하지만 상속의 의미와는 그 용도가 다르다. 공통된 type을 정의하는것으로 보는것이 맞는 의미일 것이다.

또한 interface는 클래스를 재이용하기 위해 상속을 사용하여 캡슐화의 파괴를 수반하는 것을 방지하는 기능이있다. 상속을 사용하면 모두 구현후 마치 소스 코드가 여기저기 천 조각을 주워 모아 만든 '누더기'같이 보이는 것에 한숨을 쉰 경험이 있을 것이다. 이 부분을 interface로 구현하면 보다 깔끔한 코드가 나오게 된다. 물론 public과 protected를 적절히 잘 사용해도 되긴 하지만 말이다.

하지만 상속은 메소드 오버라이드한 경우 클래스를 마음대로 개조해 버린 셈이 되므로 어디선가 묘한 모순이 발생하게 될 가능성도 높아질뿐 아니라 추상클래스의 경우 실제 구현부가 어디에 위치하는지도 에매하게 느껴질 수 있어 불안한 코드가 되고 만다.

3.3 상속 제대로 사용하기 #

"그렇다면 제대로 된 상속은 어떻게 판단할 수 있을까?"

상속은 'is a'관계가 성립해야 올바르다. 즉 '서브클래스(자식) is a 슈퍼클래스(부모)'가 성립해야 한다. 예를 들면 Red is a Color는 올바른 명제이지만 Engine is a Car는 'has a'관계이므로 상속이라고 볼 수 없다. "따라서 'has a'관계는 상속이 아니므로 composition과 delegation을 이용하면 된다."

composition은 '객체를 field가 갖게 하는 방법'을 의하므로 'has a'관계가 정확히 성립한다. "상속 대신 composition과 delegation(조작이나 처리를 다른 객체에 위임)을 사용하면 다음과 같은 이점이 있다."

  1. 상속에서는 슈퍼클래스가 허용하고 있는 조작을 서브클래스에서 모두 허용해야 하지만, composition과 delegation에서는 조작을 제한할 수 있다.
  2. 클래스는 결코 변경할 수 없지만, composition하고 있는 객체는 자유롭게 변경할 수 있다. 예를 들면 학생 클래스가 영원이 학생이 아니라 나중에 취직을 하여 직장인 클래스가 될수 있다.
상속을 composition과 delegation으로 변경하는 요령은? 여기서 Shape를 상속한 Polyline과 Circle을 변경한다면 다음과 같다.
  1. Shape(부모)의 공통된 내용을 구현한 구현 클래스(ShapeImpl)를 만든다.
  2. Polyline과 Circle 클래스에서 ShapeImpl을 composition하고 부모와 공통되지 않는 method를 각각 위임 받는다.
  3. ShapeImpl 클래스의 method를 추출한 ShapeIF interface를 작성하고 Polyline과 Circle에서는 implements 한다.

4 package와 access 제어에 관한 이해 #

4.1 package #

4.1.1 "package는 '계층구조' 인가?" #

처음 Java를 접하면서 package에 대해 이해할때 마치 파일시스템과 같은 계층구조라고 이해하게 되어 ' import /test/*.class '는 왜 안되는지 의아해 했던 기억이 있다. 그리고 부모 directory에 있는 클래스에서 왜 자식 directory에 있는 Class를 import없이 사용할 수 없는지도 이상했다.

즉, package에서 동일 부모라도 서로 다른 package는 완전히 별개의 package였던 것이다. 이 부분에 관해서는 JLS 7.1 에서 다음과 같이 기술되어 있다고 한다.

"package가 계층적인 이름 구조로 되어 있는 것은 관련된 package를 일정 규약에 따라 체계화하기 위해서이고, package 안에서 선언되어 있는 top-level형과 동일한 이름을 가진 서브 package를 갖는 것이 금지되어 있는 점을 제외하면 특별한 의미는 없다."

즉, Java에서는 package이름을 계층적으로 명명할 수 있을뿐 package구조 자체에는 어떤 계층적인 의미 부여도 할 수 없는 것이다. 다시 말해서 Java에서는 package이릉을 계층적으로 명명할 수 있을 뿐 구조자체는 평평한 것이다. 실제로 바이트 코드의 내용을 보면 깨어진 내용중에 java/lang/String과 같이 완전한 한정이름을 class이름으로 사용됨을 알 수 있다.

4.1.2 "compiler 가 인식하는 class검색 순서(소스코드내 클래스가 발견될 경우 그 클래스의 위치를 찾는 순서)" #

  1. 그 class자신
  2. 단일형식으로 임포트된 class
  3. 동일한 패키지에 존재하는 다른 class
  4. 온디멘드 형식(..* 형태) 임포트 선언된 class

4.2 access 제어 #

public은 다른 package에서 참조 가능하고, 무지정할 경우 동일한 package내에서만 참조 가능하다.

4.2.1 "interfacde member의 access 제어" #

interface의 member field/method는 모두 public이다. interface member에 protected나 private을 지정할 수는 없다. 또한 public을 지정할 필요도 없다. 지정해도 상관없지만 JLS 9.4에서는 다음과 같이 명시되어 있다.

"interface의 method에 대하여 public 수식자를 지정하는 것이 허용되고 있지만, style로서는 전혀 권장할 수 없다."

즉, interface member는 모두 public이라 되어 있는 것이다. 또한 James Gosling도 집필에 참가한 '프로그래밍 언어 Java 3판'에서는 다음과 같이 기술되어 있다고 한다.

"public이 아닌 member를 interface에게 갖게 하는 것은 아무런 의미가 없다. interface의 member에 대한 access제어에 interface 자신의 access 제한을 적용하는 것이므로 이것은 아무런 의미가 없다."

4.2.2 그렇다면 interface를 다른 package에 대하여 숨기고 싶으면 어떻게 하는가? #

그것은 interface 자체 선언에 public이 아닌 것을 적용하면 되는 것이다. member별로 제어할 수 없어 불편한 면도 있지만, 나름대로 그럴 듯한 규칙이다. 하지만 이것은 정말 이상한 논리가 아닐수 없다. public이 아닌 interface에 public method가 무슨 의미가 있는지 알 수 없기 때문이다. 이 interface를 구현한 클래스에서도 method는 모두 public이 되어야 하는데, 이것도 아무래도 이상하다.

5 기타 Java 기능 #

5.1 Thread #

5.1.1 "Multi Thread에서는 흐름은 복수이지만 data는 공유될 수 있다." #

Multi processing에서는 흐름은 복수이지만 data는 독립되어 있다. 하지만 Multi Thread에서는 Heap과 static영역에 관한 한 2개 이상의 Thread 사이에 공유가 이루어 진다. 따라서 2개 이상의 Thread에서는 동일한 static field를 참조할 수 있고, 동일한 객체에 접근할 수도 있다. 그러나 stack만은 Thread별로 독립되어 있다. stack은 method에 들어가는 시점에 확보되고 빠져 나오는 시점에 확보되고 빠져 나오는 시점에 Free 되므로 2개 이상의 Thread에서 공유할 수는 없는 것이다.

5.1.2 "Thread는 객체와 직교하는 개념이다." #

Multi Thread는 어디까지나 Thread라는 처리 흐름이 여러 개 존재할 수 있다는 의미이다. 요약하면 다음 3가지 이다.
  1. Multi Thread에서는 Thread라는 처리 흐름이 2개 이상 존재할 수 있다.
  2. 어떤 Thread에서 움직이기 시작한 method가 다른 method를 호출 했을때 호출된 측의 method는 호출한 측의 method와 동일한 Thread에서 동작한다.
  3. Thread의 경계와 객체의 경계는 전혀 관계가 없다. 즉, Thread와 객체는 직교하고 있다.

5.1.3 "Synchronized 의 이해" #

Multi Thread 기반의 programming시에 synchronized를 놓쳐 자주는 일어나지 않으나 뭔가 잘못되어 가는것을 경험한 적이 있다. 즉, 이것이 원인이 되어 버그가 발생한 경우 그 버그는 재현성이 지극히 낮아지기 때문에 꽤 고생을 하게 된다. 이런 사태가 발생하게 되면 버그의 원인을 찾기가 어렵게 되고 해당 application은 언제 발생할지도 모르는 오류가 있는 상태 그대로 운영되기 때문에 심각성이 내포되어 있다고 할 수 있다.

이러한 사태를 방지하기 위해서는 critical section을 2개 이상의 Thread가 동시에 실행되지 않도록 '배타 제어'를 해야한다. 그 키워드가 바로 synchronized이다.

synchronized에는 synchronized(obj){} 형태와 method에 synchronized 를 붙이는 두가지 방법이 있는데, 이 둘은 범위만 같다면 같은 의미이다. 예를 들어 설명하면, 아래의 소스에서 method1()과 method2()는 동일하다.

        synchronized void method1(){            ...        }                void method2(){            synchronized(this){                ...            }        }

이렇게 동일한 의미를 두가지로 만든것은 method단위로 synchronized를 걸 일이 그만큼 많다는 것을 의미한다. 많이들 오해하고 있는 부분이 위의 소스에서 알수 있듯이 method에 synchronized를 사용한다는 것은 '그 객체에 해한 조작은 동시에 하나의 Thread라는 것이지 method 호출이 하나의 Thread가 아닌것이다'

그렇다면, Thread A가 obj의 Lock을 설정하고 있는 상태에서 다시 한번 Thread A 자신이 obj의 Lock을 설정하면 어떻게 될까? 이 경우 Thread A는 이미 이 obj에 대하여 Lock을 보유하고 있으므로 기다리지는 않아도 된다. 위의 소스에서 method1에서 method2를 호출한다면?

method1에서 이미 obj의 Lock을 보유 했으므로 method2의 synchronized(this) 부분에서는 Lock을 기다리지 않아도 된다.

즉, Lock의 기준이 특정Thread에 있어서 Lock의 기준이 method가 아닌 object인 것이다. 이 규칙 덕분에 synchronized method도 재귀호출이 가능해지고, synchronized method가 동일한 instance의 synchronized method를 호출할 수 있는 것이다.

주의할 점은 static method에 synchronized가 있다면 static은 this참조가 없다고 위에서 설명하였으므로, 이 클래스의 Class 객체를 Lock하게 된다. 기준이 xx.Class가 되는 것이다.

5.1.4 "Thread 사용법의 정석은?" #

Thread 사용법에는 다음 두가지의 정석이 있다.
  1. Runnable을 implements하고 Thread의 참조를 보유(composition) 하는 방법. 이경우는 단지 Runnable만 implement함으로서 해결되는 경우가 대부분이긴 하지만, 그 class 내에서 해당 class의 Thread를 조작하게 된다면 composition한 Thread 객체에 delegation하면 된기 때문이다.
  2. Thread class를 상속하는 방법. JDK의 소스를 보면 Thread class에는 Runnable을 implements 하고 있다. 그리고 run method는 native method이다. 따라서 Thread를 상속한 모든 클래스는 사실 Runnable을 implements하고 있는 것이다. run method는 abstract가 아니므로 구현되어 있고 우리는 이를 오버라이드하여 사용하고 있다. 이 방식을 사용하면 Thread의 method를 안팍으로 자유롭게 호출할 수 이지만, 이미 다른 class를 상속하고 있다면 이 방식을 사용할 수는 없다.
JDK API Reference의 Runnable에 과한 설명중에 다음과 같은 내용이 있다.

"Thread class의 method중 run method만을 오버라이드하여 사용하는 경우는 Runnable interface만 implements하여 사용하면 된다. 왜냐하면, class의 기본적인 동작을 수정 또는 확장하지 않는한 그 class를 sub class화 하는 것은 바람직하지 않기 때문이다."

그렇다면 위에서 언제나 1)번 방식을 사용하면 되는 것 아닌가 라는 의문이 생기게 된다. 왜 귀찮게 2)의 방법을 고민하는 것인가, 극단적이긴 하지만 만일에 사태에 이 클래스가 다른 클래스를 상속받게 되는 경우도 있을수 있는데.

하지만 이것은 아닐것이다. 만약 이렇다면 Thread class가 Runnable을 implements할 필요가 없었을 것이기 때문이다. 또한 Thread는 생성자의 인수로 Runnable의 reference를 취득한 후 계속해서 그것을 보유한다는 것도 이상하다. Thread에 있어 Runnable이 필요한 것은 start() 때 뿐이므로 start()의 인수로 Runnable을 건네줘도 좋을 것이다.

그럼에도 불구하고 굳이 Thread에서 계속적으로 Runnable을 보유하고 있는 것은 Runnable객체와 Thread를 강하게 결합시키려는 의도 때문이다. 이것은 의도적으로 위의 2)의 방법을 권장하는 듯한 느낌을 받게 하는듯 하다.

그렇다면 API Reference의 말은 단지 상속을 피하라는 의미만 있는 것인가? 마지막으로 한가지 추정이 되는 부분은 Thread에는 suspend()나 stop()등과 같은 method가 현재 모두 deprecate되었다. 또한 sleep()이나 yield()는 모두 static method이므로 굳이 Thread 객체를 보유할 필요가 없다.

그렇다면 위의 1)의 방법에서 Thread객체를 composition할 필요가 없어진다.

"그렇다면 Thread를 아무도 보유하지 않고 Runnable만 implements한 방식이 최선인가?"

무엇이 정답인지 도무지 알길이 없다. ^^;

5.2 Exception #

5.2.1 "finally 절은 반드시 어떠한 경우에도 실행되는가?" #

try ~ catch 문의 finally 절은 'loop라면 break, method라면 return 절'을 만나도 뒤에 있는 finally절은 수행된다. 하지만 다음의 경우는 그렇지 않다.

        try{            ...            System.exit(1);        }catch(...){        }finally{            ... //이 부분은 실행되지 않는다.        }

5.2.2 "예외의 종류 3가지 (Error, RuntimeException, 그밖의 Exception)" #

5.2.2.1 Error #
이에 관해선 JLS 11.2.1에 다음과 같이 기술되어 있다. "체크되지 않는 예외 클래스(Error와 그 Sub class)는 프로그램안의 다양한 위치에서 발생할 가능성이 있으며, 회복이 불가능하기 때문에 컴파일시 체크되지 않는 것이다. 이러한 예외를 프로그램에서 선언한다고 해도 난잡하고 무의미한 것이 될 뿐이다."

Java의 클래스 librury에서 Error의 sub class를 살펴봐도 AWTError, LinkageError, ThreadDeath, VirtualMachineError 등 'catch해도 소용 없을 것' 들 뿐이다. (OutOfMemoryError는 VirtualMachineError 아래에 위치한다.)
5.2.2.2 RuntimeException #
위의 Error 이외의 Exception들은 application에서 catch할 가능성이 있는 예외들이다.(버그가 없으면 발생하지 않는 예외들) 그리고 RuntimeException은 '어디서든 발생할 가능성이 있는 예외'이다. RuntimeException의 sub class로는 NullPointerException, ArrayIndexOutOfBoundException, ClassCastException 등을 들 수 있다. '이러한 예외는 버그가 없는 한 발생하지 않으므로 일일이 throws 를 작성하지 않아도 된다.'

프로그램에 버그가 없는 한 발생할 수 없는 예외가 발생한 경우 C 언어와 같이 영역 파괴가 일어나기 쉬운 언어라면 프로그램 전체를 종료시키는 것이 정답이겠지만, Java와 같이 영역파괴가 일어나지 않도록 실행시 체크(JVM Classloader의 formal verification process)를 하고 동적으로 프로그램을 load하는 언어에서는 국소적인 NullPointerException 때문에 프로그램 전체를 중지시켜서는 안 될 것이다.

따라서, RuntimeException은 catch하지 않는 것이 바람직하다고 볼 수 있다. 버그가 있는 프로그램은 신속히 종료시키는 것이 대부분의 경우 최선의 방책이라 생각하기 때문이다.
5.2.2.3 그밖의 Exception #
위의 RuntimeException이외의 Exception의 sub class는 사용자의 잘못된 조작 등으로 인해 프로그램에 버그가 없어도 발생할 가능성이 있고 그에 대하여 프로그램이 확실히 대응해야 하는 경우에 사용된다. 예를 들면 FileNotFoundException등이다.

그런데 개발하다 보면 이상하고 의아한 것이 하나 있다. 숫자 부분에 문자를 넣었을때 발생하는 NumberFormatException이다. 이것은 이상하게도 RuntimeException의 sub class이다. 이것은 RuntimeException이 아니었으면 하는데 NumberFormat체크는 Runtime시에만 가능한 모양이다.

5.2.3 "OutOfMemoryError는 어떻게 처리해야 하는가?" #

예전에 Swing에서 Tree구조를 이용하는 프로젝트를 한적이 있다. 이때 Tree에 branch와 node가 무수히 생기자 JVM은 OutOfMemoryError를 내뱉었다. 이에 급한 마음에 OutOfMemoryError를 catch하여 사용자에게 재시작을 요청하는 Dialog를 띄우도록 수정하였다면 이 Dialog가 과연 떳을까? 현재 메모리가 부족한 판에 Dialog를 띄울 메모리가 남아있질 않았던 것이다. 다행히 Dialog가 떴어도 작업은 계속되지 못했을 것이다. NullPointerException가 나기 때문이다.

원인은 나중에 찾았는데, Tree구조에서 부모부터 자식들을 붙이는 순으로 Tree를 구성하는데 자식들을 줄줄이 붙여나가다가 메모리 부족현상이 발생하였고 NullPointerException은 자식이 없으니 클릭하는 순간 null을 반환하여 발생하였던 것이다.

OutOfMemoryError의 가장 좋은 해결책은 불필요한 객체를 만들지 않는 것이었다. 그리고 Tree생성시에도 자식부터 만들고 부모를 만드는 순서로 프로그램을 수정하여 프로젝트를 정상적으로 마칠수 있었다.

마지막에 드는 심정은 프로그램이 OutOfMemoryError를 일으키는 원인이 과연 이렇게 구성되어 발생했는지 어떻게 알수 있을까 하는 의문이다.

5.3 Object Serialize #

Java에서는 ObjectOutputStream의 writeObject() method에 데이타 구조 저장소의 참조만 건네주기만 하면 그 안에 있는 모든 객체를 1차원 stream으로 출력해 준다. (파일이나 ByteArrayOutputStream을 이용한 메모리로) 단, static field는 Serialize되지 않는데 이는 Serialize의 대상이 instance 객체뿐이기 때문이다.

5.3.1 "Serialize를 위해서는 marker interface인 java.io.Serializable interface를 implements해야한다." #

여기서 marker interface는 java.lang.Cloneable과 같이 method와 field의 정의는 없지만 객체 Type을 위한 interface이다. 예전에 Serialize를 이용하여 데이타를 유지하는 프로젝트를 한 적이 있는데 그때 생각했던것이 '모든 class들이 기본적으로 Serializable을 implements하고 있으면 편할텐데..'라는 생각이었다. 하지만 이것은 상당히 위험한 발상이었다.

Serializable이 기본으로 implements되어 잇으면 엉뚱한 객체까지 Serialize되고 그것을 알아채지도 못하는 사태가 일어날 가능성이 높다. Serializable이 optional인 이유는 이러한 이유 때문이리라..

5.3.2 "super class는 Serializable이 아닌데 sub class만 Serializable인 경우의 문제점" #

Serialize을 이용하여 프로젝트를 할때 한번쯤 실수할 수 있는 부분이 상속된 class의 Serialize이다. 컴파일 에러도 없고 Deserialize도 잘 되었다. 하지만 키가 되는 값이 null과 0이었다. 영문을 몰라 다른곳을 헤매여도 보다가 결국 찾은 원인은 부모의 field는 Serialize되지 않는다는 것을 알게 되었다. transient와 마찬가지로 형식별 default 값으로 채워졌었다. 이는 컴파일과 실행시 아무런 오류없이 실행되어 나를 힘들게 하였기에 Java가 원망스러웠던 기분좋은 추억이다. ^^;

5.3.3 "transient field의 복원(?)관련" #

Serialize를 이용한 프로젝트를 할때는 writeObject와 readObject를 이용하여 기본적으로 제공하는 Serialize를 customizing할수있다.

Serializable에 대한 API reference에도 다음과 같이 나와있다.

"Serialize와 Deserialize에 대한 특별한 handling을 위해서는 다음 두개의 특별한 메소드를 구현하면 된다."

private void writeObject(java.io.ObjectOutputStream out) throws IOException;private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;

이 두 method가 private으로 되어 있는 것을 보고 처음에는 의아해 했었던 기억이 있다. 이를 protected나 public으로 하면 제대로 동작하지 않는다. 이는 override가 이니기 때문이다. 사실은 속에서 reflectiond을 이용하여 강제적으로 호출되고 있는것이다. reflection에서는 private method까지 찾을 수 있기 때문이다.

또한 private으로 한 가장 큰 이유는 Serialize를 객체자신이 직접 해야 안전하다는 의미도 있지 않을까 하는 생각도 든다. 다시 본론으로 들어가서 transient를 복원하는 것에 얘기를 하자면, 사실 transient는 Serialize대상에서 제외되는 것인데 복원을 할 수 있다는 말이 안된다. 하지만 프로젝트를 진행하다 보면 logic상 가능한 경우가 많이 있다.

즉, 모든 field를 Serialize하지 않고 필요한 것만 하고 특정 field는 Serialize한 field들을 이용하여 복원하는 방법이다. 또한 Serialize당시의 객체 상태와 Deserialize시의 객체상태가 서로 다를 수 있는 field도 그것에 해당된다. cafeid만으로 나머지 field는 DB에서 읽어오게 한다면 나머지 field는 transient로 처리하고 Deserialize시 readObject()에서 복원하는 것이다.

5.3.4 "Stack Overflow에 주의하라!" #

Serialize를 하다보면 참조로 연결된 객체를 recursive하게 거슬러 올라가며 이것이 너무 깊어지면 Stack Overflow가 발생한다. 가령 linked list같은 경우이다. 이것을 Serialize하면 그 요소수만큼 recursive 호출이 발생한다. 과거(JDK1.3.0시절) 프로젝트 당시 JVM이 5111에서 Stack Overflow가 발생했던 기억이 있다.

물론 실행시 java option에 -Xss 를 이용하여 statck 크키를 조절할 수 있지만 이것은 개발자가 아닌 실행하는 사람들에게 부담이었다. JDK의 LinkedList class의 소스를 보면 writeObject()와 readObject()를 다음과 같이 변경하고 있다.

        private synchronized void writeObject(java.io.ObjectOutputStream s) throws IOException {            s.defaultWrtieObject(); //이 코드는 무조건 들어가게 되는데 이곳 소스의 System.arraycopy()에서 overflow발생한다.                        s.writeInt(size);   //이부분이 실제 추가되어 Stack Overflow를 예방한다.                        for(Entry e = ...)                s.writeObject(e.element);            }            ...        }                //readObject()도 이와 같은 개념으로 변경되어 있다.

5.4 "nested class / inner class / 중첩클래스" #

5.4.1 "중첩클래스의 개념" #

개인적으로 중첩클래스를 어떠한 경우는 사용하지 않으려 한다. 사용하기가 만만치 않고 코드 읽기가 힘들어 지기때문이다. 하지만 '어떤 클래스 내에서 은폐할 목적으로 사용하는 클래스가 있다면 이것을 사용해야 한다' 실제로 Java의 AWT 클래스 Event Handler를 비롯하여 많은 클래스에서 중첩클래스를 사용하고 있다. 또한 내부 class는 그것을 둘러싸는 class의 instance(enclosing object라고 하는)의 field를 참조 할수 있는것도 장점이다. 하지만 이는 내부클래스가 아닐경우 부부 클래스를 new해서 사용하는것과 별반 다를께 없지 않은가.

5.4.2 "내부클래스는 부모의 참조를 몰래 보유하고 있다." #

내부 클래스의 instance는 부모의 instance에 대한 참조를 몰래 보유하고 있기 대문에 위에서 얘기한 부모의 field를 참조할 수 있는 것이다. 그러므로 static method에서는 내부클래스를 생성할 수 없다. 다음 예를 보면 바로 알수 있다.

        class Test{            class InnerClass {                int i;                ...            }                        public static void main(String[] args){                InnerClass icls = new InnerClass();                ...            }        }

이 소스를 compile하면 다음의 오류가 발생한다. "non-static variable this cannot be referenced from a static context..." main method는 static이므로 this를 참조할수 없다는 것이다. 이는 InnerClass가 new 되면서 외부 클래스 Test의 this를 보유해야 하는데 여기서 static을 만나니 오류를 표출시킨것이다. 물론 일반 instance method에서는 오류가 나지 않는다.

5.4.3 "local inner class에 대하여" #

local inner class라 함은 method내에서 선언된 inner class이다.

        public class OuterClass {            public int get(){                int i = 9;                int id = 99;                int id2 = 99;                final int id3 = 100000;                                class LocalInnerClass {                    int id = 100;                                        LocalInnerClass(){                        System.out.println("LocalInnerClass");                       }                                        int getId(){                        return id3 + id;                    }                }                                   LocalInnerClass lic = new LocalInnerClass();                return id + lic.getId();            }                           public static void main(String[] args){                OuterClass outer = new OuterClass();                System.out.println("id = " + outer.get());                  //결과 값은 "100000(id3) + 100(LocalInnerClass.id) + 99(OuterClass.get())" 인 100199가 나온다.            }                    }

위 소스의 LocalInnerClass는 get() 이라는 method에서만 보이는 class이다. 그리고 특이할 만한 부분이 OuterClass의 get() method에서 final로 선언된 id3이 LocalInnerClass에서 참조 가능해 진다. id2를 참조하면 compile error가 나지만 final로 선언된 것은 오류가 나지 않는다.

이는 local variable은 method에서 나오는 순간 사라지는데, local inner class는 local variable보다 수명이 조금더 길기 때문에 final만 허용한 것이다.

5.4.4 "anonymous class(무명클래스)에 대하여" #

무명 클래스는 말그대로 이름이 없는 클래스이다.

        class AnonymousTest {            private interface Printable {                void print();            }                        static void doPrint(Printable p){                p.print();            }                        public static void main(String[] args){                doPrint( new Printable(){                            public void print(){                                System.out.println("this is new Printable print()");                            }                         });            }        }

위 소스의 "doPrint( new Printable(){" 부분이 무명클래스 이다. compile을 수행하면 AnonymousTest$Printable.class, AnonymousTest$1.class, AnonymousTest.class 세개의 클래스가 생긴다. 여기서 AnonymousTest$Printable.class는 Printable interface이고 AnonymousTest$1.class이 무명클래스이다.

이 소스를 보면 처음에 드는 의심이 Printable interface를 new 했다는 것이다. 여기서 굳이super class(이 소스에서는 interface)를 저정해야 하는 이유는 아무것도 상속하지 않는 무명 클래스의 instance를 만들어 봐야 의미가 없기 때문에 이렇게 한듯하다.

"무명클래스는 어떤 class나 interface를 상속/구현 해야만 그 instance를 사용할 수 있는 것이다" 이처럼 무명 클래스를 사용하면 어떤 절차(수행)를 다른 method의 인수로 건네줄 수 있게 된다. 하지만 간단한 로직만 구현처리해야 한다.

"무명클래스는 조금만 복잡해져도 급격히 소스의 가독성이 떨어지게 되므로 남용하지 않는 것이 바람직하다"

6 이래도 Java가 간단한가? #

6.1 method overload 에서의 혼란? #

6.1.1 "overload란 이름이 가고 인수가 다른 method에 compiler가 다른 이름을 붙이는 기능" #

overload를 구현하면 bytecode로 변환시 다른 이름으로 method가 변환되어 별개의 method로 처리된다. 이를 JVM에서 method descripter라 하여 Oolong asembler로 변화시 다른 형태의 method가 된다. 예를 들어 "void get(double d, long l)" 은 "get(DJ)V"로 변경된다. 여기서 D는 double, J는 long, V는 void를 의미한다.

그런데 여기서 "get(DJ)" 부분만 method 이름이므로 return type이 다른 동일 method는 overload 할 수 없다. 따라서 overload는 정적(compile시 결정)이라는 명제가 성립니다. 그래서 동적으로 사용되면 compile시 오류를 표출한다. 아래의 소스를 보자. 여기에는 IFS라는 interface와 이를 implements한 Impl1, Impl2 라는 class가 있다.

        //IFS.java        interface IFS {            public String getName();        }                //Impl1.java        class Impl1 implements IFS {            public String getName(){                return "Impl1";            }        }             //Impl2.java        class Impl2 implements IFS {            public String getName(){                return "Impl2";            }        }                   //main이 있는 OverloadTest.java        public class OverloadTest {                static void pr(int i){                System.out.println("pr_int : " + i);               }                        static void pr(String s){                System.out.println("pr_string : " + s);               }                        static void pr(IFS ifs){                System.out.println("pr_string : " + ifs.getName());            }                        static void pr_run(Impl1 i1){                System.out.println("pr_run : " + i1.getName());            }                        static void pr_run(Impl2 i2){                System.out.println("pr_run : " + i2.getName());            }                        public static void main(String[] args){                OverloadTest test = new OverloadTest();                test.pr(10);                test.pr("Jeid");                                   IFS ifs1 = new Impl1();                test.pr(ifs1);                                IFS ifs2 = new Impl2();                test.pr(ifs2);                                //pr_run(ifs1);                //pr_run(ifs2);            }        }

위의 소스를 수행하면 정상적으로 compile이 될것인가?

당연히 잘 된다. pr()은 overload를 잘 구현했다. 하지만 소스 하단의 두 주석문을 풀면 어떻게 될까? 이는 compile오류를 낸다.

        OverloadTest.java:36: cannot resolve symbol        symbol  : method pr_run (IFS)        location: class OverloadTest                pr_run(ifs1);                ^        OverloadTest.java:37: cannot resolve symbol        symbol  : method pr_run (IFS)        location: class OverloadTest                pr_run(ifs2);                ^        2 errors

실제 위 둘의 pr_run method는 bytecode로 변환시 "pr_run(Lpackage_name.IFS)V"로 동일하게 생성된다. 따라서 compile시에 오류를 표출한다. 이 소스를 보면 알 수 있듯이 "method overload는 정적(compile시)으로 미리 결정되며, 동적(실행시판단)으로 사용할수 없다."

6.1.2 "그렇다면 overload에서 실제로 혼동되는 부분은 무엇인가?" #

다음 소스를 보고 실제로 수행되는 method를 찾아보라.

        class OverloadTest2 {            static int base(double a, double b){ ... }  //method A                        static int count(int a, int b){ ... }  //method B            static int count(double a, double b){ ... }  //method C                        static int sum(int a, double b){ ... }  //method D            static int sum(double a, int b){ ... }  //method E        }

  • base(3,4) 를 호출했을때 수행되는 method는? => 당연히 method A (3과 4는 정수라도 double이 되므로 정상적으로 수행됨)

  • count(3,4) 를 호출했을때 수행되는 method는? => B와 C중 갈등이 생긴다. 이럴경우 JVM은 가장 한정적(more specific)한 method를 찾는다. 여기서 3과 4는 정수형에 가까우므로 method B 가 호출된다.

  • count(3, 4.0) 을 호출했을때 수행되는 method는? => 이것은 4.0 이 double이므로 method C 가 더 한정적이므로 method C 가 호출된다.
  • sum(3,4.0) 을 호출했을때 수행되는 method는? => 이것은 당연히 type이 일치하는 method D.
  • sum(3,4) 를 호출했을때 수행되는 method는?? => 이런 코드가 소스내에 있으면 다음과 같은 compile 오류를 표출한다.

             OverloadTest.java:48: reference to sum is ambiguous, both method sum(int,double)               in OverloadTest and method sum(double,int) in OverloadTest match                    System.out.println("sum(3,4) = " + sum(3,4));                                                       ^             1 error

method D와 method E가 애매하다는 compile 오류이다. 이것은 둘중 어느것이 더 한정적인지 찾을 수 없으므로 bytecode 를 생성 할 수 없다는 것이다.

"이렇듯 compiler에게 불필요한 오해(혼동)를 초래하는 overload는 사용하지 않는 것이 좋다. 개인적으로 overload를 가능한 사용하지 않으려 하고 필요하다면 인수의 개수가 다른 overload를 사용하는 편이다."

6.1.3 (참고) 또다른 혼동, overload한 method를 override 하면? #

overload란 compiler가 bytecode변환시 다른 이름을 붙이는 기능이라는 것을 위에서 설명했다. 따라서 super class에서 overload한 method를 상속하여 override하면 완전 별개의 method를 override한것처럼 JVM은 판단한다. 즉, overload와 override는 직교(전혀상관없는)하는 개념이다.

6.2 상속/override/은폐 에서의 복잡함 #

6.2.1 "Java class의 member 4 종류" #

  1. instance field
  2. instance method
  3. static field
  4. static method
여기서 상속을 하였을 경우 runtime시 객체의 형식에 따라 선택되는 것은? 2번 instance method 뿐이다. 즉, 동명의 member를 sub class에서 선언했을 때 instance method만 override 되고 나머지는 완전 별개의 member가 된다. 따라서 위의 1,3,4는 sub class에서 동일하게 선언했을 경우 별개의 것으로 인식되며 compile시에 무엇을 access 할지 결정된다.

즉, instance method는 override되지만 instance field/static field는 은폐된다. override는 실행시 객체의 형식에 따라 처리 할당되지만, 은폐의 경우는 compile시에 결정되고 만다.

6.2.2 "override시 method 이름에 대한 함정" #

과거에 코딩을 하던중 정말이지 어처구니 없는 경우를 당했다. override 하는 method이름을 잘못써서 황당한(?) 고생을 한적이 있다. super class의 writable()이라는 method를 writeable()이라고 override(?)하였는데 프로그램 수행 중에 writable()이 항상 false가 나오는 것이 아닌가? 그래서 소스를 추적추적 하다 몇시간을 허비했었던 기억이 있다.

java를 접한지 얼마되지 않았고 요즘같이 eclipse같은 에디터도 없이 메모장에서 코딩하던 시절이라 더욱 고생했던것 같다. 한참 후에야 우연히 스펠링이 잘못된걸 알고 얼마나 황당했던지... 지금 생각하면 이것도 좋은 추억이리라.

무조건 override 잘 되었을거라 생각 했던 나의 불찰도 있었지만 compile때나 runtime시 아무런 반응을 보이지 않던 Java도 원망스러웠다. 2003년도에 C#으로 프로젝트를 했는데 C#은 상속의 override에 대하여 "override void writalbe().."과 같이 정의시 override를 명시해야 된다는 것을 보고 상당히 마음에 들어 했던 기억이 있다. 가독성도 뛰어날 뿐더러 나의 몇시간동안의 헤메임도 없을 것이기 때문다. Java도 이렇게 확실한 명세였으면 정말 좋겠다.

6.2.3 "또다른 나의(?) 실수 - 말도 안되는 오타" #

위의 method이름을 잘못써서 고생하기 이전에 아주 비슷한 고생을 한적이 있다.

'난 정말 바보인가'라는 생각을 들게 했던 문제였다. 초보 시절에는 왜이리도 오타가 많이 나던지... 요즘은 대충 키보드 두드려도 오타가 잘 안나는데 그 시절에 오타 때문에 느린 CPU에서 컴파일을 몇번을 했는지... 기억을 되살리면 소스는 다음과 같다.

        public class Member {            private int memberNo;                        public int getMemberNo(){                return this.memberNo;            }                        public void setMemberNo(int menberNo){                this.memberNo = memberNo;            }                        ......        }


위 소스의 Member에는 다른 여러가지 member field가 있는데 DB의 member table에 memberid 컬럼이 memberno로 변경되면서 Member class의 memberId를 memberNo로 변경하게 되었다. 위와 같이 수정하여 배포해놓고 테스트를 하는데 시스템이 완전히 뒤죽박죽으로 돌아버리는 것이 아닌가. 이 경우도 method 이름처럼 몇시간을 헤매었다.

이번에 argument의 오타로 인한 어처구니 없는 실수였다. setMemberNo(int menberNo)에서 문제가 발생되었던 것이다. 인수의 memberNo를 menberNo로 잘못친것이다. 그래서 memberNo에는 해당 member의 memberno가 아닌 0이 모두 들어갔어던 것이다. 시스템은 memberno를 기준으로 도는 부분이 너무나 많았기에 오류나는 부분도 많았으며 DB에서는 제대로 된 memberno을 읽어 왔으며, compile과 runtime시 아무런 반응도 없었기에, 초보자를 그렇게도 고생시켰나 보다.

이것도 member field면 무조건 this를 붙이도록 하던지 Java가 인수는 'm_'와 prefix를 붙이도록 Coding Style을 정의- SUN사이트의 Java Coding 규약에는 "Variable names should not start width underscore_ or dollar sign $ characters, even though both are allowed." 와 같이 명시되어 있다 - 했더라면 발생하지 않았을 문제이다.

또한 C언어나 C#에서 처럼 compile 경고레벨을 높여놓으면 "menberNo는 어디서도 사용하지 않습니다."와 같은 메세지를 보여 줬더라면 고생을 덜 하지 않았을까?

6.2.4 "static member를 instance를 경유하여 참조해서는 안 된다." #

예를 들어 ClassA 에 public static int AA 라는 static field가 있을 경우 ClassA.AA 로 접근해야 하는데, 다음과 같이 사용하는 실수를 범한다.(물론 오류는 없지만)

        ClassA a = new ClassA();         int i = a.AA;       //instance를 경유하여 접근        int j = ClassA.AA;  //올바르게 접근

그럼 왜 굳이 ClassA.AA와 같이 instance가 아닌 class이름을 붙여야 할까?

static member(static field/static method)는 compile시에 이미 어느것을 호출할 지 결정하기 때문에 위의 a.AA와 같은 것은 static이 아닌것 같은 오해와 혼란만 가져오기 때문이다. 심지어 개인적으로는 동일 class 내 - 위 소스에서 ClassA의 member method - 에서 ClassA.AA라고 사용하는 편이다.

이는 local variable과 혼동될 염려도 없을뿐더러 AA라는 변수가 static이라는 것도 확실히 알 수 있기 때문이다. 물론 private static 의 경우는 ClassA.BB 와 같이 하지 않고 BB 라고 해도 무방하겠지만 말이다.

6.2.5 "super keyword는 부모의 this" #

Java 개발자 대부분은 'super' 에 대하여 그렇게 민감하지 않을 것이다. 그거 super() 나 super.method1() 과 같이 사용되지 그 이상에 대해선 깊이 생각하지 않게 된다. super를 한마디로 정리하면 다음과 같다.

"super keyword는 instance method등에서 this를 사용할 수 있는 곳에서만 쓸 수 있다. this의 자리에 super라고 쓰면 현재 class의 member가 참조되는 대신 부모 class의 member가 참조되는 것이다."

6.3 상속에 관한 또 다른 문제 #


6.4 그밖의 함정 #

6.4.1 "생성자에 void 를 붙인다면?" #

생성자에 void를 붙인다면 그 class가 new 될때 그 생성자(?)가 실행될까?? 아래의 'Constuctor'라는 문자열은 출력될까?

        public class ConstructorTest{            void ConstructorTest(){                System.out.println("Constuctor");            }            .....        }

출력되지 않는다. 물론 compile시 아무런 경고도 없었다. 즉, void가 붙은 ConstructorTest()는 생성자가 아니라 instance method일 뿐이었고 new시에는 default constructor가 실행 되었던 것이다.

6.4.2 "if / switch 의 함정" #

Java 개발자라면 대부분이 초보시절에 if 조건절에 '==' 대신 '='을 써본 기억이 있을것이다. 예를 들어 "if( isListenLecture == Student.STUDENT )" 를 "if( isListenLecture = Student.STUDENT )" 로 잘못 쓴 경우이다. 여기서 Student.STUDENT는 boolean type이다. 여기서 isListenLecture는 항상 Student.STUDENT 값을 갖게 되는 버그가 생긴다. 이는 compile시에 아무런 경고도 없다. 이렇게 한번 당하고 나면 앞으로는 '=='를 정확히 쓰게 되거나 아니면 다음과 같이 쓴다.

"if( isListenLecture )" 또는 "if( !isListenLecture )" 라고 말이다. 이것이 더욱 간결하고 의미도 분명해 지기 때문이다. 또한 다음 소스와 같은 오류도 범하는 경우가 있다. 이는 잘못된 indentation으로 빚어지는 초보의 함정이다.

이글을 읽는 분께 한가지 당부드리고 싶은것은 여기서 초보라고 다 그런건 아니라는 것이다.

        ....        if( a < 5 )            b = 3;            c = 10;   //이부분은 나중에 추가된 라인이다.                                if( isStudent )            if( isFemale )                sayHello("Hi~~");        else            sayHello("Hello Professor~");

위의 소스중 c = 10; 이 if( a < 5 )의 참일때 수행된다고 오해할 수도 있고, sayHello("Hello Professor~"); 부분이 if( isStudent )의 else 부분이라고 오해 할 수도 있다. 이것은 전적으로 indentation(들여쓰기)의 불찰로 개발자가 잘못 읽을 수 있는 부분이다. Java Coding Style에서는 if문 다음에 한줄의 코드가 있더라도 {} 를 사용하길 권고한다. 그러면 첫번째 if문과 같은 오류를 방지할 수 있고 두번째 if문에서도 보다 가독성이 생길 것이다.

이와 유사한 것으로 switch문의 case 절에서 break를 쓰지 않아 항상 동일하게 처리되는 버그도 경험해 보았을 것이다.

7 Java 기능 적용 몇가지 #

7.1 대규모 개발에서 interface 분리하기 #

7.1.1 "interface 분리의 필요성" #

Java와 같은 객체지향언어에서는 공개해야 할 method만을 public으로 하고, 공개할 필요가 없는 것은 private으로 하여 class의 상세한 내용을 은폐할 수 있게 되어 있다. 그런데 private 부분이 은폐되어 있는것 처럼 보이는가?

소스를 보면 훤히 들여다 보이는데?

대규모 개발은 하부 class부터 bottom-up으로 진행하는 것이 이상적인 형태일 것이다. 그런 형태로 개발하면 임의의 시점에서 테스트를 할 수도 있다. 그러나 현실적으로 단기간에 많은 수의 개발자가 붙어서 단시간에 개발을 진행하는 경우가 많다. 또한 서로 호응하는 관계에 있는 class들은 어느쪽이 하부인지 정의하기가 난감할때가 많다. 이런경우 우리는 흔히 package단위로 나누어 개발한다. 하지만 이럴경우 어느정도 코딩이 종료될때까지 테스트하기가 상당히 힘들어 진다. Java에서는 private member와 method 구현까지 하나의 파일에 코딩하는데 개발 중간에 공개하여 다른 개발자가 이용해야 하는 class를 배포할 수 없으므로 동시 개발이 까칠해 진다.

이 상황에서 다른 package(개발자)에 공개해야 하는 class 부분을 interface로 공개하면 많은 부분 유연하게 된다. 이 interface를 다른 개발자는 개발을 하고 테스트가 필요하다면 TestImpl class를 만들어 하면된다. RMI나 CORBA에서도 Stub은 이런식으로 IDL을 정의한다.

7.2 Java에서의 열거형 #

Java에서는 열거형-C의 구조체, 공용체-이 없다. 열거형이 왜 필요하냐고 반문하는 개발자도 있을 것이다.

하지만 열거형이 없어 곤란을 경험한 개발자도 꽤 있으리라 본다. 최근언어(특히 객체지향 언어) - Java, Eiffel, Oberon등 - 에는 열거형은 포함되어 있지 않다. C#에는 있긴 하지만.

이런 이유로 Java AWT의 Label class는 다음과 같이 구현되어 있다.(텍스트의 정렬값관련)

        public static final int LEFT = 0;        public static final int CENTER = 1;        public static final int RIGHT = 2;        ...                label.setAlignment(Label.CENTER);        ...

하지만 위의 소스에는 문제가 있다. setAlignment() method의 인자가 int인 것이다. 만약 위에 정의한 0, 1, 2가 아닌 다른 int 값이 들어가도 compile/runtime시 알수가 없다. 그래서 주석을 달게 되는데, 주석이라 함은 정말이지 최후의 수단이라고 봐야 한다.

실제로 우리가 개발해 놓은 소스에도 이런부분이 있으리라 예상된다. 이 문제를 어떻게 하면 해결할 수 있을까? Java에서 열거형을 한번 만들어 보자.

        //LabelAlignment.java        public class LabelAlignment {            private LabelAlignment() {} //이는 생성자를 private으로 하여 다른데서는 만들지 못하도록 하기위함이다.                        public static final LabelAlignment LEFT = new LabelAlignment():            public static final LabelAlignment CENTER = new LabelAlignment():            public static final LabelAlignment RIGHT = new LabelAlignment():        }                //변형된 Label.java 의 일부..        public synchronized void setAlignment(LabelAlignment alignment){            if( alignment == LabelAlignment.LEFT ){                ...//왼쪽으로 맞추기..            }else if( ...                ...            }        }        ...

위에서 작성한 소스는 잘 작동한다. 서로 다른 3개의 instance이므로 reference가 달라 '==' 연산도 가능하고, 훌륭하다.

하지만 한가지 문제가 있다. LabelAlignment가 Serializable한 class에서 serialize되었다 deserialize 된다면?

LabelAlignment alignment 는 새로운 instance가 되고 serialize전의 reference와 다른 참조 위치를 갖게 되어 '==' 연산은 버그를 발생시킨다. 그럼 이것만 해결하면 되겠는데, 어떻게 refactoring하면 될 것인가? '==' 연산 대신 equals로 변형하면 되겠는데.

        //LabelAlignment.java        public class LabelAlignment {            private int flag;            private LabelAlignment(int flag){                this.flag = flag;            }                         public static final LabelAlignment LEFT = new LabelAlignment(0):            public static final LabelAlignment CENTER = new LabelAlignment(1):            public static final LabelAlignment RIGHT = new LabelAlignment(2):                        public boolean equals(Object obj){                return ((LabelAlignment)obj).flag == this.flag;            }        }                //변형된 Label.java 의 일부..        public synchronized void setAlignment(LabelAlignment alignment){            if( LabelAlignment.LEFT.equals(alignment) ){                ...//왼쪽으로 맞추기..            }else if( ...                ...            }        }        ...

하하, Serialize까지 잘 작동한다. ^^;

여기서 Debug를 고려한다면 0, 1, 2 대신 문자열로 "LEFT", "CENTER", "RIGHT"로 한다면 더욱 명확하지 않을까?

(주의) 위에서처럼 LabelAlignment.LEFT 라고 쓰기 싫어서 상수 interface를 만들어 그걸 implements 하여 그냥 LEFT 라고 쓰는 것을 뿌듯해 하며 쓰는 개발자들이 있다. 물론 Swing의 소스들을 보다보면 SwingConstants라는 interface에 LEFT를 비롯하여 온갖 잡다한 상수를 집어넣어놓고 여기 저기서 implements해서 사용하고 있다. 이런 코딩 스타일은 '내 스타일이야~' 가 아니라 냄새나는 코드이다.

LEFT라는 것이 구현한 class에 이미 있을 수 있을 수 있을뿐아니라 구현한 모든 클래스에서 LEFT를 보유하여 SwingConstants.LEFT뿐 아니라 Impl.LEFT로도 사용되게 되어 온갖 혼란을 초래하게 된다. 입력량을 줄이기 위해 interface를 implements 해서는 안되지 않을까?

7.3 Debug write #

C에서는 다음과 같이 pre-process로 정의하면 DEBUG라는 식별자를 #define하지 않으면 컴파일후 해당 소스의 부분이 삭제된다.

        #ifdef DEBUG            fprintf(stderr, "error...%d\n", error);        #endif /* DEBUG */

그럼 Java에서는?

Java에서는 Pre-process가 없지만 다음과 같이 작성했을때 Debug.isDebug 가 final로 선언되어 있으면 compile후 아래 3줄 모두 삭제 된다.(단 Debug.isDebug 가 false 로 초기화 되었다면 제거된다.)

        if( Debug.isDebug ){            System.out.println("error..." + error);        }

Java는 compile시 byte code 생성시 final은 정적으로 판단하여 미리 정의하기 때문에 위의 3줄은 삭제될 수 있다. if문과 함께 없어지게 되므로 처리 속도에 피해를 주지 않는다. 단, 주의해야 할 점은 Debug.isDebug 값이 변경되면 이 것을 사용하고 있는 측도 모두 함께 다시 compile해야 한다. bytecode를 다시 만들어야 하기 때문이다.

그런데, 이 소스를 Debug.write()와 같이 static 으로 하여 이 method내에서 판단하게 하면 편리할텐데. 그리고 class별로 ON/OFF 처리를 할 수 있으면 좋을텐데, 어찌 하면 가능할 것인가?

그럼 먼저 호출한 쪽의 class이름을 찾아보자. 접근은 Exception의 printStackTrace()로 부터 시작되었다. 하지만 이 소스에는 Exception 객체를 new한 시점에 결정되어 있다. 그래서 부모인 Throwable의 생성자를 확인해 보니 fillInStackTrace() 로 되어있는데 이 method는 native method였다.

API Reference를 보면 Thread class에서는 dumpStackTrace()라는 method가 있었다. 소스를 보니, 그것도 생성시점이었다. 아무래도 예외방면에서 찾는건 무리인듯 했다.

그래서 class의 호출계층을 나타내는 java.lang.SecurityManager의 getClassContext() method로 접근하였다. sample 소스는 다음과 같다.

        // 1. GetCallerSecurityManager.java        public final class GetCallerSecurityManager extends SecurityManager {            public Class[] getStackTrace(){                return this.getClassContext();               }        }                // 2. GetCallerClass.java        public final class GetCallerClass {            private static GetCallerSecurityManager mgr;                        static{                mgr = new GetCallerSecurityManager();                System.setSecurityManager(mgr);            }                        public static void writeCaller(String str){                Class[] stk = mgr.getStackTrace();                int size = stk.length;                for(int i = 0; i < size; i++){                    System.out.println("stk[" + i + "] = " + stk[i]);                   }                                   String className = stk[2].getName();                                System.out.println("className is " + className + " : " + str);            }        }                // 3. GetCallerClassMain1 : 호출하는 클래스 예제 1        public class GetCallerClassMain1 {            public static void main(String[] args){                GetCallerClass.writeCaller(", real is 1.");            }        }                // 4. GetCallerClassMain1 : 호출하는 클래스 예제 2        public class GetCallerClassMain2 {            public static void main(String[] args){                GetCallerClass.writeCaller(", real is 2.");            }        }

위의 3번 주석과 4번 주석 부분을 수행하면 다음과 같은 결과가 나온다.

    className is GetCallerClassMain1 : , real is 1.    className is GetCallerClassMain2 : , real is 2.

정확히 호출한 클래스를 표현하고 있다. 이것을 비교해서 클래스별 ON/OFF를 구현하면 된다.

8 Java 5.0 Tiger 에 대하여 #

Tiger에서는 새로운 개념의 적용이 많은 부분 시도 되었다. 이중 가장 기본이 되는 몇가지를 살펴보자.

8.1 Working with java.util.Arrays #

Tiger에서는 무엇보다도 Collection class들에 대해 많은 부분 정비하였다. 예를 들면 for/in 구문 지원과 Generic Type member와 Arrays Utility class 등이다. 그럼 Collection에 대한 static method들을 담고 있는 Arrays 에 대해 다음 example로 한눈에 살펴보자.

package com.jeid.tiger;import java.util.Arrays;import java.util.Comparator;import java.util.List;public class ArraysTester {	private int[] arr;	private String[] strs;	public ArraysTester(int size) {		arr = new int[size];		strs = new String[size];		for (int i = 0; i < size; i++) {			if (i < 10) {				arr[i] = 100 + i;			} else if (i < 20) {				arr[i] = 1000 - i;			} else {				arr[i] = i;			}			strs[i] = "str" + arr[i];		}	}	public int[] getArr() {		return this.arr;	}	public String[] getStrs() {		return this.strs;	}	public static void main(String[] args) {		int size = 50;		ArraysTester tester = new ArraysTester(size);		int[] testerArr = tester.getArr();		int[] cloneArr = tester.getArr().clone();		String[] testerStrs = tester.getStrs();		String[] cloneStrs = tester.getStrs().clone();		// clone test		if (Arrays.equals(cloneArr, testerArr)) {			System.out.println("clonse int array is same.");		} else {			System.out.println("clonse int array is NOT same.");		}		if (Arrays.equals(cloneStrs, testerStrs)) {			System.out.println("clonse String array is same.");		} else {			System.out.println("clonse String array is NOT same.");		}		// 2부터 10까지 값 셋팅		Arrays.fill(cloneArr, 2, 10, new Double(Math.PI).intValue());		testerArr[10] = 98;		testerStrs[10] = "corea";		testerStrs[11] = null;		List<String> listTest = Arrays.asList(testerStrs);		System.out.println("listTest[10] = " + listTest.get(10));		System.out.println("------- unsorted arr -------");		System.out.println("Arrays.toString(int[]) = " + Arrays.toString(testerArr));		System.out.println("Arrays.toString(String[]) = " + Arrays.toString(testerStrs));		Arrays.sort(testerArr);		// Arrays.sort(testerStrs); //NullPointerException in sort method..(null이 없더라도 길이에 대한 크기 체크는 못함)		Arrays.sort(testerStrs, new Comparator<String>() {			public int compare(String s1, String s2) {				if (s1 == null && s2 == null) {					return 0;				} else if (s1 == null && s2 != null) {					return -1;				} else if (s1 != null && s2 == null) {					return 1;				} else if (s1.length() < s2.length()) {					return -1;				} else if (s1.length() > s2.length()) {					return 1;				} else if (s1.length() == s2.length()) {					return 0;				} else {					return s1.compareTo(s2);				}			}		});		System.out.println("------- sorted arr -------");		System.out.println("Arrays.toString(int[]) = " + Arrays.toString(testerArr));		System.out.println("Arrays.toString(String[]) = " + Arrays.toString(testerStrs));				System.out.println("------------------------------------------------");		String[][] mstrs1 = { { "A", "B" }, { "C", "D" } };		String[][] mstrs2 = { { "a", "b" }, { "c", "d" } };		String[][] mstrs3 = { { "A", "B" }, { "C", "D" } };		System.out.println("Arrays.deepToString(mstrs1) = " + Arrays.deepToString(mstrs1));		System.out.println("Arrays.deepToString(mstrs2) = " + Arrays.deepToString(mstrs2));		System.out.println("Arrays.deepToString(mstrs3) = " + Arrays.deepToString(mstrs3));				if( Arrays.deepEquals(mstrs1, mstrs2)) {			System.out.println("mstrs1 is same the mstrs2.");		}else {			System.out.println("mstrs1 is NOT same the mstrs2.");		}				if( Arrays.deepEquals(mstrs1, mstrs3)) {			System.out.println("mstrs1 is same the mstrs3.");		}else {			System.out.println("mstrs1 is NOT same the mstrs3.");		}				System.out.println("mstrs1's hashCode = " + Arrays.deepHashCode(mstrs1));		System.out.println("mstrs2's hashCode = " + Arrays.deepHashCode(mstrs2));		System.out.println("mstrs3's hashCode = " + Arrays.deepHashCode(mstrs3));	}}

8.2 Using java.util.Queue interface #

Queue를 이용하여 First In First OutOrdering한 Queue를 구현 가능하다.

package com.jeid.tiger;import java.util.LinkedList;import java.util.PriorityQueue;import java.util.Queue;public class QueueTester {	public static void main(String[] args) {		System.out.println("---------- testFIFO ----------");		testFIFO();		System.out.println("---------- testOrdering ----------");		testOrdering();	}	private static void testFIFO() {		Queue<String> q = new LinkedList<String>();		q.add("First");		q.add("Second");		q.add("Third");		String str;		while ((str = q.poll()) != null) {			System.out.println(str);		}	}	private static void testOrdering() {		int size = 10;		Queue<Integer> qi = new PriorityQueue<Integer>(size);		Queue<String> qs = new PriorityQueue<String>(size);		for (int i = 0; i < size; i++) {			qi.offer(10 - i);			qs.offer("str" + (10 - i));		}				for (int i = 0; i < size; i++) {			System.out.println("qi[" + i + "] = " + qi.poll() + ", qs[" + i + "] = " + qs.poll());		}	}}

8.3 java.lang.StringBuilder 사용하기 #

StringBuffer가 synchronize하지 않은 method들로 구성된 듯한 StringBuilder를 사용하므로 성능 향상을 도모할수 있다. 사용법은 StringBuffer와 동일하다.

package com.jeid.tiger;import java.util.ArrayList;import java.util.Iterator;import java.util.List;public class StringBuilderTester {	public static void main(String[] args) {		List<String> list = new ArrayList<String>();		list.add("str1");		list.add("str2");		list.add("str3");		String ret = appendItems(list);		System.out.println("ret = " + ret);	}	private static String appendItems(List<String> list) {		StringBuilder sb = new StringBuilder();		for (Iterator<String> iter = list.iterator(); iter.hasNext();) {			sb.append(iter.next()).append(" ");		}		return sb.toString();	}}

8.4 Using Type-Safe Lists #

Collection에 type을 명시하여 type-safe 하게 처리 가능. 아래에서 type을 명시하지 않을 경우 compile error가 남을 보여준다. tip으로 Number를 이용하여 byte, short, int, long, double, float 동시 사용하는 부분 참조.

package com.jeid.tiger;import java.util.Iterator;import java.util.LinkedList;import java.util.List;public class ListTester {	public static void main(String[] args) {		List<String> list = new LinkedList<String>();		list.add("str1");		list.add("str2");		list.add(new Integer(123));  // <-- String이 아니므로 compile error!!				//Iterator에 String type을 명시하므로 정삭작동됨.		for (Iterator<String> iter = list.iterator(); iter.hasNext();) {			String str = iter.next();			System.out.println("srt = " + str);		}				//Iterator에 String type을 명시하지 않았으므로 아래 A 부분에서 compile 오류 발생!!		for (Iterator iter = list.iterator(); iter.hasNext();) {			String str = iter.next(); //A			System.out.println("srt = " + str);		}				//byte, short, int, long, double, float 동시 사용		List<Number> lstNum = new LinkedList<Number>();		lstNum.add(1);		lstNum.add(1.2);		for (Iterator<Number> iter = lstNum.iterator(); iter.hasNext();) {			Number num = iter.next();			System.out.println("num = " + num);		}	}}

8.5 Writing Generic Types #

class 나 interface keyword에 type을 명시하여 동일 타입 명시 가능. 주의 할 점은 any type은 static 일 수 없다.(동적으로 type이 정해지므로)

class AnyTypeList<T> {//class AnyTypeList<T extends Number> {  // <-- 이는 Number를 상속한 type은 허용하겠다는 의미.	private List<T> list;	//private static List<T> list;  // <-- 이는 정적이므로 compile error 발생!!! 	public AnyTypeList(){		list = new LinkedList<T>();	}		public boolean isEmpty(){		return list == null || list.size() == 0;	}		public void add(T t){		list.add(t);	}		public T grap(){		if (!isEmpty() ) {			return list.get(0);		} else {			return null;		}	}}

8.6 새로운 static final enum #

예제를 통해 알아보자.

package com.jeid.tiger;import com.jeid.BaseObject;import com.jeid.MyLevel;public class EnumTester extends BaseObject {	private static long start = System.currentTimeMillis();		public static void main(String[] args) {		try {			test();			enum1();		} catch (Exception e) {			e.printStackTrace();		}		printEllapseTime();	}		private static void test() throws Exception {		byte[] b = new byte[0];		System.out.println(b.length);	}	private static void enum1() {		//enum TestEnum { A, B };  //enum cannot be local!!!				for(MyVO.TestEnum te: MyVO.TestEnum.values()){			System.out.println("Allow TestEnum value : " + te);		}		System.out.println("---------------------------------------");				MyVO vo = new MyVO();		vo.setName("enum1");		vo.setLevel(MyLevel.A);		System.out.println(vo);		System.out.println("isA = " + vo.isA() + ", isGradeA = " + vo.isLevelA()+ ", isValueOfA = " + vo.isValueOfA());		System.out.println("getLevelInKorean = " + vo.getLevelInKorean());	}	private static void printEllapseTime() {		System.out.println("==> ellapseTime is " + (System.currentTimeMillis() - start) + " ms.");	}}package com.jeid.tiger;import com.jeid.BaseObject;import com.jeid.MyLevel;public class MyVO extends BaseObject {	enum TestEnum {		A, B	}; // this is same public static final	private int id;	private String name;	private MyLevel grade;	// private List<T> list;	public MyLevel getLevel() {		return grade;	}	public void setLevel(MyLevel grade) {		this.grade = grade;	}	public boolean isA() {		return "A".equals(this.grade);	}	public boolean isValueOfA() {		return MyLevel.valueOf("A").equals(grade);	}	public boolean isLevelA() {		return MyLevel.A.equals(this.grade);	}	//A,B,C..대신 0,1,2... 도 동일함.	public String getLevelInKorean() {		switch(this.grade){		case A:			return "수";		case B:			return "우";		case C:			return "미";		case D:			return "양";		case E:			return "가";		default:			return "없음";		}	}	public int getId() {		return id;	}	public void setId(int id) {		this.id = id;	}	public String getName() {		return name;	}	public void setName(String name) {		this.name = name;	}}

8.7 Using java.util.EnumMap #

java.util.Map과 동일하나 key가 enum type이어 한다. 예제로 살펴보자.

package com.jeid.tiger;import java.util.EnumMap;public class EnumMapTester {	private enum MyEnum {		A, B, C	}; // this is same the static final..	public static void main(String[] args) {		MyEnum[] enums = MyEnum.values();		System.out.println("MyEnum is " + enums[0] + ", " + enums[1] + ", " + enums[2]);		EnumMap<MyEnum, String> em = new EnumMap<MyEnum, String>(MyEnum.class);		em.put(MyEnum.A, "수");		em.put(MyEnum.B, "우");		em.put(MyEnum.C, "미");		em.put(MyEnum.B, "가"); //key 중복은 HashMap과 동일하게 overwrite임.		for (MyEnum myEnum : MyEnum.values()) {			System.out.println(myEnum + " => " + em.get(myEnum));		}	}}

8.8 Using java.util.EnumSet #

java.util.Set과 동일하나 value가 enum type이어 한다. 예제로 살펴보자.

package com.jeid.tiger;import java.util.EnumSet;public class EnumSetTester {	private enum MyEnum {		A, B, C, a, b, c	}; // this is same the static final..	public static void main(String[] args) {		MyEnum[] enums = MyEnum.values();		System.out.println("MyEnum is " + enums[0] + ", " + enums[1] + ", " + enums[2]);		EnumSet<MyEnum> es1 = EnumSet.of(MyEnum.A, MyEnum.B, MyEnum.C);		EnumSet<MyEnum> es2 = EnumSet.of(MyEnum.a, MyEnum.b, MyEnum.c);		EnumSet<MyEnum> es3 = EnumSet.range(MyEnum.a, MyEnum.c);		if (es2.equals(es3)) {			System.out.println("e2 is same e3.");		}		for (MyEnum myEnum : MyEnum.values()) {			System.out.println(myEnum + " contains => " + es1.contains(myEnum));		}	}}

8.9 Convert Primitives to Wrapper Types #

int, short, char, long, double등 primitive와 이들의 Object Wrapper 인 Integer, Shrt, Char등 간의 converting에 있어 자동으로 처리해주는 boxing과 unboxing이 지원 됨에 따라 type에 대한 유연한 처리가 가능해졌다. 예제로 살펴보자.

package com.jeid.tiger;public class AutoBoxingTester {	public static void main(String[] args) {		int i = 0;		Integer ii = i; // boxing. JDK 1.4에서는 incompatible type error가 발생 했었으나 Tiger에서는 괜찮다.		int j = ii; // unboxing		for (ii = 0; ii < 5; ii++) { // Integer인데도 ++ 연산자 지원.		}		i = 129;		ii = 129;		if (ii == i) {			System.out.println("i is same ii.");		}		// -128 ~ 127 사이의 수는 unboxing이 되어 == 연산이 허용되지만,		// 그 범위 외의 경우 Integer로 boxing된 상태므로 equals를 이용해야함.		// 이는 버그가 발생했을 경우 찾기 쉽지 않은 단점도 내포하고 있다.!!		checkIntegerSame(127, 127); // same		checkIntegerSame(128, 128); // Not same		checkIntegerEquals(128, 128); // equals		checkIntegerSame(-128, -128); // same		checkIntegerSame(-129, -129); // Not same		checkIntegerEquals(-129, -129); // equals				System.out.println("--------------------------------------------");		Boolean arriving = false;		Boolean late = true;		String ret = arriving ? (late ? "도착했지만 늦었네요." : "제시간에 잘 도착했군요.") : 								(late ? "도착도 못하고 늦었군요." : "도착은 못했지만 늦진 않았군요.");		System.out.println(ret);				StringBuilder sb = new StringBuilder();		sb.append("appended String");		String str = "just String";		boolean mutable = true;		CharSequence chSeq = mutable ? sb : str;		System.out.println(chSeq);	}	private static void checkIntegerSame(Integer ii, Integer jj) {		if (ii == jj) {			System.out.println("ii = " + ii + ", jj = " + jj + " ==> jj is same ii.");		} else {			System.out.println("ii = " + ii + ", jj = " + jj + " ==> jj is NOT same ii!!");		}	}	private static void checkIntegerEquals(Integer ii, Integer jj) {		if (ii.equals(jj)) {			System.out.println("ii = " + ii + ", jj = " + jj + " ==> jj is equals ii.");		} else {			System.out.println("ii = " + ii + ", jj = " + jj + " ==> jj is NOT equals ii!!");		}	}}

8.10 Method Overload resolution in AutoBoxing #

int가 127을 초과할 경우 boxing이 이루어 질듯 하지만, method overload에 있어서는 boxing이 이루어 지지 않아 JDK1.4와 동일한 결과를 얻는다. 예제로 살펴보자.

package com.jeid.tiger;public class OverloadTester {	public static void main(String[] args) {		double d = 10;		Integer ii = new Integer(10);		doSomething(10);		doSomething(1000);		doSomething(ii);		doSomething(d);	}	private static void doSomething(Integer ii) {		System.out.println("This is doSomething(Integer)");	}	private static void doSomething(double d) {		System.out.println("This is doSomething(double)");	}}

8.11 가변적인 argument 개수 ... #

인수가 가변적일 경우 인수의 개수가 없는것 부터 다수개까지 모두 지원. 예제로 살펴보자.

package com.jeid.tiger;public class VarArgsTester {	public static void main(String[] args) {		setNumbers(1, 2);		setNumbers(1, 2, 3, 4);		setNumbers(1);		// setNumbers(); //해당 되는 method가 없어 compile error!!		System.out.println("==============================================");		setNumbers2(1, 2, 3, 4);		setNumbers2(1);		setNumbers2();	}	// this is same setNumbers(int first, int[] others)	private static void setNumbers(int first, int... others) {		System.out.println("-----------setNumbers()----------- : " + first);		for (int i : others) {			System.out.println("i = " + i);		}	}	// this is same setNumbers(int[] others)	private static void setNumbers2(int... others) {		System.out.println("-----------setNumbers2()----------- : "				+ (others != null && others.length > 0 ? others[0] : "null"));		for (int i : others) {			System.out.println("i = " + i);		}	}}

8.12 The Three Standard Annotation #

@Override - sign the override from superclass.

    //정상적인 사용    @Override    public int hashCode(){        return toString().hashCode();    }        //스펠링이 틀려 compile error!!    @Override    public int hasCode(){   //misspelled => method does not override a method from its superclass error!!        return toString().hashCode();    }

@Deprecated deprecated 주석과 동일하나 부모의 method가 deprecated되면 자식의 method를 사용해도 deprecated로 나온다.

package com.jeid.tiger;public class AnnotationDeprecateTester {	public static void main(String[] args){		DeprecatedClass dep = new DeprecatedTester();		dep.doSomething(10);    //deprecated	}}class DeprecatedClass {	@Deprecated	public void doSomething(int ii){    //deprecated		System.out.println("This is DeprecatedClass's doSomething(int)");	}		public void doSomethingElse(int ii){		System.out.println("This is DeprecatedClass's doSomethingElse(int)");	}}class DeprecatedTester extends DeprecatedClass {	@Override	public void doSomething(int ii){		System.out.println("This is DeprecatedTester's doSomething(int)");	}}

@SuppressWarnings SuppressWarnings에 인자는 String[] type으로 여러개를 배열형태로 쓸수 있다.

package com.jeid.tiger;import java.util.ArrayList;import java.util.List;public class AnnotationSuppressWarningsTester {	@SuppressWarnings({"unchecked", "fallthrough"} )	private static void test1(){		List list = new ArrayList();		list.add("aaaaaa");	}		@SuppressWarnings("unchecked")	private static void test2(){		List list = new ArrayList();		list.add("aaaaaa");	}		//warning이 없는 소스.	private static void test3(){		List<String> list = new ArrayList<String>();		list.add("aaaaaa");	}}

8.13 Creating Custom Annotation Types #

나만의 annotation을 정의할 수 있는데 키워드는 @interface이 각 method정의가 member라고 보면 된다. 간단한 예를 보면 다음과 같다.

package com.jeid.tiger;import java.lang.annotation.Documented;import java.lang.annotation.ElementType;import java.lang.annotation.Retention;import java.lang.annotation.RetentionPolicy;import java.lang.annotation.Target;@Documented@Target( { ElementType.TYPE, ElementType.FIELD, ElementType.METHOD, ElementType.ANNOTATION_TYPE })@Retention(RetentionPolicy.RUNTIME)public @interface MyAnnotation {	String columnName();	String methodName() default "";}//사용하는 쪽..public class AnnotationTester {	@MyAnnotation(columnName = "test", methodName = "setTest")	private String test;	@MyAnnotation(columnName = "grpid")	public String grpid;    ....}//위의 test 멤버의 경우 다음과 같이 접근 가능하다.Field testField = cls.getDeclaredField("test");if (testField.isAnnotationPresent(MyAnnotation.class)) {    Annotatioin anno = testField.getAnnotation(MyAnnotation.class);    System.out.println(anno.columnName() + ", method = " + anno.methodName());}

9 The for/in Statement #

9.1 for/in 의 자주 사용되는 형태 #

for/in은 무엇보다 다양한 유형의 예제를 보는것이 제일 빠를것이다. 형태별 사용 예제를 살펴보면 다음과 같다.

//1. 가장 단순한 형태인 배열(array)String[] strs = { "aaa", "bbb", "ccc" };for (String str : strs) {    System.out.println(str);}//2. List by using IteratorList<Number> lstNum = new LinkedList<Number>();lstNum.add(1);lstNum.add(1.2);for (Iterator<Number> iter = lstNum.iterator(); iter.hasNext();) {	Number num = iter.next();	System.out.println("num = " + num);}//3. List를 바로 사용List<String> lst = new LinkedList<String>();lst.add("aaaaa");lst.add("bbbbb");lst.add("ccccc");lst.add("ddddd");for (String str : lst) {	System.out.println("str = " + str);}// 4. List of ListList[] lists = { lst, lst };for (List<String> l : lists) {	for (String str : l) {		System.out.println("str = " + str);	}}

10 Static Import #

10.1 static member/method import #

Tiger에서는 다른 클래스의 member와 method를 import 할수 있다. 단, static 일 경우만 가능하다.

//예를 들어 System.out.println() 이라는 것을 사용하기 위해서는 다음의 import 문이 필요하다.import java.lang.System;   //물론 java.lang 이기에 import 문이 필요없지만 예를 들자면 그렇다는 것이다.&^^//허나, Tiger에서는 다음과 같이 사용할수 있다.import static java.lang.System.out;...out.println(...);// method를 import 한다면..import static java.lang.System.out.println;...println(...);

Posted by 1010
01.JAVA/Java2008. 8. 12. 10:33
반응형

어제 제가 개발한 시스템에 대해 윗분과 이야기 하는데

총 코딩 파일 라인수가 몇줄이냐고 물어보시는데 -_-;;

몰라서 당황했다는;; 전 나중에 산출물 작성할때나 알아볼까 했는데 흠.

암튼 이클립스에 라인수 측정하는 곳이 안보여서

예전에 만들어뒀던 소스 이용하여 약간 발전시켜 만들어 봤습니다.

이클립스에 이미 있는 기능이라면 저 또 뻘짓한 것이지만서도 ㅎㅎㅎ

뭐 공부용으로도 함 봐보셔도 괜찮을듯 싶습니다.





- Finder.java


/*
 * @Finder.java Created on 2006. 08. 24
 *
 * Copyright (c) 2005 GHLab.com All rights reserved.
 */

import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.text.NumberFormat;
import java.util.ArrayList;
import java.util.Locale;

/**
 * 파일 총 라인수 구하기.
 *
 * @version 1.0
 * @author 김건호
 */
class Finder {
    public static long totalFileSize = 0; // 전체 파일 사이즈 저장

    public long fileSize = 0; // 파일 사이즈 저장

    public static int totalFileLineCount = 0;

    public int fileLineCount = 0;

    // 파일 정보 저장
    public ArrayList<FileDTO> fileList = new ArrayList<FileDTO>();

    public final static int TOTAL_FIND_CODE = 0; // 전체 검색 코드

    public final static int FILENAME_FIND_CODE = 1; // 파일명 검색 코드

    public final static int EXTENSION_FIND_CODE = 2; // 확장자 검색 코드

    public int findTypeCode = TOTAL_FIND_CODE; // 검색 코드

    // 검색 파일명
    public String findFileName = "*.*";

    // 하위디렉토리 검색 여부
    public boolean isFindUnderDir = false;

    // 대소문자 구분
    public boolean isUpperLower = false;

    public static void main(String[] args) {
 if (args.length == 0 || args.length > 3) {
     StringBuffer sb = new StringBuffer();

     sb
      .append("사용법을 갈켜드리겠습니다~\n")
      .append(
       "예) Windows 폴더 내의 모든 파일의 용량 및 라인수를 추출하고 싶다면 아래처럼~\n\n")
      .append("java Finder c:\\windows\n\n")
      .append("파일을 지정하고 싶다면(기본 전체 파일 검색) 아래와 같은 옵션을 붙이면 됩니다.\n")
      .append("확장자 지정 검색 -e, 파일 지정 검색 : -f\n")
      .append("예) Windows 폴더 내의 확장자가 exe 인 파일을 검색\n\n")
      .append("java Finder c:\\windows -e exe\n\n")
      .append("하위 폴더를 포함하여 검색하고 싶다면 s 옵션을 붙이면 됩니다.\n")
      .append(
       "예) Windows 폴더와 하위 폴더의 모든 파일 중 파일명이 notepad.exe인 파일을 검색\n\n")
      .append("java Finder c:\\windows -sf notepad.exe\n\n")
      .append("파일명을 대소문자 구분하여 검색하려면 u 옵션을 붙이면 됩니다.\n")
      .append(
       "예) Windows 폴더와 하위 폴더의 모든 파일 중 확장자가 exe인 파일을 검색\n\n")
      .append("java Finder c:\\windows -sue exe");

     System.out.println(sb.toString());

     System.exit(1);
 }

 Finder f = new Finder();

 // 검색 경로
 String path = null;

 // 옵션
 String option = "";

 if (args.length > 0)
     path = args[0]; // 검색 경로 저장

 // 인자 갯수에 따른 분류
 if (args.length > 1) {
     // 옵션 저장
     option = args[1];

     // 검색 파일명 또는 확장자 저장
     f.findFileName = args[2];
 }

 // 옵션에 의한 데이터 셋팅
 if (option.indexOf("s") != -1)
     f.isFindUnderDir = true;

 // 대소문자 구분하지 않을 경우
 if (option.indexOf("u") != -1)
     f.isUpperLower = true;

 // 확장자 검색일 경우
 if (option.indexOf("e") != -1)
     f.findTypeCode = Finder.EXTENSION_FIND_CODE;

 // 파일명 검색일 경우
 if (option.indexOf("f") != -1)
     f.findTypeCode = Finder.FILENAME_FIND_CODE;

 // 확장자 검색과 파일명 검색은 함께 쓸수 없다.
 if (option.indexOf("e") != -1 && option.indexOf("f") != -1)
     System.out
      .println("확장자 검색과 파일명 검색 옵션 모두 입력하셨습니다.\n파일명 검색 모드로 자동 설정됩니다.");

 // 디렉토리 존재 여부
 File file = new File(path);
 if (file.isDirectory() == false) {
     System.out.println("정확한 경로를 입력하여 주십시오.");
     System.exit(1);
 }

 // 디렉토리 끝에 \ 또는 / 이 없으면 붙임
 String lastChar = path.substring(path.length() - 1, path.length());
 if (lastChar.equals(File.separator) == false) {
     path = path + File.separator;
 }

 try {
     f.getSize(path);
 } catch (Exception e) {
     System.out.println("에러!! : " + e.getMessage());
     e.printStackTrace();
 }

 System.out.println("검색된 파일 갯수  : " + f.fileList.size());

 // 검색된 파일 갯수가 있을 경우에 정보 출력
 if (f.fileList.size() > 0) {
     System.out.println("총 파일 사이즈 : " + byteTranslater(totalFileSize));
     System.out.println("총 라인수 : " + totalFileLineCount + "라인");

     System.out.print("검색된 파일 정보를 보시겠습니까?(Y/N) : ");

     String choice = null;

     try {
  BufferedReader in = new BufferedReader(new InputStreamReader(
   System.in));
  choice = in.readLine();

     } catch (Exception e) {
  choice = "N";
     }

     choice = choice.toUpperCase();

     if (choice.equals("Y")) {
  // 파일 정보 추출
  FileDTO[] fdto = f.getFileList();

  for (int i = 0; i < fdto.length; i++) {
      System.out.println("파일 : " + fdto[i].getFilePath()
       + fdto[i].getFileName() + ", 사이즈 : "
       + byteTranslater(fdto[i].getFileSize())
       + ", 라인수 : " + fdto[i].getFileLineCount());
  }
     }
 }

 System.exit(1);
    }

    /**
     * 해당 경로에서 파일을 찾아 용량, 라인수를 측정
     *
     * @param path
     *                파일을 찾을 경로
     * @param findFileName
     *                모든 파일 찾기(*.*), 확장자로 찾기(*.java), 파일명 찾기(test.java)
     * @param isFindUnderDir
     *                하위디렉토리 검색 여부
     * @throws Exception
     */
    public void getSize(String path) throws Exception {
 File dir = new File(path);

 String[] list = dir.list();

 File file;

 BufferedReader br = null;

 String fileName = null; // 파일명 저장

 String filePath = null; // 파일 경로

 String findFileName = this.findFileName;

 for (int i = 0; i < list.length; i++) {
     file = new File(path + list[i]);

     fileSize = 0; // 해당 파일 크기 0으로 초기화
     fileLineCount = 0; // 해당 파일 총 라인수 0으로 초기화

     // 파일만 계산
     if (file.isFile()) {
  fileName = file.getName(); // 파일명 추출

  // 대소문자 구분 하지 않는다면 모두 대문자로 변경
  if (this.isUpperLower == false) {
      fileName = fileName.toUpperCase(Locale.KOREAN);
      findFileName = findFileName.toUpperCase(Locale.KOREAN);
  }

  filePath = file.getPath(); // 파일경로 추출

  // 검색 형태에 따른 조건 설정
  if ((findTypeCode == TOTAL_FIND_CODE)
   || (findTypeCode == EXTENSION_FIND_CODE && fileName
    .substring(fileName.lastIndexOf(".") + 1,
     fileName.length()).equals(findFileName))
   || (findTypeCode == FILENAME_FIND_CODE && fileName
    .equals(findFileName))) {
      br = new BufferedReader(new InputStreamReader(
       new FileInputStream(filePath)));

      // 라인수 추출
      while (br.readLine() != null) {
   fileLineCount++;
      }

      fileSize = file.length(); // 파일 크기 추출

      FileDTO fdto = new FileDTO();

      fdto.setFileSize(fileSize);
      fdto.setFileName(file.getName());
      fdto.setFilePath(filePath.substring(0, filePath
       .lastIndexOf(File.separator) + 1));
      fdto.setFileLineCount(fileLineCount);

      fileList.add(fdto);
  }
     }

     // 해당 폴더내의 모든 파일의 크기 추출을 위한 연산
     totalFileSize += fileSize;
     // 해당 폴더내의 모든 파일의 라인수 추출을 위한 연산
     totalFileLineCount += fileLineCount;

     // 하위 디렉토리가 있고, 옵션을 하위 디렉토리 검색을 지정했을 경우 재귀호출
     if (file.isDirectory() && isFindUnderDir)
  getSize(file.getPath() + File.separator);
 }
    }

    /**
     * ArrayList 에 담겨진 파일 정보 DTO를 배열로 전환하여 받아옴
     *
     * @return 파일 정보 목록
     */
    public FileDTO[] getFileList() {
 FileDTO[] result = new FileDTO[fileList.size()];

 for (int i = 0; i < result.length; i++) {
     result[i] = new FileDTO();

     result[i] = fileList.get(i);
 }

 return result;
    }

    /**
     * 파일 사이즈 단위 변환
     *
     * @param size
     *                long 형 타입의 파일 사이즈
     * @return KB, MB, GB 로 변환한 사이즈
     */
    public static String byteTranslater(long size) {
 NumberFormat nf = NumberFormat.getIntegerInstance();

 java.text.DecimalFormat df = new java.text.DecimalFormat("#,##0.00");

 int intSize = 0;

 int kbyteSize = 1024;

 double doubleSize = 0;

 String returnSize = null;

 // 파일 사이즈가 1000, 2000 형식이므로 기가는 1024 가 아닌 1000을 기준으로.
 if (size >= (1000 * 1024 * 1024)) {
     intSize = new Long(size / (1000 * 1024 * 1024)).intValue();

     return nf.format(intSize) + "GB";
 } else if (size > (kbyteSize * 1024)) {
     intSize = (int) (((double) size) / ((double) (kbyteSize * 1024)) * 100);

     doubleSize = (double) (((double) intSize) / 100);

     returnSize = df.format(doubleSize);

     if (returnSize.lastIndexOf(".") != -1) {
  if ("00".equals(returnSize.substring(returnSize.length() - 2,
   returnSize.length()))) {
      returnSize = returnSize.substring(0, returnSize
       .lastIndexOf("."));
  }
     }

     return returnSize + "MB";
 } else if (size > kbyteSize) {
     intSize = new Long(size / kbyteSize).intValue();

     return nf.format(intSize) + "KB";
 } else {
     // return nf.format(size) + "Byte";
     return "1KB";
 }
    }
}

/**
 * 파일 정보 저장 객체
 *
 * @version 1.0
 * @author 김건호
 */
class FileDTO {
    public int fileLineCount;

    private long fileSize;

    private String filePath;

    private String fileName;

    public FileDTO() {
 fileSize = 0;
 filePath = null;
    }

    /**
     * @return the fileLineCount
     */
    public int getFileLineCount() {
 return fileLineCount;
    }

    /**
     * @param fileLineCount
     *                the fileLineCount to set
     */
    public void setFileLineCount(int fileLineCount) {
 this.fileLineCount = fileLineCount;
    }

    /**
     * @return the fileName
     */
    public String getFileName() {
 return fileName;
    }

    /**
     * @param fileName
     *                the fileName to set
     */
    public void setFileName(String fileName) {
 this.fileName = fileName;
    }

    /**
     * @return the filePath
     */
    public String getFilePath() {
 return filePath;
    }

    /**
     * @param filePath
     *                the filePath to set
     */
    public void setFilePath(String filePath) {
 this.filePath = filePath;
    }

    /**
     * @return the fileSize
     */
    public long getFileSize() {
 return fileSize;
    }

    /**
     * @param fileSize
     *                the fileSize to set
     */
    public void setFileSize(long fileSize) {
 this.fileSize = fileSize;
    }

}

Posted by 1010
01.JAVA/Java2008. 7. 26. 16:59
반응형
순수자바기반 무료레포팅툴 iReport
2008.05.05 18:31
http://tong.nate.com/lhs0806/44879819 iReport 개발자 매뉴얼.part1.rar
iReport 개발자 매뉴얼.part2.rar
JasperReports_개발자_매뉴얼-rokmc7980304.pdf
ireport를 살짝 소개합니다. | 자유로운글
 
안녕하세요...
원래 듬직한 몸뚱아리였으나...(췌)
IT에 발들이고 나서
D라인의 환상 몸매를 갖게 된 쿠쿠입니다...(췌)
 
리포트 툴 하나 간단히 소개 할까 해서 ...
(파는거 아니에요 ㅡ,.ㅡ)
보통 리포트 툴이 꽤 비싸다는 것을 다들 아실꺼에요...
(싸게는 수백에서... 비싸게는 수천까지...)
하지만
iReport라는 이 툴은 무료입니다..
-_-v
엑셀, pdf, http 다양한 출력이 가능하지요...(사실 http는 보기가 어려워요... 꾸져 췌)
그래도 공짜니까....흠...
 
설치방법이나 소스 자체는 오픈이라 네이버에서
ireport만 치셔도 많이 나오구요..
전 그냥 간단한 소개만 할께요 ^^
 
우선 이것이 첫 화면입니다...


쿠쿠
투박한 녀석...
까만 부분은 저희 프로젝트의 DBCon이름인데...
티나서 ㅡ,.ㅡ
이해해주시길 믿습니다...
 
 요렇게 Report Wizard를 누르시고

 

검은 부분에서 DB선택하신후 그 아래 SQL query부분에 쿼리를 직접 쓰거나 쿼리 파일을 로드 해주십니다...


이렇게...

모자이크 처리 미숙이 돋보입니다..

ㅡ_ㅡ;;;

흠흠...

여하튼 넥스트...



자 그러면 자동으로 column을 만들어 주고,

>> 요 버튼으로 한번에 보내던지 >버튼으로 하나씩 보내고 필요없는 애를 빼던지

할 수 있습니다...

다음단계는 Gruop by를 어떤 컬럼으로 할 것인가

체크하는 부분이고 5개까지의 컬럼으로 group by할 수 있습니다.

(더 많았는지는 해보질 않아서 모르겠습니다... ㅡ,.ㅡ)


Layout은 화면을 어떤 모양으로 출력해 줄것인가 하는 부분이라서

이것 저것 눌러보고 예쁜 걸로 하세요...

물론 가로 세로도 가능하고요...


물론 변수를 받을 수도 있구요....

리포트 안에 subreport를 넣어서 멋진 모양들도 만들 수 있답니다...

챠트도 넣을 수 있다고 하는데...

전 안해봐서 ^^;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


그리하여 나오는 화면은 대충 이렇습니다...


 
이 넘은
JAVA기반이고
jrml 파일을 컴파일하면 jasper라는 파일이 생깁니다.
이 jasper파일을 서버에 올리시고
변수를 넣어서 call하시면 바로 위 화면이 짜잔 하고 나타나서
사용하시면 됩니다....^^
 
완전 후다닥
정리해서 제대로 설명이 되지도 않았네요...
혹시 나중에 시간이 되면 더 예쁘게 잘 정리해보도록 하겠습니다...
 
나만 그런지 모르겠지만...
전 문서 정리가 제일 싫어요 ㅠㅠ
Posted by 1010
01.JAVA/Java2008. 7. 26. 16:57
반응형
가까운 자바의 미래 JDK 7 Project
2007.11.28 01:25
http://tong.nate.com/lhs0806/42082612 java-se-7-EclipseCon-2007.pdf
Java7Overview_Prague_JUG.pdf
2101.pdf

jdk7 프로젝트 홈


귀하가 등록된 상태와 로그인 된 상태이셨다면 귀하는 프로젝트에 참여하실 수 있습니다.

요약 JDK 7 Snapshot Releases
카테고리 없음
라이센스 Java Research License (JRL)
소유자 bcbeck, mreinhold, peterkessler
JDK 7 Project
Building the next generation of Java SE platform
download it
Download it
use it
Use it
improve it
Improve it
openjdk
Open Source
NetBeans
Download NetBeans

Sun is releasing weekly early access snapshots of the complete source, binaries and documentation for JDK 7. These snapshot releases let you review and contribute to the Java SE platform as it is being developed.

Download JDK 7

 
  • Latest JDK 7 binary snapshots
  • Latest JDK 7 source snapshots
  • Latest JDK 7 Java Docs
  • Summary of changes in JDK 7
  • We Want Contributions!

    Frustrated with a bug that never got fixed? Have a great idea for improving the Java SE platform? See How to Collaborate for information on making contributions to the platform.

    News

     
    • The openjdk project is now available shipping HotSpot, javac and JavaHelp as the initially available open source components.
    • The JDK 7 project opens for business at https://jdk7.dev.java.net/. But you knew that already.  [August 15 2006]

    Feedback

    Please use the Project Feedback forum if you have suggestions for or encounter issues with using the JDK 7 snapshots.

    If you find bugs in a snapshot release, please submit them using the usual Java SE bug reporting channels, not with the Issue tracker accompanying this project. Be sure to include complete version information from the output of the  java -version command.




    코멘트
    이제 좀있다 7 도 나오네..


    Posted by 1010
    01.JAVA/Java2008. 7. 24. 13:57
    반응형
    JSP Tips
    http://www.okjsp.pe.kr/seq/42732
    유효하지 않는 전자메일 2004-03-18 00:19:30.0
    park17@empal.com http://www.gampol.net
    자바로 썸네일 빈즈를 함 만들어 보았네요..!!!

    테스트 환경

    j2sdk1.4.x
    jai 1.x
    window 2000, Linux
    Tomcat 4.1.x


    www.gampol.net에서 테스트 해 보실수 있습니다.

    집에있는 컴이라 보통 저녁 10시까진 On상태이고

    제가 잠잘때는 Off상태입니다.


    먼저 SUN사이트에서 jai(Java Advanced Imaging 1.1.2)
    를 다운로드 받으셔야 합니다.

    http://java.sun.com/products/java-media/jai/downloads/download-1_1_2.html

    다운 받고 압축이나 실행파일을 실행 하시면

    jai_codec.jar, jai_core.jar

    파일을 CLASSPATH에 추가하시고

    JAVA_OPTS="-Djava.awt.headless=true"

    또는

    CATALINA_OPTS="-Djava.awt.headless=true"

    환경변수를 셋팅하시고

    또는 빈즈나 서블릿 실행시

    System.setProperty("java.awt.headless", "true");

    이걸 추가 하시기 바랍니다.


    메소드는 대충 보시면 아실겁니다..

    배율, 넓이높이 지정

    파일로도 저장 가능하고 서버에 있는 이미지를 웹상에서 걍 보여 줄수도 있습니다.


    문의 사항이나 버그가 있으면

    park17@empal.com으로 연락 바랍니다.

    그럼 유용하게 사용하시기 바랍니다..

    출처 : Tong - 설레임중독자님의 JAVA통

    Posted by 1010
    01.JAVA/Java2008. 7. 23. 09:16
    반응형
    for(int x=0;x<str.length();i++){
    if ( str.charAt(i) >= '\uAC00' && str.charAt(i) <= '\uD7A3' ){
    Log.debug("한글");
    }else{
    Log.debug("한자");
    }
    Posted by 1010
    01.JAVA/Java2008. 7. 15. 13:44
    반응형

    유닉스에서 자바 이미지 객체를 사용하려 할때 다음과 같은 에러가 발생한다.


    Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.


    이것은 일종의 JDK의 버그이다. 원인은 자바가 BufferedImage 를 생성하고 실제로 Graphics 객체를 얻어오기 위해 getGraphics나 createGraphics 메소드를 부를때, 실제로 display하거나 mouse, keyboard 자원을 하나도 쓰지 않을 것임에도 불구하고 내부적으로 AWT Toolkit이 그것들에 대한 자원을 얻어오게 되어있었기 때문이다. 

    Sun에서는 이걸 버그로 취급하며 해결 방법은 2가지가 있다.


    1. JRE 1.3 이하 일경우 www.x.org 에서 다운로드 받을 수 있는 Xvfb 라는 것을 사용하는 방법이다. 이것은 X-server 에뮬레이터이다.


    참고

    1.1. 가상 xwindow실행하기

    1.1.1 리눅스

    리눅스의 경우 XFree86-Xvfb-4.1.0-3.i386.rpm 을 설치해야 합니다.
    XFree86-Xvfb-4.1.0-3.i386.rpm 패키지는 아래의 패키지가 최소한 설치되어 있어야 합니다.
    XFree86-4.1.0-3.i386.rpm
    Mesa-3.4.2-7.i386.rpm
    Xaw3d-1.5-10.i386.rpm

    설치과정중에 에러가 발생하면 아래 커맨드를 이용하여 의존성을 검사하면 됩니다.
    rpm -ivh --nodeps ./Mesa-3.4.2-7.i386.rpm
    rpm -ivh ./XFree86-4.1.0-3.i386.rpm
    rpm -ivh ./Xaw3d-1.5-10.i386.rpm
    rpm -ivh ./XFree86-Xvfb-4.1.0-3.i386.rpm

    Xvfb는 100dpi 및 75dpi용 폰트도 설치되어 있어야 합니다.
    폰트와 관련하여 간단하게 작업하려면 아래와 같이 하세요
    wget http://www.psoft.net/downloads/X11.tgz
    tar xfz ./X11.tgz -C /usr/X11R6/lib/

    이제 모든 설치가 완료되면 아래 커맨드로 Xvfb를 활성화 시킵니다.
    /usr/X11R6/bin/Xvfb ':0' -screen 0 100x100x8 &

    이제 서버가 시작할 때 마다 이 기능을 활성화 시키려면
    /etc/rc.d/rc.local에 추가하면 됩니다.


    1.2.1  Solaris :

    다운로드 : X11R6_bin.tar.gz

    1.2.2 설치 :
    % su -
    # mkdir /usr/X11R6
    # cp X11R6_bin.tar.gz /usr/X11R6
    # cd /usr/X11R6
    # gunzip X11R6_bin.tar.gz
    # tar xvf X11R6_bin.tar
    # rm X11R6_bin.tar


    1.2.3. 자동실행
    실행 스크립트 : xvfb.server 다운로드
    자동 실행 설정 스크립트 : install.xvfb다운로드
    xvfb.server에서 RUN_AS_USER=tomcat 을 적절히 수정 후 install.xvf 만 실행하면 끄~읕

    참조 :
    http://www.x.org/
    http://developers.sun.com/solaris/articles/solaris_graphics.html#3
    http://www.idevelopment.info/data/Unix/General_UNIX/GENERAL_XvfbforSolaris.shtml
    http://chartworks.com/support/server/XvfbonUnix.html
     


    2. JRE 1.4 이상에서  Headless AWT Toolkit을 이용해서 이 문제를 해결한다. 파일을 실행할때 간단히 -Djava.awt.headless=true 옵션을 주는것만으로 가능하다.
     

    [참고]

    java 1.4 버전 이상에서는 자바 자체에서 처리 가능하게 할수 있습니다.

    리눅스에서 굳이 x-window나 xvf 깔기 귀찮다고 아니면 할줄 모르시는 분들은 간단하게 이문제를 해결하는 방법이 있습니다.

    <!--
    Note: If true, the system property, java.awt.headless, will be set to true.
    This should be used with JDK 1.4+ on servers without graphics cards and
    monitors. Otherwise, the property is not set.
    -->
    <!-- <headless-server>true</headless-server> -->

    /WEB-INF/flex/flex-config.xml에서 이부분의 주석을 제거 해주시면 됩니다.

    <headless-server>true</headless-server>


    그리고 자바 구동시에(톰켓이나 레진) JVM 파라메터를 적는 부분이 있을 것입니다.

    레진 같은 경우 걍 뒤에 자바 파라메터 적으면 작동됩니다.

    resin start -Djava.awt.headless=true


    즉 flex-config에서 headless-server 수정하고 jsp 엔진 구동시에 파라 메터 Djava.awt.headless=true 를 넣어주면 에러없이 잘 해결된다.


    톰캣에서 이용할때는 catalina.sh 파일에
    CATALINA_OPTS=-Djava.awt.headless=true를 추가하고 재구동하면 된다.

    Posted by 1010
    01.JAVA/Java2008. 7. 15. 10:36
    반응형
    Fedora 9 버전 배포본에 포함된 패키지로서 오픈 소스로 개발되고 있는 JDK 1.6 버전을 설치 가능하다. 패키지 명은 다음과 같다: java-1.6.0-openjdk

    less..

    # yum install java-1.6.0-openjdk
    Loaded plugins: priorities
    fedora                                                   | 2.4 kB     00:00
    updates                                                  | 2.3 kB     00:00
    Setting up Install Process
    Parsing package install arguments
    Resolving Dependencies
    --> Running transaction check
    ---> Package java-1.6.0-openjdk.i386 1:1.6.0.0-0.12.b09.fc9 set to be updated
    --> Processing Dependency: tzdata-java for package: java-1.6.0-openjdk
    --> Running transaction check
    ---> Package tzdata-java.noarch 0:2008b-1.fc9 set to be updated
    --> Finished Dependency Resolution

    Dependencies Resolved

    =============================================================================
     Package                 Arch       Version          Repository        Size
    =============================================================================
    Installing:
     java-1.6.0-openjdk      i386       1:1.6.0.0-0.12.b09.fc9  updates            28 M
    Installing for dependencies:
     tzdata-java             noarch     2008b-1.fc9      fedora            167 k

    Transaction Summary
    =============================================================================
    Install      2 Package(s)
    Update       0 Package(s)
    Remove       0 Package(s)

    Total download size: 28 M
    Is this ok [y/N]: y
    Downloading Packages:
    (1/2): tzdata-java-2008b-1.fc9.noarch.rpm                | 167 kB     00:00
    (2/2): java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.i386.rpm  |  28 MB     00:55
    Running rpm_check_debug
    Running Transaction Test
    Finished Transaction Test
    Transaction Test Succeeded
    Running Transaction
      Installing: tzdata-java                  ######################### [1/2]
      Installing: java-1.6.0-openjdk           ######################### [2/2]

    Installed: java-1.6.0-openjdk.i386 1:1.6.0.0-0.12.b09.fc9
    Dependency Installed: tzdata-java.noarch 0:2008b-1.fc9
    Complete!
    # java -version
    java version "1.6.0"
    OpenJDK  Runtime Environment (build 1.6.0-b09)
    OpenJDK Client VM (build 1.6.0-b09, mixed mode)
    #

    less..


    gcj 관련된 패키지와 함께 사용하기 위해서는, java-1.5.0-gcj-compat 패키지를 추가로 설치한다.

    less..

    # yum install java-1.4.2-gcj-compat
    Loaded plugins: priorities
    Setting up Install Process
    Parsing package install arguments
    Resolving Dependencies
    --> Running transaction check
    ---> Package java-1.5.0-gcj.i386 0:1.5.0.0-21.fc9 set to be updated
    --> Processing Dependency: sinjdoc for package: java-1.5.0-gcj
    --> Running transaction check
    ---> Package sinjdoc.i386 0:0.5-6.fc9 set to be updated
    --> Processing Dependency: java_cup >= 0.10 for package: sinjdoc
    --> Running transaction check
    ---> Package java_cup.i386 1:0.10-0.k.6jpp.2 set to be updated
    --> Finished Dependency Resolution

    Dependencies Resolved

    =============================================================================
     Package                 Arch       Version          Repository        Size
    =============================================================================
    Installing:
     java-1.5.0-gcj          i386       1.5.0.0-21.fc9   fedora            127 k
    Installing for dependencies:
     java_cup                i386       1:0.10-0.k.6jpp.2  fedora            175 k
     sinjdoc                 i386       0.5-6.fc9        fedora            786 k

    Transaction Summary
    =============================================================================
    Install      3 Package(s)
    Update       0 Package(s)
    Remove       0 Package(s)

    Total download size: 1.1 M
    Is this ok [y/N]: y
    Downloading Packages:
    (1/3): java_cup-0.10-0.k.6jpp.2.i386.rpm                 | 175 kB     00:00
    (2/3): sinjdoc-0.5-6.fc9.i386.rpm                        | 786 kB     00:01
    (3/3): java-1.5.0-gcj-1.5.0.0-21.fc9.i386.rpm            | 127 kB     00:00
    Running rpm_check_debug
    Running Transaction Test
    Finished Transaction Test
    Transaction Test Succeeded
    Running Transaction
      Installing: java-1.5.0-gcj               ######################### [1/3]
      Installing: sinjdoc                      ######################### [2/3]
      Installing: java_cup                     ######################### [3/3]

    Installed: java-1.5.0-gcj.i386 0:1.5.0.0-21.fc9
    Dependency Installed: java_cup.i386 1:0.10-0.k.6jpp.2 sinjdoc.i386 0:0.5-6.fc9
    Complete!

    less..


    기존 패키지에 포함된 Java 플랫폼의 문제점은 Fedora Project JavaFAQ를 참고한다.
    Posted by 1010
    01.JAVA/Java2008. 7. 14. 23:50
    반응형

    저는 rpm 파일로부터 설치하지 않고, 바로 bin 파일을 다운받아 설치합니다.


    jdk-1_5_0_14-linux-i586.bin 파일을 다운받아

    아래와 같은 명령어 순으로 설치를 하고, 환경설정까지 하면..

    리눅스에 완벽한 java 설치가 끝나게 됩니다.


    1. java 설치 파일의 퍼미션 변경(설치할 수 있도록 실행파일로 바꿈)

    chmod 755 jdk-1_5_0_14-linux-i586.bin


    2. 원하는 위치로 이동(저는 개인적으로 /usr/local에 모든 사용자 파일을 넣기 때문에. -0-;;)

    mv jdk-1_5_0_14-linux-i586.bin /usr/local


    3. 설치

    ./jdk-1_5_0_14-linux-i586.bin


    4. 설치할 때.. 라이센스를 확인하는게 나오는데.. 스페이스 여러번 누르고, 마지막에 yes 한번이면 설치가 끝납니다. ^^


    5. 설치가 끝나면.. 아래와 같은 디렉터리가 생성됩니다.

    jdk-1_5_0_14-linux-i586


    6. 다음에 버전이 다른 java를 손 쉽게 변경하기 위해(환경은 건드리지 않고..) 링크를 걸어줍니다.

    ln -s /usr/local/jdk-1_5_0_14-linux-i586 /usr/local/java


    7. 환경설정파일을 건드려봅시다~~

    vi /etc/profile


    JAVA_HOME=/usr/local/java
    export JAVA_HOME
    PATH=$PATH:$JAVA_HOME/bin

    CLASSPATH=$CLASSPATH:$JAVA_HOME/lib/*:.


    8. 환경설정 파일을 업로드 시켜 줍니다.

    source /etc/profile


    9. java가 제대로 동작하는지 확인..





    -------------------------------------------------------------------------------------------------------


    Java의 원조는 Sun이지만 GNU를 비롯하여 여러 벤더들이 자바 플랫폼을 - 컴파일러와 가상 머신(Java Runtime Environment, JRE) 그리고 여러 툴을 포함해서 - 배포하고 있다. 대부분의 리눅스 배포판에는 GNU-Java가 탑재되어 있는데 아마도 Sun Java는 open source가 아니기 때문이리라 생각된다. 여기서는 페도라 6 (이하 페도라)에 Sun Java 1.6.0-update 2버전의 Java SE (Standard Edition, SDK + JRE)를 설치하는 방법을 설명한다. 2007년 8월 현재 Sun Java의 최신 버전은 1.6.0-update 2이고 페도라에 깔린 GNU-Java는 1.4.2 버전이다.

    문제점
    설치만 높고 본다면 Sun에서 자체적으로 실행이 가능한 설치파일과 rpm 패키지 두가지 형태로 Java SE 를 제공하고 있기 때문에 특별히 어려울 건 없다. 그리고 원한다면 GNU-Java를 언인스톨해버리면 그만이다. 그러나 혹시나 다른 프로그램들이 디폴트로 GNU-Java를 찾게 설정되어 있을 가능성도 있고, 또는 GNU-Java를 시스템에 지우지 않고 필요할 때마다 Sun Java랑 쉽게 바꿔가며 쓰고 싶은 경우가 있을 것이다. 실제로 어떤 프로램들이 GNU-Java를 디폴트로 설정되어 있는 지 확인하여 보지는 않았지만, 만약 그런 프로그램들이 있다면 단순한 설정파일을 고치는것도 때에 따라선 초보 리눅서에게는 쉽지 않은 삽질이 될 수도 있을 것이다.

    실제로 Sun Java가 설치되는 디렉토리는 각 리눅스 배포판의 프로그램 설치 관행과는 일치하지 않는다. Sun Java를 rpm으로 설치하는 경우 /usr/Java/jdk버전/ 디렉토리 밑에 설치가 되는데, 페도라의 경우는 여러 종류의 자바를 /usr/lib/jvm/Java버전-배포자/ 디렉토리 밑에 설치하고, 이들을 alternatives를 통해 이중 링크로 관리한다. 예를 들어 /usr/bin/Java 명령은 /etc/alternatives/Java에 대한 소프트 링크이고, 이 링크는 다시 /usr/Java/아래 설치된 여러 Java버전 중 하나를 가르키는 소프트 링크이다. 자세한 내용은 alternatives의 man page를 참조.

    대안
    그렇다면 각 배포판의 관행에 맞추어 Sun Java를, 아니면 여러개의 다른 Java패키지을 설치하고 이를 쉽게 관리하는 방법은 없을까? 여기에 대한 대안이 Jpackage와 alternatives를 활용하는 방법이다. Jpackage는 각종 자바 패키지를 리눅스의 디렉토리 배치 관행에 맞게 설치되도록 재패키징한 것으로 여기에는 Sun이나 IBM의 자바 플랫폼도 포함된다. 다만 이들의 경우 재배포는 허용되지만 아직 open source는 아니기 때문에 소스코드는 포함하고 있지 않다.

    설치
    Jpackage의 Sun Java를 설치하기로 맘을 먹었다면 두가지 방법이 있는데 Jpackage.org에서 재패키징한 Sun Java패키지(java-1.6.0-sun-버전번호-1jpp.nosrc.rpm)를 직접 빌드해서 설치하거나; Sun에서 직접 배포한 Java패키지를 설치한 후 이걸 리눅스 디렉토리구조와 호환되게 만들어 주는 패키지(Java-1.6.0-Sun-compat-버전번호-1jpp.i586.rpm)를 설치하는 것이다. 여기서는 후자의 방법을 택하겠다. 설치 순서는 간단하다: 1) Sun Java 패키지 다운로드 및 설치 2) Jpackage 다운로드 및 설치 3) Alternatives 확인 및 설정 4) JAVA_HOME 환경변수 설정 5) 그리고 보너스로 mozilla 또는 firefox에 Java 플러그인 설치 확인.

    1) Sun Java 패키지 다운로드 및 설치
    http://Java.Sun.com/downloads에 가서 jdk-6u2-linux-i586-rpm.bin를 다운로드한다. 위에서 언급한 대로 두가지 형태로 제공이 되는데 반드시 rpm으로 제공되는 Linux RPM in self-extracting file (Linux self-extracting file 이 아니다)를 받아 아래와 같이 설치한다. 혹시나 초보 리눅서를 위하여 설치명령을 자세히 설명하였다.

    cd 다운로드한 디렉토리
    chmod 755 jdk-6u2-linux-i586-rpm.bin
    ./jdk-6u2-linux-i586-rpm.bin


    2) Jpackage 다운로드 및 설치
    Jpackage를 설치하기 전에 확인해야 할 사항이 하나 있는데 바로 jpackage-utils 패키지가 이미 설치되어 있는지 확인하는 것이다. 아래와 같이 jpackage설치여부를 확인하고 설치할 수 있다.

    rpm -qa | grep jpackage-utils

    위 명령결과 아무것도 안나오면, 아래와 같이 jpackage-utils패키지를 설치한다.

    yum install jpackage-utils


    그 다음에는 아래 링크에서 Jpackage를 다운받아 설치한다. ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/RPMS.non-free/. 이때 반드시 1)에서 설치한 Sun Java와 같은 버전의 화일을 다운 받아야 하는데 여기에서는 1.6.0-update 2를 설치했으므로 Java-1.6.0-Sun-compat-1.6.0.02-1jpp.i586.rpm를 받아야 할 것이다. 다음과 같이 설치한다.

    cd 다운로드한 디렉토리
    rpm -Uvh Java-1.6.0-Sun-compat-1.6.0.02-1jpp.i586.rpm


    3) Alternatives 확인 및 설정
    위 패키지를 설치하면 /usr/lib/jvm/와 /etc/alternatives/ 디렉토리 밑에 약간 어지러울 정도로 많은 링크를 만든 후에 디폴트로 Sun Java를 사용하도록 alternatives를 셋팅해 주는데 아래와 같이 확인 해볼 수 있다.

    alternatives --config Java

    위 명령 결과는 아래와 같이 보일 것이다.

    There are 2 programs which provide 'Java'.

    Selection Command
    -----------------------------------------------
    1 /usr/lib/jvm/jre-1.4.2-gcj/bin/Java
    *+ 2 /usr/lib/jvm/jre-1.6.0-Sun/bin/Java

    원한다면 다시 GNU 자바를 디폴트로 잡아 줄 수 있는데 자세한 용법은 다시 alternatives의 man page를 참고.

    4) JAVA_HOME 환경변수 설정

    bash사용자는 export JAVA_HOME=/usr/lib/jvm/java를 c-shell 사용자는 setenv JAVA_HOME /usr/lib/jvm/java를 적당한 시작 스크립트 화일에 넣어준다. Bash의 경우 ~/.bash_profile에 넣으면 무난할 듯.

    5) mozilla 또는 firefox에 Java 플러그인 설치 확인

    위 1)번 과정에서 Sun Java 32비트 버전을 설치하면 SDK나 JRE외에 mozilla나 firefox에서 플러그인으로 사용할 수 있는 라이브러리 파일인 libJavaplugin_oji.so가 같이 설치되는데 Java-1.6.0-Sun-compat-1.6.0.02-1jpp.i586.rpm 패키지 설치과정에서 위 플러그인을 사용할 수 있도록 mozilla 플러그인 디렉토리 밑에 소프트 링크를 만들어 준다. 아쉽지만 64비트 버전 Java의 경우 플러그인이 아직 제공되지는 않는다. 다음과 같이 확인할 수 있다.

    ls -l /usr/lib/mozilla/plugins

    위 명령 결과 화면에 아래와 같은 부분이 보인다면

    libJavaplugin_oji.so -> usr/lib/jvm/Java-1.5.0-Sun-1.5.0.09/jre/plugin/i386/ns7/libJavaplugin_oji.so


    아무 이상이 없는 것이다. 혹시 없다면 아래와 같이 직접 링크를 만들어 준다.

    cd /usr/lib/mozilla/plugins
    ln -s /usr/lib/jvm/Java-1.6.0-Sun-1.6.0.02/jre/plugin/i386/ns7/libJavaplugin_oji.so ./


    마지막으로 한 가지 첨언한다면 혹시나 초보자의 경우에는 Java-1.6.0-Sun-compat-1.6.0.02-1jpp.i586.rpm가 만든 여러 링크들은 가급적 직접 수정하지 않는 것이 좋을 듯하다. 만약 수정해야 할 필요가 있을 때에는 패키지를 제거하거나 재설치하는 것이 아마 나을 듯.

    ------------
    References
    CCL Sun Java Development Kit on FC6. <http://ccl.net/cca/software/SOURCES/JAVA/JSDK-1.5/index.shtml>
    [Jpackage] Installation. <http://www.jpackage.org/installation.php>

    Posted by 1010
    01.JAVA/Java2008. 7. 11. 17:59
    반응형

    /**
     *
     */
    package com.sbdc.util;

    import java.text.DecimalFormat;
    import java.text.ParsePosition;
    import java.text.SimpleDateFormat;
    import java.util.*;
    import java.io.*;

    /**
     * @author jchhkr
     *
     */

    public class EtcUtil {
     
     public String checkNull(String pStr){
      if(pStr == null || "NULL".equals(pStr.toUpperCase()))
       return "";
      else
       return pStr;
     }
     
     public String checkNull(String pStr, String retStr){
      if(pStr == null || "NULL".equals(pStr.toUpperCase()))
       return retStr;
      else
       return pStr;
     }
     
     public int checkNull(String pStr, int pInt){
      if(pStr == null || "".equals(pStr))
       return pInt;
      else
       return Integer.parseInt(pStr);
     }
     
     public float checkNull(String pStr, float pInt){
      if(pStr == null)
       return pInt;
      else
       return Float.parseFloat(pStr);
     }  
     
     public String getFomatDate(String strType, String strDate){
      String delim = "";
     
      if("1".equals(strType))
       delim = "-";
      else if("2".equals(strType))
       delim = ".";
      else if("3".equals(strType))
       delim = "/";

      if(strDate == null || "".equals(strDate)){
       return "";
      }else{
       if(strDate.length() == 8){
        return strDate.substring(0, 4) + delim + strDate.substring(4, 6) + delim + strDate.substring(6, 8);
       }else{
        return strDate;
       }
      }
     }

     // 로그파일 작성
     public void writeLog(String who, String msg, String sql){
      String LogDir = "D:/web_root/sbdc/log";

      String writeStr = "";
      writeStr = getTime() + " | " + who + " | " + msg;

      //파일이 없을 경우 생성
      String fileName = LogDir + "/sbdc_" +
            getYear() +  getMonth() + getDay() + ".log";
      try{
       makeFile(fileName);
       
       File file = new File(fileName);
       RandomAccessFile randomaccessfile = new RandomAccessFile(file, "rw");
       
       long i = randomaccessfile.length();
       randomaccessfile.seek(i);
       randomaccessfile.write(writeStr.getBytes());
       randomaccessfile.write("\n".getBytes());
       
       randomaccessfile.close();
     
      }catch(Exception e){
       System.out.println("Write Log Error :::: " + e.toString());
      }
     }
     
     public void makeFile(String fileName) throws Exception{
      File file = new File(fileName);
      if(!file.isFile()){
       file.createNewFile();
      }
     }
     
     //날짜와 시간 가져오기
     public static String getYear(){
      Calendar calendar = Calendar.getInstance();
      return Integer.toString(calendar.get(Calendar.YEAR));
     }
     
     //현재 월 가져오기
      public static String getMonth(){
      Calendar now = Calendar.getInstance();
      int monthN  = now.get(Calendar.MONTH)+1;
      String MON  = (monthN<10)? "0"+Integer.toString(monthN):Integer.toString(monthN) ;
     
      return MON;
      }
     
     //현재 일자 가져오기
     public static String getDay(){
      Calendar now = Calendar.getInstance();
      int dayN     = now.get(Calendar.DAY_OF_MONTH);
      if(dayN <10){
          return '0' + Integer.toString(dayN);
      }
      return Integer.toString(dayN);
     }
     
     public static String getDate(){ //년-월-일
      java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("yyyy-MM-dd");
      return  formatter.format(new java.util.Date());
     }
     public static String getTime(){ //년-월-일 시:분:초
      java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
      return  formatter.format(new java.util.Date());
     }
     public static String getTime2(){ //시:분:초
      java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("HHmmss");
      return  formatter.format(new java.util.Date());
     }
     public static int getDateNum(){
      java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("yyyyMMdd");
      return  Integer.parseInt(formatter.format(new java.util.Date()));
     }
     
     //한달전 일자 가져오기, sDay:현재일자 sMM:개월수(1은 1개월)
     public String getLastMonth() {
      Calendar cal = new GregorianCalendar();
     
      String sDay = getTime().substring(0,10);
      String sMM = "1";
     
      SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
      Date d = df.parse(sDay, new ParsePosition(0));
     
      cal.setTime(d);
      cal.add(Calendar.MONTH, -Integer.parseInt(sMM));
     
      return df.format(cal.getTime());
     }
     
     // 한달후 일자 가져오기, sDay:현재일자 sMM:개월수(1은 1개월)
     public String getNextMonth() {
      Calendar cal = new GregorianCalendar();
     
      String sDay = getTime().substring(0,10);
      String sMM = "1";
     
      SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
      Date d = df.parse(sDay, new ParsePosition(0));
     
      cal.setTime(d);
      cal.add(Calendar.MONTH, Integer.parseInt(sMM));
     
      return df.format(cal.getTime());
     }
     
     // 어제 일자 가져오기, sDay:현재일자 sMM:일수(1은 1일)
     public String getLastDate() {
      Calendar cal = new GregorianCalendar();
     
      String sDay = getTime().substring(0,10);
      String sMM = "1";
     
      SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
      Date d = df.parse(sDay, new ParsePosition(0));
     
      cal.setTime(d);
      cal.add(Calendar.DATE, -Integer.parseInt(sMM));
     
      return df.format(cal.getTime());
     }
     
     //두 날짜 차이값 비교, sDay:일자1 pDay:일자2
     public long getDiffDate(String day1, String day2) {
     
      long retVal = 0;
      String sDay = day1;
      String pDay = day2;
     
      SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
     
      Date d1 = df.parse(sDay, new ParsePosition(0));
      Date d2 = df.parse(pDay, new ParsePosition(0));
     
      retVal = (d1.getTime() - d2.getTime()) / (1000*60*60*24);
       
      return retVal;
     }
     /**
        * 설명   한글코드처리
        * @param     --String s
        * @return    --String
        * @exception
        */

      public String convToKo(String s){
       String retStr = "";
        try{
         if(s != null){
          retStr = (new String(s.getBytes("8859_1"),"KSC5601"));
         }
        }catch (Exception e){
         retStr = "";
        }
       
        return retStr;
      }
     
      // 파일명변경
     public void setFilerename(String path, String filename_old, String filename_new){
      //파일명 변경..
      File ff = new File(path+"/"+filename_old);
      if(ff.exists()){
       File fileRename = new File(path+"/"+filename_new);
     
       ff.renameTo(fileRename);
      }
     }
     
     // 특수문자에 대해 HTML 형태로 변환
     public String convToDB(String str) {
     
      String tmpStr = "";
     
      if(str == null){
       str = "";
      }
     
      tmpStr = str.replaceAll("&quot;",  "\"");
      tmpStr = tmpStr.replaceAll("&lt;",  "<");
      tmpStr = tmpStr.replaceAll("&gt;",  ">");
      tmpStr = tmpStr.replaceAll("&nbsp;",  " ");
      tmpStr = tmpStr.replaceAll("&amp;",  "&");
     
      return tmpStr;
     }
     
     public String convToHtml(String str) {
     
      String tmpStr = "";
     
      if(str == null){
       str = "";
      }
     
      tmpStr = str.replaceAll("\"", "&quot;");
      tmpStr = tmpStr.replaceAll("<", "&lt;");
      tmpStr = tmpStr.replaceAll(">", "&gt;");
      tmpStr = tmpStr.replaceAll(" ", "&nbsp;");
     
      return tmpStr;
     }
     
     //파일 사이즈 가져오기
     public String getFileSize(File file){
      if(file.exists())
       return Long.toString(file.length());
      else
       return "0";
     }
     
     //파일 확장자 가져오기
     public String getFileExt(String filenm){
      if(!"".equals(filenm))
       return filenm.substring(filenm.lastIndexOf(".")+1);
      else
       return "";  
     }
     
     //지정된 글자수를 초과한 문자열을 대체문자로 교체
     public String getCutUTFString(String s, int len, String tail){
      if (s == null)
       return null;
     
      int srcLen = s.getBytes().length;
      if (srcLen < len)
       return s;
      String tmpTail = tail;
     
      if (tail == null)
       tmpTail = "";
      int tailLen = tmpTail.getBytes().length;
     
      if (tailLen > len)
       return "";
      char a;
      int i = 0;
      int realLen = 0;
     
      for (i = 0; i < len - tailLen && realLen < len - tailLen; i++) {
       a = s.charAt(i);
       if ((a & 0xFF00) == 0)
        realLen += 1;
       else
        realLen += 2;
      }
     
      while (s.substring(0, i).getBytes().length > len - tailLen) {
       i--;
      }
      return s.substring(0, i) + tmpTail;
     }
     
     /**
      * 스트링 자르기
      * 지정한 정수의 개수 만큼 빈칸(" ")을 스트링을 구한다.
      * 절단된 String의 바이트 수가 자를 바이트 개수를 넘지 않도록 한다.
      *
      * @param <str>원본 String
      * @param <int>자를 바이트 개수
      * @param <char>+1 or -1
      * @return <String> 절단된 String
      */
     public String cutString(String str, int length, char type)
     {
         byte[] bytes = str.getBytes();
         int len = bytes.length;
         int counter = 0;

         if(length >= len)
         {
             StringBuffer sb = new StringBuffer();
             sb.append(str);

             for(int i=0;i<length-len;i++) sb.append(' ');
             return sb.toString();
         }

         for(int i=length-1; i>=0; i--)
         {
             if(((int)bytes[i] & 0x80) != 0) counter++;
         }

         String result = null;

         if(type == '+') result = new String(bytes, 0, length + (counter % 2));
         else if(type == '-') result = new String(bytes, 0, length - (counter % 2));
         else result = new String(bytes, 0, length - (counter % 2));
        
         return result + "..";
     }
     
     public String covToDate(String str) {
     
      String tmpStr = "";
      String tmpArray[] = new String[3];
      String retStr = "";
     
      if(!"".equals(str) && !"null".equals(str) && str != null) {
       
       tmpStr = str.replaceAll(" ", "");
       tmpStr = tmpStr.replaceAll("[.]", "-");
       tmpArray = tmpStr.split("-");
       
       if(tmpArray[0].length() < 4) {
        tmpArray[0] = "20" + tmpArray[0];
       }
       
       if(tmpArray[1].length() < 2) {
        tmpArray[1] = "0" + tmpArray[1];
       }
       
       if(tmpArray[2].length() < 2) {
        tmpArray[2] = "0" + tmpArray[2];
       }
       
       retStr = tmpArray[0] + "-" + tmpArray[1] + "-" + tmpArray[2];
      }
      return retStr;
     }
     
     //원본 문자를 구분자로 분해하여 배열을 리턴한다.
     //전화번호, 팩스의 경우 - 구분으로 3개의 배열값을 갖도록 할 경우 사용
     public String[] getSepStringArr(String tarVal, String sepVal, int arrLen){
      String[] retStrArr = new String[arrLen];
      String[] tarStrArr = tarVal.split(sepVal);
     
      for(int i=0; i<arrLen; i++){
       if(i>=tarStrArr.length){
        retStrArr[i] = "";
       }else{
        retStrArr[i] = tarStrArr[i];
       }
      }
      return retStrArr;
     }
     
     /**
      * 문자열의 특수문자장 줄바꿈 Escape 문자열을 HTML 문서의 줄바꿈 태그("&lt;br/&gt;")로 변경
      * 2007-07-16 김형섭 추가
      *
      * @param <String>input 변경할 문자열
      * @return <String>"\r\n"과 "\r"이 "&lt;br/&gt;"로 치환된 문자열
      *
      */
     public String toLineBreak(String input)
     {
      return input.replaceAll("\r\n", "<br/>").replaceAll("\r", "<br/>");
     }
     
     public String toLine(String input)
     {
      return input.replaceAll("<br/>", "\r\n").replaceAll("<br/>", "\r");
     }
     
     /**
      * 퍼센트를 계산
      * 2007-07-17 김형섭 추가
      *
      * @param <int>decimalCount 소수점 자릿수
      * @param <int>number 대상값
      * @param <int>sum 합계값
      * @return <float>퍼센트값
      *
      */
     public float getPercent(int decimalCount, int number, int sum)
     {
      return this.getPercent(decimalCount, (float)number, (float)sum);
     }

     /**
      * 퍼센트를 계산
      * 2007-07-17 김형섭 추가
      *
      * @param <int>decimalCount 소수점 자릿수
      * @param <int>number 대상값
      * @param <float>sum 합계값
      * @return <float>퍼센트값
      *
      */
     public float getPercent(int decimalCount, int number, float sum)
     {
      return this.getPercent(decimalCount, (float)number, sum);
     }

     /**
      * 퍼센트를 계산
      * 2007-07-17 김형섭 추가
      *
      * @param <int>decimalCount 소수점 자릿수
      * @param <float>number 대상값
      * @param <int>sum 합계값
      * @return <float>퍼센트값
      *
      */
     public float getPercent(int decimalCount, float number, int sum)
     {
      return this.getPercent(decimalCount, number, (float)sum);
     }

     /**
      * 퍼센트를 계산
      * 2007-07-17 김형섭 추가
      *
      * @param <int>decimalCount 소수점 자릿수
      * @param <float>number 대상값
      * @param <float>sum 합계값
      * @return <float>퍼센트값
      *
      */
     public float getPercent(int decimalCount, float number, float sum)
     {
         float devidedNumber = 0f;

         if(sum != (float)0) devidedNumber = number/sum;

      return formatDecimal(decimalCount, devidedNumber * 100f);
     }

     /**
      * 소수점 자릿수를 지정하여 변경
      * 2007-07-17 김형섭 추가
      *
      * @param <int>decimalCount 소수점 자릿수
      * @param <float>number 대상값
      * @return <float>변경된값
      *
      */
     public float formatDecimal(int decimalCount, float number)
     {
      String pattern = "#.";
     
      for(int i=0; i<decimalCount; i++)
      {
       pattern+= "0";
      }
     
      DecimalFormat dformat = new DecimalFormat(pattern);
      return Double.valueOf(dformat.format(number)).floatValue();
     }
     
     /**
      * 소수점 자릿수를 지정하여 변경
      * 2007-07-17 김형섭 추가
      *
      * @param <int>decimalCount 소수점 자릿수
      * @param <double>number 대상값
      * @return <float>변경된값
      *
      */
     public float formatDecimal(int decimalCount, double number)
     {
      String pattern = "#.";
     
      for(int i=0; i<decimalCount; i++)
      {
       pattern+= "0";
      }
     
      DecimalFormat dformat = new DecimalFormat(pattern);
      return Double.valueOf(dformat.format(number)).floatValue();
     }
     
     /**
      * 숫자를 받아 3자리마다 ,를 넣어 리턴
      * 2007-07-27 정상욱 추가
      *
      * @param <String>변경할 수
      * @return <String>변경된 값
      */

     public String convToMoney(String strNumber) {
      String Money = "";
      if (strNumber == null) {
       Money = "";
      } else {
       try{
        float floatMoney = Float.parseFloat(strNumber);
       
        java.text.DecimalFormat tstFormat = new java.text.DecimalFormat("#,###");
       
        Money = tstFormat.format(floatMoney);
       }catch(Exception e){
        Money = strNumber;
       }
      }
     
      return Money;
     }
     
     public String padStr (String orgStr, String direction, String repStr, int len) {
      orgStr = checkNull(orgStr, "");
      for(int i = 1; i <= len; i++){
       if("L".equals(direction))
        orgStr = repStr + orgStr;
       else
        orgStr = orgStr + repStr;
      }
     
      return orgStr;
     }

        /**
      * 현재의 날짜를 스트링으로 리턴
      * 2007/09/13 추가 (김형섭)
      *
         * @param <String>format 날짜포맷 (ex-yyyyMMdd)
      * @return <String>날짜
      */
        public String getCurrentDate(String format)
        {
            SimpleDateFormat formatter = new SimpleDateFormat(format, new Locale("ko", "KOREA"));

            return formatter.format(new Date());
        }

        /**
      * 지정한 자리수만큼 0을 채움
      * 2007/09/13 추가 (김형섭)
      *
         * @param <int>sourceNumber 대상숫자
         * @param <int>formatLength 자리수
      * @return <String>날짜
      */
        public String formatZeroString(int sourceNumber, int formatLength)
        {
            String sourceString = Integer.toString(sourceNumber);
            String result = "";

            for(int i=sourceString.length(); i<formatLength; i++) result+= '0';

            return result + sourceString;
        }
    }


     

    Posted by 1010
    01.JAVA/Java2008. 7. 11. 17:15
    반응형


    /**
      *
      * @param input
      *            체크할 값
      *
      * 한글 , 영어 , 특수 기호 값을 체크
      */
     public static void testChar(String input){
      boolean test = false;
      char[] charArray=input.toCharArray();


      for (int j=0; j<charArray.length; j++) {
       System.out.println(" 0x"+Integer.toHexString((int)charArray[j]));

       if (charArray[j] >= 'A' && charArray[j] <= 'Z' || charArray[j] >= 'a' && charArray[j] <= 'z'){
        System.out.println(charArray[j]+"=>"+"(English)");

       }else if (charArray[j]>='\uAC00' && charArray[j]<='\uD7A3'){
        System.out.print(charArray[j]+" =>"+"(한글)");

       }else if (
         (charArray[j]>='!' && charArray[j]<='/')  ||
         (charArray[j]>='[' && charArray[j]<=0x60)  ||
        
         (charArray[j]>='{' && charArray[j]<='~') ||
         (charArray[j]>=':' && charArray[j]<='@')
       ){
        System.out.println(charArray[j]+" =>"+"(특수 문자)");

       }else if (charArray[j]>='0' && charArray[j]<='9'){
        System.out.println(charArray[j]+"=>"+"(숫자)");

       }else {
        test = false;
        for (int jnx=0; jnx<ChoSung.length; jnx++){
         if(charArray[j]== ChoSung[jnx]){
          System.out.println(ChoSung[jnx]+ "초성");
          test = true;
          break;
         }
        }
        for (int jnx=0; test == false && jnx<JwungSung.length; jnx++){
         if(charArray[j]== JwungSung[jnx]){
          System.out.println(JwungSung[jnx] + " 중성 ");
          test = true;
          break;
         }
        }
        for (int jnx=0; test == false && jnx<JongSung.length; jnx++){
         if(charArray[j]== JongSung[jnx]){
          System.out.println(JongSung[jnx] + "종성");
          test = true;
          break;
         }
        }
       }
       System.out.println("");

      }

     }

    Posted by 1010
    01.JAVA/Java2008. 7. 11. 17:15
    반응형

    /  ㄱ ㄲ ㄴ ㄷ ㄸ ㄹ ㅁ ㅂ ㅃ ㅅ ㅆ ㅇ ㅈ ㅉ ㅊ ㅋ ㅌ ㅍ ㅎ
       static char[] ChoSung   = { 0x3131, 0x3132, 0x3134, 0x3137, 0x3138, 0x3139, 0x3141, 0x3142, 0x3143, 0x3145, 0x3146, 0x3147, 0x3148, 0x3149, 0x314a, 0x314b, 0x314c, 0x314d, 0x314e };
       // ㅏ ㅐ ㅑ ㅒ ㅓ ㅔ ㅕ ㅖ ㅗ ㅘ ㅙ ㅚ ㅛ ㅜ ㅝ ㅞ ㅟ ㅠ ㅡ ㅢ ㅣ
       static char[] JwungSung = { 0x314f, 0x3150, 0x3151, 0x3152, 0x3153, 0x3154, 0x3155, 0x3156, 0x3157, 0x3158, 0x3159, 0x315a, 0x315b, 0x315c, 0x315d, 0x315e, 0x315f, 0x3160, 0x3161, 0x3162, 0x3163 };
       // ㄱ ㄲ ㄳ ㄴ ㄵ ㄶ ㄷ ㄹ ㄺ ㄻ ㄼ ㄽ ㄾ ㄿ ㅀ ㅁ ㅂ ㅄ ㅅ ㅆ ㅇ ㅈ ㅊ ㅋ ㅌ ㅍ ㅎ
       static char[] JongSung  = { 0, 0x3131, 0x3132, 0x3133, 0x3134, 0x3135, 0x3136, 0x3137, 0x3139, 0x313a, 0x313b, 0x313c, 0x313d, 0x313e, 0x313f, 0x3140, 0x3141, 0x3142, 0x3144, 0x3145, 0x3146, 0x3147, 0x3148, 0x314a, 0x314b, 0x314c, 0x314d, 0x314e };
    Posted by 1010
    01.JAVA/Java2008. 7. 11. 10:48
    반응형

     

    자바에서 각 문자는 내부적으로 유니코드값으로 저장되므로
    char의 값을 유니코드 테이블과 비교해보면 이것이 영어인지 한글인지 혹은 한자인지 알수 있을 것입니다.
    (질문은 단어가 한글인지 영문인지를 묻는데
    단어는 물론 한영이 섞여 있을 수도 있고 자바 내부에서는
    유니코드로 처리되므로 큰 의미가 없을 것입니다.


    // charTest.java

    class charTest {
    	public static void main(String args[]) {
    		for (int i=0;i<args.length;i++) {
    			System.out.println("args["+i+"]="+args[i]);	
    			char[] charArray=args[i].toCharArray();
    			for (int j=0; j<charArray.length; j++) {
    				System.out.print(" 0x"+Integer.toHexString((int)charArray[j]));
    				if (charArray[j]>='A' && charArray[j]<='z')
    					System.out.print("(English)");
    				else if (charArray[j]>='\uAC00' && charArray[j]<='\uD7A3')
    					System.out.print("(한글)");
    			}
    			System.out.println("");
    		}
    	}
    }

    실행 예
    C:\javaworks>java charTest AbZz 가나다라한글
    args[0]=AbZz
    0x41(English) 0x62(English) 0x5a(English) 0x7a(English)
    args[1]=가나다라한글
    0xac00(한글) 0xb098(한글) 0xb2e4(한글) 0xb77c(한글) 0xd55c(한글) 0xae00(한글)

    Posted by 1010
    01.JAVA/Java2008. 7. 8. 18:19
    반응형
    Posted by 1010
    01.JAVA/Java2008. 7. 8. 17:16
    반응형
    Code sample
    Java IDL Code Samples
     
    IDL Code Samples

    Java IDL is a CORBA-compliant technology for distributed objects that lets objects interact regardless of whether they are written in the Java programming language or another language.

    CORBA Hello World Example File Transfer Example Portable Object Adapter Example Servlets Example
    Posted by 1010
    01.JAVA/Java2008. 7. 7. 17:21
    반응형
    ★ MultipartRequest를 이용하여 업로드구현하기

    Last Modified 2002/05/26
    Written by hsboy
    ReadCount 2250


    * 강좌를 시작하기전에....

    - 기존의 jspSmartUpload를 대체해 가고 있는 MultipartRequest에 대한 간단한 사용법에 대해 강의 합니다.
    JSP만을 사용하는 강좌이며 Beans, Servlet은 다루지 않습니다.

    - MultipartRequest는 COS 패키지에 포함되어 있는 파일 업로드 컴포넌트 입니다.

    - COS 에서는 한글등(non-Latin-1)의 언어를 지원하지 않았었습니다. 그러한 이유로 이아스(이창신)님 께서 배포한 COSI(COS International) 를 주로 사용 하였으나, 이아스님의 노력에 힘입어 2002년 5월 9일 자 COS에서는 한글을 포함한 non-Latin-1 계열의 언어를 지원하게 되었습니다. 근 2년간의 국제화를 위한 투쟁이 비로서 결실을 맺는 순간이었습니다.
    이에 따라 본 강좌의 내용도 COS 맞추어 약간의 수정을 했습니다.

    COS 공식 사이트 : http://www.servlets.com/cos/index.html


    * MultipartRequest는....

    필자는 기존에 jspSmartUpload를 주로 사용하여 업로드를 구현했었다. 하지만 jspSmartUpload는 로직자체에 상당한 문제점(업로드된 파일을 메모리에 올리고 작업하여 그로인해 파생되는 문제점들)이 있음이 밝혀 졌고, 그로인해 jspSmartUpload의 사용은 급속히 줄어 들었다.

    사실 jspSmartUpload에서는 편리한 많은 메소드를 지원해주고 있어 MultipartRequest를 사용하는것 보다 훨씬 쉽게 원하는 기능을 구현 할수 있는 것이 사실이다. 하지만 jspSmartUpload는 문제점이 발견 되었으므로 가능한사용을 자제하는 것이 좋겠다.

    MultipartRequest는 아주 간단한 메소드를 몇개 지원한다. 하지만 이 메소드들 만으로도 왠만한 기능은 전부 구현이 가능하니 실망하지 말자. getFile() 메소드를 이용하면 java.io.File 객체를 얻어 낼수 있으니 이를 이용하면 될것이다.


    * 설치하기

    MultipartRequest는 oreilly에서 배포하며, http://www.servlets.com/cos/index.html에서 다운로드 받아도 되고, 필자의 홈페이지(http://aboutjsp.com)의 자료실에도 업로드를 해놓았으니 다운받아 사용해 보기 바란다.

    설치 하는 방법은 다운로드 받아서 압축을 푼뒤, classes 디렉토리 아래를 톰캣의 classes 디렉토리에 통째로 복사한다. (예.ROOT/WEB-INF/classes) 혹은 cos.jar를 lib에 복사해도 된다.

    COS 패키지기에는 MultipartRequest 말고도 유용한 많은 클래스들이 많이 존재하므로, 여기의 API문서를 참고하여 사용하기 바란다


    * 업로드 구현

    간단한 예제를 통해서 알아 보도록 하자.

    wirte.htm
    <html> <body> <form action="up.jsp" enctype="multipart/form-data" method="post"> 이름 : <input type="text" name="userName"> <br /> 파일 : <input type="file" name="upfile"> <input type="submit" value="Upload"> </form> <div style="margin:0; padding:0; border:none; background:none; float:none; clear:none; z-index:0"></div> <script type="text/javascript" src="https://tistory1.daumcdn.net/tistory_admin/userblog/userblog-fb75728c77dea064afed4dc08526d25217180e4d/static/script/common.js"></script> <script type="text/javascript">window.roosevelt_params_queue = window.roosevelt_params_queue || [{channel_id: 'dk', channel_label: '{tistory}'}]</script> <script type="text/javascript" src="//t1.daumcdn.net/midas/rt/dk_bt/roosevelt_dk_bt.js" async="async"></script> <script>window.tiara = {"svcDomain":"user.tistory.com","section":"기타","trackPage":"글뷰_보기","page":"글뷰","key":"218144","customProps":{"userId":"0","blogId":"218144","entryId":"null","role":"guest","trackPage":"글뷰_보기","filterTarget":false},"entry":null,"kakaoAppKey":"3e6ddd834b023f24221217e370daed18","appUserId":"null"}</script> <script type="module" src="https://t1.daumcdn.net/tistory_admin/frontend/tiara/v1.0.5/index.js"></script> <script src="https://t1.daumcdn.net/tistory_admin/frontend/tiara/v1.0.5/polyfills-legacy.js" nomodule="true" defer="true"></script> <script src="https://t1.daumcdn.net/tistory_admin/frontend/tiara/v1.0.5/index-legacy.js" nomodule="true" defer="true"></script> </body> </html>

    up.jsp
    <%@ page contentType="text/html;charset=euc-kr" 
    %><%@ page import="com.oreilly.servlet.MultipartRequest,
                       com.oreilly.servlet.multipart.DefaultFileRenamePolicy,
                       java.util.*" 
    %><%
     String savePath="/usr/local/tomcat/webapps/ROOT/test/upload"; // 저장할 디렉토리 (절대경로)
    
     int sizeLimit = 5 * 1024 * 1024 ; // 5메가까지 제한 넘어서면 예외발생
    
     try{
    
    	MultipartRequest multi=new MultipartRequest(request, savePath, sizeLimit, new DefaultFileRenamePolicy());
     	Enumeration formNames=multi.getFileNames();  // 폼의 이름 반환
    	String formName=(String)formNames.nextElement(); // 자료가 많을 경우엔 while 문을 사용
    	String fileName=multi.getFilesystemName(formName); // 파일의 이름 얻기
    
    	if(fileName == null) {   // 파일이 업로드 되지 않았을때
    		out.print("파일 업로드 되지 않았음");
    	} else {  // 파일이 업로드 되었을때
    		fileName=new String(fileName.getBytes("8859_1"),"euc-kr"); // 한글인코딩 - 브라우져에 출력
    		out.print("User Name : " + multi.getParameter("userName") + "<BR>");
    		out.print("Form Name : " + formName + "<BR>");
    		out.print("File Name  : " + fileName);
    	} // end if
    
     } catch(Exception e) {
    	out.print("예외 상황 발생..! ");
     } 
    %>
    				

    위의 예제 소스를 보면 대부분이 이해가 잘 갈것이라 생각되지만.. 하나씩 살펴 보도록 하겠다. 우선 write.htm 에서는 폼에서 method="post" 형식으로 해야 하며 ecntype="multipart/form-data" 를 꼭 붙여 주어야 한다.

    다음으로 up.jsp를 하나 하나 살펴 보자. MultipartRequest 클래스를 import 하고, java.util.* 는Enumeration 객체를 사용하기 위해서 import 한다..

    savePath 는 저장될 실제 디렉토리(시스템상의 절대 경로)를 적으면 된다. sizeLimit 에서는 제한 용량을 셋팅하는데, 위와같은방법으로 메가바이트 단위로 지정할 수 있다.

    그 다음줄에서는 MultipartRequest 객체가 생성됨과 동시에 업로드가 이루어져 지정한 디렉토리에 저장된다. 이때 MultipartRequest의 여러 생성자들중 하나를 이용하면 되는데, 기존에는 새성자로 한글 "euc-kr"을 줬어야 했는데, 어쩐일인지 이제는 주지 않아아 한글 이름의 파일이 잘 저장되느는 것을 볼수 있다. 또한 가장 오른쪽의 'new DefaultFileRenamePolicy' 는 는 파일 이름 중복처리에 관한 것으로 넣을수도 있고, 뺄수도 있다. 필요하지 않다고 생각된다면 빼버리도록 하자.

    그아래에 if 문을 보면, 파일이 업로드 되었을때와 업로드 되지 않았을때의 처리를 나누어서 할수 있도록 하고 있다.

    if 문 위의 3라인은 파일의 이름을 얻기위한 로직으로 Enumeration 객체로 받은 폼의 이름을 이용하고 있다. 만약 폼이 여러개가 있을 경우엔 적절한 자료형을 이용하여 폼의 이름을 통해서 파일의 이름들을 얻어 낼수 있을 것이다. 만약 파일 업로드를 Beans로 구현할 경우엔 반드시 이러한 로직을(Enumeration 객체를 이용한 loop구문)사용해야 할 것이다.

    사실 위의 예제에서는 굳이 Enumerration 객체를 가지고 구현할 필요는 없지만, 해당 메소드의 사용법을 보여주기 위해서 사용하였다. 이러한 방법을 사용하지 않을 경우에는 if 위에 3라인을 삭제하고 아래의 내용을 추가 하면다.

    String fileName=multi.getFilesystemName("upfile");


    * FileRenamePolicy 에 관해서...

    이번 버젼의 MultipartRequest 에서 부터는 파일 중복처리 인터페이스가 추가 되었고, 위의 예제 소스는 그러한 내용이 반영되어있다. DefaultFileRenamePolicy는 FileRenamePolicy Interface 를 구현한 것으로, 중복된 파일 이름뒤에 숫자를 붙여 주고 있다. ( abcd.zip , abcd1.zip, abcd2.zip, abcd3.zip ....... )

    DefaultFileRenamePolicy Class를 바탕으로 새로운 RenamePolicy class 를 만들면 자신이 원하는 FileRenamePolicy 를 적용할수 있다.

    또한 getFilesystemName()메소드를 이용하여 변경된 파일 이름을 얻을수 있고, getOriginalFileName()메소드는 변경되기 이전의 파일이름을 넘겨준다.


    * multi.getParameter()

    write.htm 에서 서정한바와 같이 enctype="multipart/form-data" 로 지정하면, request.getParameter()로는 아무러 값도 받아 올수가 없게된다. 그러한 이유로 대부분의 파일업로드 컴포넌트에서는 getParameter() 메소드를 지원하는데, MultipartRequest에서도 이러한 메소드를 지원한다. 지원하는 메소드는 아래와 같으며, 사용법은 request.getParameter() 등과 동일하다.

    String getParameter(String name)
    Enumeration getParameterNames()
    String[] getParameterValues(String name)


    * 한글관련 문제 처리법

    MultipartRequest multi=new MultipartRequest(request, savePath, sizeLimit, new DefaultFileRenamePolicy());

    위를 아래와 같이 수정한다.

    MultipartRequest multi=new MultipartRequest(request, savePath, sizeLimit, "euc-kr", new DefaultFileRenamePolicy());

    "euc-kr" 부분엔 "ksc5601", "ms949" 등 자신의 환경에 알맞는 캐릭터셋을 넣어 주면 된다.

    각 메소드들에 대한 자세한 사용법은 아래의 API문서를 참고 하기 바란다.

    http://aboutjsp.com/docs/cos/



    * 관련사이트
    http://www.servlets.com/cos/
       COS 공식 사이트

    저자 : 이선재(hsboy)
    http://www.aboutjsp.com
    다른곳에 올리실 때는 반드시 출처를 명시해 주시기 바라며 되도록 이면 링크를 걸어 주시기 바랍니다.

    Posted by 1010
    01.JAVA/Java2008. 7. 7. 15:40
    반응형
     
    정말 자바 웹 프로그래머가 알고있어야 할 기본입니다.
    굉장히 방대한 분량이 간략히 정리되어있습니다.
     
    =================================================================
     
    마소 2005년 1월호 기고
    1 제목
    2 발문
    3 필자 소개
    4 본문
    4.1 서론, 어떻게 공부할 것인가
    4.2 본론
    4.2.1 web.xml
    4.2.2 예외 처리
    4.2.3 로깅
    4.2.4 예외 추적
    4.2.5 한글 문제
    4.2.6 URL 인코드
    4.2.7 클래스패스의 리소스 사용법
    4.2.8 서블릿/액션 멤버 변수 공유 문제
    4.3 결론, 생각하기
    4.4 참조

    1 제목 #

    자바 웹 프로그래머의 기본

    2 발문 #

    프로그래밍 초보자가 능히 한 사람 몫을 할 정도로, 혼자 코딩하도록 내버려둬도 다른 사람들이 불안에 떨지 않을 만큼 성장하는 가장 빠른 방법은 무엇일까? 디자인 패턴을 공부하고 최신 기술을 익히고 실전 프로그래밍을 많이 해보는 것? 그것도 물론 중요하다. 그러나, 이보다 훨씬 더 중요한 것은 기초를 다지는 것이다. 슬램덩크에서 강백호는 농구부 입단 후 2주일 간 드리블 연습만 했고 이것이 그가 빠른 시간 안에 한 사람 몫을 해내는데 밑거름이 되었다. 잠시 더블 클러치 연습은 멈추고 드리블을 해보자. 복잡한 이론, 어려운 신기술은 잠시 접어두고 프로그래머로서의 기본을 재점검해보자.

    3 필자 소개 #

    박영록 refactorer@naver.com code for human, not for programmer. 인간다운 프로그래머, 게으른 프로그래머를 지향한다. 현재 NHN에서 프레임웍 개발과 서버 관리를 담당하고 있다.

    4 본문 #

    4.1 서론, 어떻게 공부할 것인가 #

    4년 전, 학교에서 어느 벤처 경영인의 강연을 들은 적이 있다. 미국에서 벤처를 시작해서 어느 정도의 성공을 거둔 기업가였다. 그는 강연 내내 기본을 강조했다. 미국과 한국의 기업 문화의 차이를 비교하면서 미국의 벤처들은 대체로 경영인으로서의 기본적으로 지켜야할 것들을 잘 지키는 반면 한국의 벤처는 기본적인 것들을 제대로 지키지 못하고 그로 인해 실패하는 경우가 많다고 했다. 벤처 붐이 일 때 수많은 학생 벤처가 경영에 대한 무지로 가진 기술을 펼쳐보지도 못하고 망한 현상에 대해 벤처는 경영이며 경영을 하려면 경영에 대해 배워야하는 것은 기본인데 그 기본이 지켜지지 않았기 때문이라고 했다. 당시 부도덕한 벤처 기업가들의 행태가 사회적으로 논란이 되고 있었는데 이에 대해서는 사회인으로서의 기본적인 소양이 갖추어져 있지 않기 때문이라고 했다. 그는 모든 것을 기본이란 말 하나로 설명했다. 기본이 물론 성공의 충분조건은 아니다. 그러나, 기본을 지키지 않고는 성공할 수 없다. 어떤 분야든 이것은 예외가 없을 것이다.

    그렇다면 프로그래머, 그 중에서도 자바 웹 프로그래머의 기본은 무엇일까? 당연히 자바 언어에 대해서 잘 아는 것이다. 웹 프로그래밍이라는 것도 결국 사용하는 API가 다른 것 뿐, 좋은 자바 웹 프로그래머가 되려면 먼저 좋은 자바 프로그래머가 되어야한다. 너무도 당연한 말 같지만 현실은 그렇지 않다. 여러 자바 커뮤니티에 가보면 자바에 대한 정말 기본적인 질문들이 수도 없이 올라오며, 현업 프로그래머 중에도 기초가 부족한 사람이 너무나도 많다. 자바 프로그래머라면 자바에 관한 기본서 하나 정도는 마스터하고 시작하도록 하자. 자바 기본서들은 대체로 내용이 충실하므로 아무 거나 사도 나쁜 선택은 아닐 것이다. 그래도 추천이 필요하다면 Thinking in Java를 추천한다. 프로그래밍에 처음 입문하는 거라면 예제들을 직접 따라해보는 것도 좋을 것이다.

    자바에 익숙해졌다면 다음 단계는 웹 기술이다. 웹 프로그래밍의 기본은 웹과 관련된 스펙(Specification)에 대한 지식, 구체적으로 Servlet/JSP 스펙, HTTP 스펙(RFC 2068), HTML ?W3C 스펙 등이다. 이 스펙들에 대해 상세히 다 알 필요는 없지만 웹 프로그래밍에서 사용하는 API들이 어떤 스펙에 기반하고 있는지, 자세히 알고 싶으면 무엇을 찾아야하는지는 알아야한다. 공대생이 공학수학의 내용을 전부 알고 있을 필요는 없지만 미분방정식을 풀고 싶으면 어느 페이지를 찾아봐야하는지는 알고 있어야하는 것처럼 어떤 요구사항이 발생했을 때 그 요구사항을 구현하려면 어떤 스펙을 찾아봐야하는지 정도는 알고 있어야한다. 그리고 의외로 많은 웹 프로그래머들이 HTML, CSS에 익숙지 않은데 이 때문에 웹사이트의 브라우저 호환성이 떨어질 뿐만 아니라 지저분한 코드를 양산하게 된다. HTML 코드 역시 유지보수 대상이 되는 코드이며 자바 코드 못지 않게 깔끔하게 유지할 수 있어야함을 기억하자. 이를 위해서는 HTML과 CSS에 대해 상세히 알아둘 필요가 있다. XML은 이제 프로그래머의 기본이니 언급할 필요도 없을 것이다. XML 파일을 이용하는 것이 편하게 느껴질 정도가 되면 코드의 유연성을 높일 좋은 방법들을 많이 생각해낼 수 있을 것이다.

    스펙을 실제로 활용하는 것은 API(Application Programming Interface)를 통해서이다. Servlet/JSP API는 스펙과는 달리 실제로 API를 통해서 무엇을 할 수 있는지를 상세하게 알고 있어야한다. 이것은 비단 Servlet/JSP API 뿐 아니라 Java 기본 API, 각종 라이브러리의 API도 마찬가지다. 필자가 이제껏 자바에 관해 받아본 질문 중 대부분은 API 문서만 잘 들여다보면 해결되는 것이었다. API 문서를 자주 찾아보는 습관을 들이자. 리눅서들은 매뉴얼을 읽지 않고 질문하는 사람에게 RTFM(Read The Fucking Manual)이라는 대답을 해준다. 자바 역시 RTFM이 필요하다. ?J2EE 기본서를 하나 사서 보는 것도 좋을 것이다. ?J2EE 기본서에는 웹 관련 스펙 중 중요한 부분들, Servlet/JSP 스펙 및 API들이 잘 정리되어 있다. Java Server Programming, ?J2EE Edition 정도면 훌륭한 참고서가 될 것이다.

    이제부터 이런 기본적인 지식 중에 중요하지만 간과하기 쉬운 것들, 간단하지만 알면 도움이 되는 정보들, 자주 부딪히게 되는 고민들 등 몇 가지 작은 문제들을 짚어볼 것이다. 모두 기본 학습 과정을 잘 거쳤다면 자연스럽게 알 수 있는 내용들이다. 이런 하나하나의 지식들을 통해 자신에게 부족한 점을 되짚어볼 수 있는 계기를 마련할 수 있기를 바란다.

    4.2 본론 #

    4.2.1 web.xml #
    배치 서술자(deployment descriptor)라고 부르는 web.xml은 웹 프로젝트를 구성하는데 있어 필수적이면서 웹 애플리케이션의 동작을 여러 가지로 조정하는 역할을 한다. 스트러츠를 사용하는 경우도 스트러츠를 사용하기 위한 설정은 web.xml에 하게 되는데 그 설정들이 무슨 의미를 가지고 있는지 정도는 상식으로 알아두는 것이 좋을 것이다. 다음의 실제 스트러츠 설정 예제를 보자. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"><servlet> <servlet-name>action</servlet-name> <servlet-class> org.apache.struts.action.ActionServlet </servlet-class> <init-param> <param-name>config</param-name> <param-value> /WEB-INF/struts-config.xml </param-value> </init-param> <load-on-startup>1</load-on-startup></servlet><servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern></servlet-mapping></PRE>PHP, ASP 등의 다른 서버 사이드 스크립트나 JSP 페이지는 페이지를 호출하는 경로에 실제 스크립트 파일이 존재해야하지만 서블릿은 이와 달리 web.xml의 설정을 이용해서 URL을 특정 서블릿으로 매핑시킬 수 있다. 위의 설정은 호출된 URL을 스트러츠의 Action으로 매핑시키기 위한 설정이다. servlet 설정에서 action이라는 이름의 서블릿을 org.apache.struts.action.?ActionServlet 클래스로 등록하고 아래의 servlet-mapping 설정에서 *.do라는 URL로 호출된 페이지들을 action이라는 이름의 서블릿으로 매핑시킨다. url-pattern 값을 *.nhn으로 바꾼다면 *.nhn으로 호출된 요청들이 ?ActionServlet으로 매핑될 것이다. 스트러츠는 이 ?ActionServlet에서 요청을 각 Action으로 분기시켜준다. init-param은 서블릿을 초기화할 때 사용할 파라미터값이며 getInitParameter 메쏘드를 통해서 읽어올 수 있다. load-on-startup은 서블릿 엔진이 스타트될 때 로드될 우선 순위를 지정하는 값이다.

    인덱스 페이지를 지정하는 것도 web.xml에서 할 수 있다. 많은 웹사이트들이 구체적인 경로 지정 없이 도메인명까지만 써줘도 페이지를 표시한다. 이를테면 http://www.hangame.com으로 호출할 경우 다음과 같이 설정해두면 www.hangame.com의 /index.jsp를 호출하게 만들 수 있다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"><welcome-file-list> <welcome-file>index.jsp</welcome-file></welcome-file-list></PRE>태그명에서 짐작할 수 있듯이 인덱스 페이지는 여러 개를 둬서 순서대로 검색하게 할 수 있다. 예를 들어 index.html과 index.jsp가 순서대로 지정된다면 서블릿 엔진은 index.html이 있으면 index.html을 보여주고 없으면 index.jsp를 호출한다. 이것도 없으면 404 에러가 나거나 디렉토리 목록이 보이게 된다. 이 인덱스 페이지는 모든 경로에 대해서 동작한다. 위와 같은 설정의 경우 http://www.hangame.com/login/을 호출한다면 http://www.hangame.com/login/index.jsp를 찾게 되는 것이다. 이 설정은 사실 아파치 등의 웹서버에서도 해줄 수 있으나 보통 웹 서버에서는 인덱스 페이지가 실제 파일로 존재해야 보여줄 수 있는데 서블릿 엔진에서는 실제 파일로 존재하지 않고 서블릿 매핑으로 지정만 되어 있어도 보여줄 수 있다는 장점이 있다.

    접근 권한도 설정할 수 있다. 권한 체계가 간단한 웹 애플리케이션이라면 web.xml만으로도 충분한 권한 설정을 해줄 수 있다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"><security-constraint> <web-resource-collection> <web-resource-name>retail</web-resource-name> <url-pattern>/acme/retail/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>CONTRACTOR</role-name> <role-name>HOMEOWNER</role-name> </auth-constraint></security-constraint></PRE>위의 예는 서블릿 스펙 문서에 있는 예다. 이것의 의미는 GET이나 POST로 /retail/*와 같은 요청은 CONTRACTOR와 HOMEOWNER라는 role을 가진 사용자에게만 허락하겠다는 뜻이다. 이외의 사용자는 권한이 없다는 401 에러 페이지를 보게 된다. 이런 접근 제한 뿐 아니라 로그인 처리도 login-config 설정을 이용하면 가능하다. 실제 톰캣의 admin과 manager 애플리케이션은 이 설정을 이용해서 인증과 권한 처리를 한다. 자세한 스펙은 서블릿 스펙 문서에 정의되어 있으나 실제 활용하기엔 다소 부족한 감이 있고 톰캣의 실제 활용 예를 보는 것이 도움이 될 것이다. 이외에도 서블릿 필터 설정, 세션 설정, 리소스 설정 등 여러 가지 유용한 설정을 해줄 수 있고 공통적인 에외 처리를 위한 에러 페이지 설정도 가능하다. 에러 페이지 설정 부분은 이후 예외 처리에서 자세히 다룰 것이다.

    4.2.2 예외 처리 #
    자바의 강점 중 하나가 편리한 예외 처리 방식이다. C 언어 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리이다. 하지만 의외로 많은 자바 프로그래머들이 예외 처리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킨다. 기본이라고 할 수도 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대한 많은 고민이 필요하다. 특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹사이트 방문객을 위한 부분 두 가지를 모두 고려해야한다.

    먼저 프로그래머의 입장을 살펴보자. 예외가 발생하면 어디까지는 그냥 던지고 어디서 캐치하는 것이 좋을까? 자바의 예외는 자바 코드의 모든 영역에서 발생할 수 있다. 이 모든 영역에 다 try-catch를 걸고 예외를 잡을 수는 없는 일이다. 대부분의 예외는 일단 그냥 던지는 것이 좋다. 자바의 예외가 좋은 것은 꼭 예외가 발생한 그 지점에서 처리를 하지 않아도 된다는 것 때문이다. 예외를 던짐으로서 예외를 처리하기에 적절한 위치에서 처리하게 만들 수 있다. 어떻게 처리해야할지 잘 모르겠다면 그냥 그대로 던지도록 하는 것이 좋다. 예외를 잡아서 처리해야하는 곳은 일반적으로 사용자에게 화면을 보여주기 직전이며 이것은 웹 애플리케이션이 MVC(Model-View-Controller) 패턴으로 작성되어 있다면 컨트롤러에서 이 역할을 하게 된다. 컨트롤러에서 예외를 보고 판단을 해서 사용자에게 보여줄 화면을 결정하는 것이다. 쇼핑몰에서 마일리지 적립액으로 상품을 구매하는 과정을 예로 들어보자. 만약 고객이 자신의 마일리지보다 더 많은 금액의 상품을 구매하려한다면 구매를 수행하는 모델 객체에서 예외가 발생할 것이다. 그러면 이 모델 클래스에서 예외를 바로 잡지 말고 던져서 구매 프로세스의 컨트롤러 객체에서 이를 잡아서 예외 페이지로 포워드를 시켜서 예외 메시지를 보여주는 식으로 코딩하면 된다.

    웹사이트 방문객을 위해 중요한 것은 자바 예외가 발생했을 때 이해할 수 없는 시스템 에러 메시지나 스택트레이스 등의 황당한 화면이 아닌 친절한 에러 메시지를 표시해주는 것이다. 이를 위해서는 컨트롤러에서도 처리하지 못하고 던져진, 정말 예상 밖의 예외를 모두 끌어모아서 처리하는 부분이 필요하다. Servlet/JSP에서는 이런 부분의 처리를 위한 기능을 여러 가지로 제공하고 있고 스트러츠 등의 프레임웍에서도 다양한 방법을 제공하고 있다. JSP의 에러 페이지 설정이 그 한 예다. 그러나, JSP의 에러 페이지 설정 방식은 모든 JSP 페이지에 설정해야 작동한다는 단점이 있다. 만약 에러 페이지 지정을 빠뜨린 페이지에서 예외가 발생한다면 서블릿 엔진의 에러 메시지가 그대로 웹사이트 방문객에게 전달되고 만다. 이런 부분을 쉽게 처리하기 위한 방법이 있다. 이것은 위에서 설명했던 web.xml의 에러 페이지 설정을 이용하는 것이다. 우선 다음의 예를 보자. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"><error-page> <exception-type>java.lang.Exception</exception-type> <location>/common/error.jsp</location></error-page><error-page> <error-code>404</error-code> <location>/common/error.jsp</location></error-page></PRE>이렇게 설정해두면 웹 애플리케이션 전반에서 발생하는 예외 중 java.lang.Exception을 상속한 예외는 모두 잡혀서 /common/error.jsp 페이지에서 처리하게 된다. 예외가 발생하면 request 객체에 예외 상황에 대한 정보가 attribute로 저장된 후 /common/error.jsp로 포워딩되어 이곳에서 request에 담긴 정보들을 바탕으로 에외 처리를 해줄 수 있다. 이 곳에서는 일반적인 에러 메시지를 사용자에게 보여주면 된다. 자바 예외 뿐 아니라 HTTP 에러 코드도 잡아낼 수 있다. 이를테면 없는 페이지를 호출해서 404 에러가 나는 경우 이를 잡아서 페이지가 없다는 에러 메시지를 좀더 친절한 메시지로 보여줄 수 있다. 덧붙여, 이 에러 처리 페이지는 가급적 순수한 서블릿으로 만드는 것이 좋다. 스트러츠의 Action으로 에러 페이지를 구성해본 적이 있었는데 설정 상의 문제로 스트러츠의 ?ActionServlet 로딩이 실패할 경우 예외를 제대로 표시하지 못한다. JSP로 만드는 것도 나쁘진 않으나 복잡한 로직이 들어갈수록 서블릿이 더 코딩하기 더 편할 수 있다. 만약 이 에러페이지 자체에서 또다시 예외가 발생하면 찾기 힘든 경우가 많기 때문에 주의를 많이 기울여야한다.

    4.2.3 로깅 #
    에러 페이지에서 해야할 또 하나 중요한 일은 예외 상황에 대한 로그를 남기는 것이다. 에러 페이지까지 왔다는 것은 이미 개발자의 예상을 벗어난 동작을 하고 있다는 것이므로 이 사실은 개발자에게 빨리 전달되어야한다. 때문에 로그를 제대로 남겨서 조회하기 편한 시스템을 구축해야한다. 로깅 API는 여러 가지가 있고 JDK 자체에도 포함되어 있지만 log4j가 가장 널리 사용되고 성능, 기능, 안정성 등 여러 가지 면에서 다른 것들보다 낫다. 여러 가지 로깅 API를 바꿔가면서 사용할 수 있게 해주는 자카르타의 commons-logging 프로젝트도 쓸만하다. 로거 객체는 일반적으로 클래스 당 하나를 클래스의 전체 이름으로 생성해서 사용한다. 다음은 commons-logging을 사용하는 예다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black">package com.hangame.avatar;import ...public class Avatar { private static Log log = LogFactory.getLog(Avatar.class); public void changeBackgroud() { log.debug("avatar changing.."); }}</PRE>이러면 로그 객체는 Avatar 클래스의 전체 이름, com.hangame.avatar.Avatar로 생긴다. 만약 여기에 log4j를 붙여서 사용한다면 다음과 같은 log4j 설정을 사용할 수 있다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"><?xml version="1.0" encoding="UTF-8" ?><log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'> <appender name="normal" class="org.apache.log4j.ConsoleAppender"> <param name="Threshold" value="DEBUG"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%-5p] %m%n"/> </layout> </appender> <appender name="memory" class="com.nhn.logging.MemoryAppender" > <param name="Threshold" value="ERROR"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%-5p](%F:%L) %m%n"/> </layout> </appender> <logger name="com.hangame" additivity="false"> <level value="DEBUG"/> <appender-ref ref="normal"/> <appender-ref ref="memory"/> </logger> <logger name="org.apache" additivity="false"> <level value="INFO"/> <appender-ref ref="normal"/> </logger> <root> <level value="WARN"/> <appender-ref ref="STDOUT"/> </root></log4j:configuration></PRE>위의 설정은 com.hangame와 org.apache라는 이름의 로거를 두 개 생성하고 있다. 로거의 특성은 이름으로 상속된다. com.hangame.avatar.Avatar라는 이름의 로거는 com.hangame의 속성을 모두 상속 받게 된다. 그러면 com.hangame이 normal과 memory라는 두 개의 appender를 갖고 있기 때문에 com.hangame.avatar.Avatar 로거가 찍은 로그는 표준 출력으로도 나가고 메모리에도 남게 된다. log4j의 이런 특성을 이용하면 다양한 방식으로 로그를 남길 수 있고 로그를 선택적으로 켜고 끄는 것이 가능하다. 이런 기능들을 잘 활용하면 로그를 조회하기 쉽게 구성할 수 있다. 위에서 예를 든 것처럼 메모리에 최근 로그를 남겨두고 이를 조회할 수 있는 페이지를 만든다거나 데이터베이스에 로그를 쌓을 수도 있다. 그리고 주기적으로 이런 로그 조회 페이지를 모니터링하면서 로그 리포트를 개발자에게 메일 등으로 자동 발송해주는 시스템도 구상해 볼 수 있을 것이다.

    4.2.4 예외 추적 #
    예외 처리 시스템을 구축하고 예외 로그를 남겼으면 다음은 이 정보를 바탕으로 문제점을 찾아들어가는 것이다. 예외 추적의 출발점은 당연히 예외 스택 정보이다. 대부분의 문제는 예외 스택 정보만 가지고도 찾아낼 수 있다. 하지만 의외로 많은 프로그래머들이 예외가 발생했을 때 스택 정보를 보지 않고 자신의 경험에 의지해서 문제점을 예측하려 하곤 한다. 이런 실제 상황에 기반하지 않은 예측은 운 좋게 문제를 바로 짚어내는 경우도 있겠지만 대개의 경우 시간만 낭비하게 된다. 예외가 발생하면 반드시 스택 정보에 찍힌 소스의 라인부터 살펴보는 습관을 기르는 것이 좋다. 스택 정보는 가끔 수백 라인에 이를 정도로 길어지는 경우도 간혹 있다. 이 모든 정보를 다 찾아볼 필요는 없다. 스택 정보는 메쏘드가 호출된 역순으로 찍히므로 위에 있는 정보가 예외가 발생한 위치와 가까운 정보다. 그렇다고 늘 제일 위의 정보를 봐야하는 것은 아니다. 웹 애플리케이션의 경우 스택 정보는 자신이 작성한 클래스 뿐 아니라 서블릿 엔진을 포함한 여러 가지 클래스의 정보들이 같이 담겨 있다. 이런 정보들은 보통 볼 필요가 없고 스택 정보에서 자신이 작성한 클래스 중 제일 위에 있는 것, 이것이 예외가 발생한 지점이며 이곳을 찾아보면 대부분의 문제점은 정확하게 추적 가능하다.

    또 한 가지 자바 초보자를 괴롭히는 문제는 ?NullPointerException이다. 사실 이것은 초보자에게는 아주 까다로운 문제지만 조금만 알면 가장 찾기 쉬운 문제 중 하나가 ?NullPointerException이다. ?NullPointerException은 객체의 멤버 변수나 메쏘드를 이용하려고 할 때 그 객체가 null인 경우에 발생한다. 따라서 ?NullPointerException이 발생하면 위의 방법대로 예외가 발생한 라인을 찾아들어간 다음 그 라인에서 멤버 지정 연산자(.) 앞에 있는 객체를 보면 된다. 이 사실만 알고 있어도 ?NullPointerException이 발생했을 때 어떤 객체가 null인지를 쉽게 찾아낼 수 있을 것이다.

    간혹 ?NullPointerException이 싫어서 다음과 같은 코드를 작성하는 경우가 있다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"> if ("Y".equals(param)) doSomthing(); else doOther();</PRE>이런 코드는 조심해서 써야한다. param의 null 체크가 귀찮아서 이런 식의 코드를 쓰곤 하는데 만약 param의 값이 Y인 경우는 doSomething()을 실행하고 N이나 null이면 doOther()를 실행해야하는 경우라면 이 코드는 문제가 없다. 그러나, 만약 param은 null이면 안되는 상황이라면 어떻게 될까? 다른 부분의 버그로 param에 null이 들어와도 프로그래머는 이것을 알아차리지 못하고 넘어가게 된다. 즉, 버그를 은폐하는 코드가 된다. 당장의 문제를 발생하지 않더라도 이런 코드는 나중에 찾기 힘든 문제를 유발할 수 있다. 이런 경우는 그냥 ?NullPointerException이 발생하도록 내버려 두면 param에 null 값이 들어왔을 때 다른 부분에 버그가 있기 때문이라는 사실을 감지할 수 있다. 상황에 따라 위와 같은 코드를 써도 되는지를 신중히 검토한 후 사용해야한다. 예외 발생이 두려워서 버그를 은폐할 수 있는 코드를 만들지 말자.

    4.2.5 한글 문제 #
    웹 프로그래머들을 괴롭게 하는 문제를 꼽을 때 빠지지 않는 것이 한글 문제다. 한글 문제가 지금처럼 골치아프게 된 데는 역사적으로 복잡한 원인들이 얽혀 있는데 이런 문제는 접어두고 자바 웹 프로그래머로서 한글 문제를 해결하기 위해 알아야하는 것들을 살펴보자.

    자바는 문자열과 바이트 스트림을 다르게 취급한다. 자바의 스트링은 유니코드의 문자셋을 사용하며 문자열을 파일에 쓰거나 네트워크로 전송하는 등 실제 입출력이 일어날 때는 문자열을 바이트 스트림으로 변환하게 된다. 이 때 바이트 스트림으로 변환하는 규칙이 인코딩이다. 따라서 바이트 스트림으로 전달된 것을 문자열로 바꾸거나 문자열을 바이트 스트림으로 전달할 때는 반드시 인코딩을 지정해야한다. 이런 인코딩 중 한글을 표현할 수 있는 인코딩은 자바에서 사용하는 이름을 기준으로 하면 EUC-KR, ?MS949, UTF-8, UTF-16 정도가 있다. EUC-KR은 ?KSC5601-1987에 기반한 인코딩으로 한글의 모든 문자를 다 표현할 수 없다. ?MS949는 EUC-KR을 확장해서 모든 한글을 표현할 수 있지만 비표준이고 코드 자체에 기술적인 결함이 많다. UTF-8과 UTF-16은 유니코드의 인코딩들이며 모든 한글을 표현할 수 있고 표준이며 한글 이외의 다른 캐릭터셋과 함께 표현이 가능하다. 보통 많이 쓰이는 EUC-KR은 RFC 표준 인코딩이긴 하나 한글의 확장 문자들을 제대로 표시하지 못한다. 그래서 자바 웹 프로그래밍에서는 ?MS949를 많이 쓰게 된다. 자바에서 스트링 객체를 생성할 때는 이 중에 하나로 인코딩을 줘서 생성해야 한글을 표현할 수 있게 인코딩된다.

    웹 서버로 전달되는 요청은 클라이언트의 웹브라우저가 문자열을 바이트 스트림으로 인코딩하는데 이 때 사용하는 인코딩은 일반적으로 한글 윈도우의 기본 인코딩인 ?MS949다. 그런데, 서블릿 엔진에서 요청을 처리하는데 사용하는 기본 인코딩이 ISO-8859-1이기 때문에 아무 것도 지정하지 않으면 ?MS949로 인코딩된 바이트들을 ISO-8859-1 인코딩의 스트링 객체로 만들기 때문에 한글이 깨져보이게 된다. 따라서 기본 인코딩을 ?MS949로 지정해주면 인코딩이 보존된 상태로 한글이 깨지지 않게 된다. ?HttpServletRequest.setCharacterEncoding() 메쏘드에서 이것을 지정해줄 수 있다. 그러나, 이것에도 약간 문제가 있다. 서블릿 스펙상 이 메쏘드는 POST 요청에만 적용된다. 즉, POST 요청의 파라미터는 setCharacterEncdoing에서 지정한 인코딩으로 스트링 객체가 생성되기 때문에 한글을 보존할 수 있으나 GET 요청은 setCharacterEncoding의 적용을 받지 않기 때문에 GET으로 받은 파라미터는 인코딩 변환을 다시 해주어야한다. 다만, 이것은 서블릿 엔진에 따라 다르다. 톰캣의 경우도 4.1 버전과 5.0 버전이 다르게 동작하니 주의가 필요하다.

    웹 서버에서 다시 클라이언트로 응답을 할 때는 반대의 과정이다. 자바의 스트링 객체가 바이트 스트림으로 변환되며 이 때 역시 인코딩을 지정해야한다. 이 인코딩은 JSP 페이지에서 페이지 지시자의 pageEncoding 속성을 통해 지정을 해줄 수 있고 서블릿 2.4 스펙에서는 ?HttpServletResponse.setCharacterEncoding을 사용할 수 있다. HTTP 요청을 읽는 과정과 역순이라고 생각하면 된다. 그리고, 웹 서버에서 요청을 읽을 때 ?MS949를 지정해 주듯이 클라이언트의 웹브라우저도 웹 서버에서 생성한 응답을 정확하게 읽으려면 어떤 인코딩을 사용해야하는지 알아야한다. 이것을 지정해주는 것이 HTML의 Content-Type이다. 다음과 같이 지정할 수 있다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"> <meta http-equiv="Content-Type" content="text/html;charset=euc-kr" /></PRE>여기서 지정하는 charset은 원칙적으로는 당연히 웹 서버에서 응답 객체를 생성할 때 지정한 인코딩값과 같아야 제대로 한글로 읽을 수 있다. 그러나, 여기 지정하는 charset이 RFC 표준 문자셋이 아닐 경우 브라우저에 따라 인식을 못할 수도 있다. 그래서 ?MS949로 인코딩했다면 ?MS949를 지정해야 정상이지만 ?MS949가 RFC 표준이 아니기 때문에 문제가 생길 수 있다. 그렇다고 응답의 인코딩을 EUC-KR로 지정하게 되면 확장 한글을 표시할 수 없기 때문에 문제가 된다. 그래서 페이지 인코딩은 ?MS949로 하지만 Content-Type에는 euc-kr을 지정해주게 되는 것이다. 물론 이렇게 되면 경우에 따라 확장 한글이 깨질 수 있지만 다행스럽게도 대부분의 브라우저에서 이렇게 지정하면 잘 동작한다.

    사실 이 부분은 응답 스트림에 적용되는 인코딩과 HTML Content-Type에 지정하는 인코딩이 같기만 하면 되기 때문에 굳이 ?MS949를 사용할 필요는 없고 UTF-8 등의 인코딩을 사용해도 무방하다. 따라서 응답 스트림의 인코딩도 UTF-8로 하고 Content-Type도 UTF-8로 지정하는 것이 가장 확실한 방법일 수 있다. 또한, HTML의 Content-Type에 UTF-8이 지정되어 있으면 이 페이지에서 폼을 전송할 경우에도 UTF-8로 인코딩되어 요청을 파싱하는 쪽에서도 UTF-8을 사용할 수 있다. 유니코드의 인코딩들인 UTF-8, UTF-16은 한 인코딩으로 다국어를 처리할 수 있기 때문에 다국어 지원이 필요한 웹 애플리케이션은 실제로 UTF-8로 작성된 것이 많다. 다국어 지원이 필요 없다고해도 UTF-8을 사용하는 것이 오히려 한글 문제를 더 쉽게 해결하는 방법이 될 수 있다.

    웹 뿐 아니라 데이터베이스나 파일에 입출력을 할 때도 마찬가지의 원리가 적용된다. 사용하는 인코딩이 다르면 변환 과정을 거쳐야한다. 이것은 리눅스나 유닉스에서 문제가 될 수 있다. 리눅스는 ?MS949를 지원하지 않고 EUC-KR만 지원하기 때문이다. 따라서 윈도우에서 개발하고 리눅스에서 돌리는 경우 문제가 되는 경우가 간혹 있다. ?MS949가 또 하나 문제가 되는 영역은 XML 파서다. 현재 가장 널리 사용되는 XML 파서는 Xerces인데 이 파서는 RFC 표준 문자셋 외에는 지원하지 않기 때문에 ?MS949 인코딩은 파싱 에러가 난다. 그런 반면 JDK 1.4에 포함된 파서인 Crimson은 네임스페이스 파싱에 버그가 있다. ?MS949를 XML 인코딩으로 쓸 경우 XML 파서 선택이 문제가 될 수 있는 것이다. 다행스럽게도 JDK 5.0에 포함된 파서는 Xerces를 썬에서 패치한 것인데 이것은 아무 문제가 없다. 하지만 여전히 많은 오픈소스 라이브러리들이 Xerces를 사용하고 있기 때문에 문제가 되는 경우는 계속 나타날 수 있을 것이다. 이것 때문에라도 UTF-8을 사용할 필요가 있다.

    자바에서의 한글 문제는 문자열과 바이트스트림의 변환에 인코딩이 주어져야한다는 사실만 생각하면 다 쉽게 해결가능하다. 역시 기본이 잘 갖춰져 있으면 한글 문제도 쉽게 해결할 수 있는 것이다.

    4.2.6 URL 인코드 #
    URL 인코딩이 필요한 것은 URL에 사용가능한 문자가 제한되어 있기 때문이다. URL 스펙(RFC 1738)에 정의된 바로는 URL에 사용할 수 있는 문자는 알파벳, 숫자와 몇 가지의 특수문자 뿐이다. 따라서 다양한 문자들을 URL로 전달하려면 URL에서 허용하는 문자로 변환시켜서 전달해야한다. 이것은 GET 요청의 파라미터로 값을 전달하려할 때 문제가 된다. 예를 들어 http://website.com/process.jsp에 로그인 안된 상태에서 접근하면 자동으로 로그인 페이지인 http://website.com/login.jsp로 리다이렉트된 후 로그인을 하면 원래 요청했던 페이지로 다시 리다이렉트되도록 해야한다고 하자. 그러면 /process.jsp에서는 로그인 페이지로 리다이렉트시키면서 파라미터로 현재 요청한 URL, 즉 /process.jsp를 넘겨주고 login.jsp에서는 로그인 처리가 끝난 후 이 URL로 다시 리다이렉트를 시키면 된다. 여기서 /process.jsp에서는 http://website.com/login.jsp?redirect=http://website.com/process.jsp와 같은 형식으로 리다이렉트를 해주면 될 것이다. 여기서 문제는 redirect 파라미터의 값이 URL이기 때문에 URL 안에 URL이 들어간 형태가 되어 제대로 파싱이 되지 않는다. 그래서 파라미터로 넘겨야하는 URL 부분을 ?URLEncoder로 인코딩을 해서 http://website.com/login.jsp?redirect=http%3A%2F%2Fwebsite.com%2Fprocess.jsp와 같은 형태로 넘겨야한다. 이 값을 받는 부분에서는 다시 디코딩을 해줄 필요가 없다. URL은 자동으로 웹 서버에서 파싱할 때 디코딩을 해주기 때문이다. URL을 통해서 GET 요청의 파라미터로 보내야하는 값은 반드시 URL 인코딩을 거쳐야한다는 사실만 기억하도록 하자. 참고로 자바스크립트에서도 escape, unescape 함수를 통해서 URL 인코딩, 디코딩과 유사한 작업을 수행할 수 있다.

    4.2.7 클래스패스의 리소스 사용법 #
    웹 애플리케이션은 보통 애플리케이션의 설정을 담고 있는 파일이 필요하다. web.xml, struts-config.xml 등의 설정 파일들은 보통 웹 애플리케이션의 /WEB-INF/에 위치하게 되는데 그 외에 애플리케이션에서 사용하는 파일들은 어디에 놓고 사용하는 것이 편리할까? 가장 관리하기 쉽고 부가적인 작업이 적은 방법은 클래스패스에 두는 것이다. /WEB-INF/classes에 두면 자바의 클래스로더를 이용해서 이런 파일들에 접근할 수 있다. log4j 등 많은 라이브러리들이 자신의 설정 파일을 클래스패스에서 가장 먼저 찾게 된다. 다음의 예제를 보자 <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"> public File getFile(String name) { ClassLoader loader = Thread.currentThread().getContextClassLoader(); return new File(loader.getResource(name).getFile()); } public void doSomeProcess() { File file = getFile("config.xml"); }</PRE>위의 코드는 클래스패스에서 config.xml을 읽는다. 웹 애플리케이션의 기본 클래스패스는 /WEB-INF/classes이므로 기본적으로 여기서 찾게 된다. 이것으로 jar 파일 안의 내용도 읽을 수 있다. 이 경우는 ?ClassLoader.getResourceAsStream을 통해서 스트림으로 파일 내용을 읽을 수 있다. 대부분의 IDE나 maven 등의 빌드 툴에서는 소스 경로에 있는 파일들 중 자바 소스가 아닌 파일들을 자동으로 클래스패스로 복사해주므로 이용하기도 편리하다. 자카르타의 commons-discovery 프로젝트는 이런 기능들을 모아서 편리하게 이용할 수 있게 제공하고 있다.

    4.2.8 서블릿/액션 멤버 변수 공유 문제 #
    JSP가 보급되기 시작하던 초기에 많이 발생하던 문제로 웹사이트의 이용자가 접속했을 때 자신의 정보가 아닌 다른 사람의 정보가 나타나면서 엉키는 경우가 있었다. 이것의 원인은 서블릿에 대한 이해가 부족해서 발생한 것이었다. 다음의 예제를 보자. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black">public class BadServlet extends HttpServlet { Map userInfo; protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { String username = req.getParameter("name"); Map userInfo = UserManager.getUserInfo(username); req.setAttribute("userInfo", username); }}</PRE>얼핏 별 문제가 없어보이지만 이 코드는 심각한 문제가 있다. 서블릿은 보통 서블릿 엔진에서 하나만 생성되고 한 번 생성된 서블릿 객체가 계속 재활용된다. 때문에 A와 B라는 두 사용자가 동시에 이 서블릿을 호출하게 되면 A의 호출을 수행하는 중에 B의 호출이 userInfo의 값을 바꿔버릴 수 있다. 그러면 A는 B의 정보를 보거나 그 반대의 경우가 생길 수 있는 것이다. 혼자서 테스트할 때는 한 번에 한 쓰레드만 service 메쏘드를 호출하기 때문에 이런 문제가 잘 드러나지 않기 때문에 별 문제 없는 줄 알고 있다가 서비스를 오픈하고 나면 문제가 되는 경우가 있으므로 조심해야한다. JSP에서 <%! %>를 통해서 선언하는 내용도 마찬가지 문제가 발생하므로 주의하자. 이런 내용 역시 자바 클래스와 멤버 변수의 기본 개념을 이해하고 서블릿 스펙만 한 번 읽어본다면 금방 알 수 있는 내용이다.

    4.3 결론, 생각하기 #

    이 내용들을 읽으면서 모르는 내용이 하나도 없었다면 자바 웹 프로그래머로서 어느 정도 기본은 되어 있다고 할 수 있다. 이런 내용들은 그 하나하나에 대한 지식을 쌓는 것도 중요하지만 더 중요한 것은 이런 내용을 알아야한다는 사실을 아는 것이다. 무엇을 알아야하는가를 가르쳐주는 것은 스펙이다. 스펙 문서들은 대부분 영어이고 그다지 친절하게 되어 있진 않지만 해당 분야에 대해 가장 정확한 정보를 담고 있다. 자세한 내용을 다 알진 못하더라도 스펙에 어떤 내용이 있는가 정도는 알아야 그 내용 중 자신에게 필요한 내용을 찾아서 공부할 수가 있는 것이다. 이런 정보를 어디서 찾을 수 있는가를 알고 있는 것도 중요하다. 기본적으로 www.ietf.org, jcp.org, java.sun.com, www.w3.org 정도의 사이트에는 익숙해지는 게 좋을 것이다.

    많은 프로그래머들이 실제로 자기 손으로 프로그래밍해보는 게 실력이 느는 제일 좋은 방법이라고 말하지만 필자는 여기에 동의하지 않는다. 물론, 실제 경험을 쌓는 것이 필수적인 과정이긴 하다. 그러나, 기본 지식을 등한시한 상태에서 코딩만 해보는 것으로는 실력이 잘 늘지 않는다. 코딩 기술은 늘 수 있겠지만 정말 실제 서비스를 해야하는 프로그래밍에서 중대한 실수를 저지르게 되거나 남들이 쉽게 쉽게 하고 있는 일들을 어렵게 빙 둘러가면서 하게될 수 있다. 그래서 기본기를 갖추는 것이 중요한 것이다.

    거듭해서 기본의 중요성을 강조했는데 한 가지 덧붙이고 싶은 말은 이런 기본 지식 뿐 아니라 기본을 활용하는 능력을 키우는 것도 잊지 말아야한다는 것이다. 앞서 언급한 예외 처리 같은 내용은 기본이긴 하나 자바 문법만 잘 안다고 알 수 있는 내용들은 아니며 기본을 바탕으로 좋은 판단을 내릴 수 있는 능력이 있어야한다. 결국 좋은 프로그래머가 되려면 먼저 좋은 사고 능력을 가지고 있어야하는 것이다. 글짓기를 잘하는 방법으로 흔히 다독(多讀), 다작(多作), 다상량(多商量)을 이야기한다. 많이 읽고 많이 쓰고 많이 생각하라는 것이다. 프로그래밍도 이와 비슷하다. 각종 스펙들과 좋은 코드들을 많이 읽어보고 직접 코딩도 많이 해보면 분명 실력이 늘지만 이것으로는 충분치 않다. 프로그래밍을 하면서 끊임없이 생각해야한다. 지금 작성한 코드는 좋은 코드인가, 이렇게 코딩하면 불편한데 개선할 방법은 없을까, 이 API들로 무엇을 할 수 있을까, 좀더 개발 속도를 향상시키려면 어떻게 해야할까 등등 생각을 많이 해야 진짜 발전을 이룰 수 있다. 만일 손가락이 아플 정도로 하루 종일 키보드를 두드리고 있다면 좋은 프로그래머라고 할 수 없다. 생각하는데 좀더 많은 시간을 써야한다. 모니터를 구부정하게 들여다보면서 키보드를 두드리는 것은 것보다는 의자에 편안히 기대서 생각하는 시간을 늘리자. 복잡한 문제가 있으면 바깥 공기를 쐬면서 산책을 하면서 생각을 하는 것도 좋다. 굳이 건강을 생각하지 않더라도 걷는 것은 두뇌를 활성화시키기 때문에 해결책을 더 빨리 찾을 수 있게 해 준다. 남들이 보기에는 게을러보일 수 있지만 놀고 있는 게 아니라는 것은 결과로 충분히 보여줄 수 있다. 물론 이런 생각을 잘 이어나가기 위해서는 생각의 재료가 되는 기본에 충실해야함은 물론이다. 어둠침침한 구석에 앉아 키보드만 두드리는 geek가 아닌 보다 인간다운 프로그래머가 되자.

    4.4 참조 #

    <PRE></PRE>
    Posted by 1010
    01.JAVA/Java2008. 7. 7. 14:26
    반응형
    java networking
    Posted by 1010