:: 산사에 눈 내리는 소리

export MAVEN_OPTS=-Xmx1024m

http://www.ashishpaliwal.com/blog/2008/10/nio-frameworks-in-java/

Netty 개발자가 MINA를 만들었다가 다시 Netty로 돌아왔다는 사실. 그 여파로 MINA는 지지부진, Netty는 일취월장

Netty 홈페이지: http://www.jboos.org/netty/

사용법이 궁금하다면... http://www.jboss.org/file-access/default/members/netty/freezone/guide/3.1/html_single/index.html

http://www.springsource.com/training/spr001/icn20090302/?geonr&__utma=1.2971782686416582000.1231936752.1231936752.1231936752.1&__utmb=170440930.1.10.1231936760&__utmc=170440930&__utmx=-&__utmz=1.1231936752.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)&__utmv=-&__utmk=80448919

이야.. 그러나.. 가격이. ㅠ.ㅠ

http://tinyurl.com/9w3fmv
http://tinyurl.com/7459nw

javapassion.com 사이트의 주인장을 만났습니다. passion이라는 낱말을 쓸 수 있는 분이었습니다.

- Q3, 2008

- Moves to Java 5+ basis

- Further improvements in Spring MVC will provide a unified programming model between Spring MVC and Spring Web Flow to handler the full range of web programming requirements

- Comprehensive REST support across Spring MVC and Spring Web Services

출처: http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6169.pdf?cid=925649

pushAll에 이어 popAll을 추가 구현해 보겠습니다. 단순하게 제네릭을 이용하면 아마도 다음 코드와 비슷할 것입니다.

public void popAll(Collection<E> dst) {
  while(!isEmpty())
    dst.add(pop());
}

그리고 popAll을 다음처럼 호출할 것입니다.

Stack<Number> numberStack = new Stack<Number>();
Collection<Object> objects = ...;
numberStack.popAll(objects);

이 코드 역시 컴파일 할 수 없습니다. Collection<Object>와 Collection<Number>는 다릅니다.

앞에 코드는 Object 형 묶음인 objects변수에  Number형을 싹 꺼내서 담으려고 합니다. 이 경우는 앞 글에서 언급한 <? extends E>로 해결할 수 없습니다. 'Object extends Number'와 같은 의미구문은 자바세상에서 절대 존재할 수 없습니다. 이 경우는 역으로 <E extends ?> 가 맞습니다. 그렇다고 그렇게 코드를 작성하지는 못하고, super라는 키워드를 이용합니다. <? super E>

dst변수는 데이터를 이용하는 소비자(consumer)입니다. 제 관찰 기준으로, 매개변수의 메소드에 인자를 넘겨 호출하면 소비자입니다. (혹시 이 기준이 틀리다면 댓글 ^^)

이제 제네릭을 이용할 때, 인자에 단순히 E라고 적을 것이 아니라 상황에 따라 extends, 혹은 super를 적어야 한다는 것을 아셨습니다. 조슈아 아저씨가 쉽게 외우도록 한국형 공식을 만들었습니다.

PECS

약어입니다. producer-extends, consumer-super.

JavaOne2008에서 조슈아 아저씨는 작년에 이 부분 설명이 좀 어려웠다고 고백하며 미안하다 했습니다. 아무래도 어느 정도의 암기가 필요했다고 생각한 것 같습니다. 저도 한 번 설명듣고 PECS를 외우고 나니, 다른 보기를 들 때 이해하는데 한결 나았습니다. 참고로 <Effective Java, 2nd> 책에도 크게 약어를 적어 놓았습니다.

PECS stands for producer-extends, consumer-super.

주의할 점이 있습니다.

한 변수가 P와 C의 역할을 다 하는 경우가 있습니다. 그 때는 그냥 E만 적습니다. (제네릭 타입)

두 번째로 메소드를 호출하는 쪽에서는, 구현 코드에서 extends를 썼는지 super를 썼는지 의식하지 않도록 메소드를 디자인해야합니다. 앞 두 글의 클라이언트 코드는 구현 쪽을 신경쓰지 않았습니다. 메소드 구현부에서 클라이언트의 의도대로 수행되도록 적절히 extends나 super 키워드를 적었습니다.

먼저, 아래 내용은 <Effective Java, 2nd> Item28의 일부를 정리한 것임을 밝힙니다.

--- 아래 ---

어떠한 타입도 담을 수 있는 Stack 클래스가 있습니다.

public class Stack<E> {
  public Stack();
  public void push(E e);
  public E pop();
  public boolean isEmpty();
}

pushAll메소드를 구현하여 덧붙이면 다음과 같이 작성할 수 있습니다.

public void pushAll(Iterable<E> src) {
  for (E e : src)
    push(e);
}

이렇게 작성한 메소드를 다음처럼 사용할 수도 있습니다.

Stack<Number> numberStack = new Stack<Number>();
Iterable<Integer> integers = ...;
numberStack.pushAll(integers);

사실 이 코드는 컴파일조차 할 수 없습니다.

Integer가 Number를 상속했기에 당연히 되리라 생각할 수 있지만, 컴파일 타임에 Iterable<Integer>와 Iterable<Number>는 완전히 다른 타입입니다. 제네릭에서 가장 착각하기 쉬운 부분입니다.

이런 경우에는 'bounded wildcard type'을 이용하면 '상식대로' 돌아가도록 개선할 수 있습니다.

public void pushAll(Iterable<? extends E> src) {
  for (E e : src)
    push(e);
}

'Iterable<? extends E>'는 'E의 하위타입에 대한 Iterable' 이라고 읽습니다. 그렇다고 E를 못넘기는 것은 아닙니다. E와 E의 하위타입 모두 가능합니다.

참고로, 여기서 변수 src는 정보를 생산(e)하고 있지, 다른 변수 값을 이용하지 않습니다. 이 경우 src를 생산자(producer)라고 부를 수 있습니다. 이런 변수를 'producer'라고 부르는 것은 <Effective Java>의 지은이 'Joshua Bloch'가 임의로 붙인 것 같습니다. 참고라고 적었지만 일단 외워두는 것이 좋습니다. (이유는 다음 글에)

다음 글에서는 반대 경우를 설명 드리겠습니다.

http://maas-frensch.com/peter/2006/08/09/spring-mvc-and-ruby-controllers/

JSP로 커스텀 태그를 만들면서 한 삽집을 소개하려 합니다.

커스텀 태그에는 다음처럼 인자를 넘길 수 있습니다.

<%@ attribute name="groupList" required="true" rtexprvalue="true" %>

이름에서 미루어 짐작하듯이 groupList는 ArrayList 형입니다. 그런데 커스텀태그 내에서 <c:forEach>태그가 먹지 않아 한참을 헤맸습니다. 답답해서 forEach 구문을 지우고 ${groupList.class.name}을 넣어보니... 'String' 타입이라고 나왔습니다. 세상에 -_-;; String이어서 forEach가 돌지 않은 것은 당연하지만, 왜 ArrayList가 아니고 String인지.

J2EE 문서를 보니, attribute에 옵션으로 쓸 수 있는 속성이 하나 있었습니다. type ㅠ.ㅠ. 이 type을 명시하지 않으면 기본으로 String이라고 가정하는 것이 문제 원인이었습니다. groupList가 커스텀태그로 넘어오면서 String으로 바뀐 것입니다. (groupList.toString())

다른 커스텀태그를 보니, 공교롭게도 지금까지 String만 넘겼습니다. 흐. ^^ (사실은 int도 넘겼지만 화면에 찍으면 int인지 String인지 구분이 안돼죠)

문제의 코드는 아래처럼 고쳐 적으면 됩니다.

<%@ attribute name="groupList" type="java.util.List" required="true" rtexprvalue="true" %>

추가로,

개발자는 자바로 업무로직 객체를 개발하고 디자이너가 EL을 익혀 디자인을 입히면 된다는 몇몇 JSP/EL 망상가들의 말이 떠올랐습니다. 저는 업무 영역을 자바 업무로직 개발자, UI 개발자(벨로시티, JSP/EL, 프리마커 등등), HTML 코더(웹표준 준수 노력), (포토샵을 쓰는)디자이너 이렇게 나누는 것이 맞다고 생각합니다.

이클립스에는 불필요한 import를 제거하거나 필요한 import문을 자동으로 추가하는 기능이 있습니다. (Ctrl+Shift+O) 소스코드 형식을 예쁘게 정돈해주는 포맷터도 있습니다. (Ctrl+Shift+F)

파일을 저장할 때 두 기능을 자동으로 실행할 수 있습니다. 팀에서 같은 포맷터를 공유하면 일관된 소스 형태를 유지할 수 있고, 화이트 스페이스 정도의 차이 때문에 커밋하는 일을 줄일 수 있습니다.

설정은 다음 그림을 참고하세요.

http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html 페이지에 있는 PDF 파일

generics-tutorial.pdf

참고: http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html

JCosole은 결국 사용해보지 못하고 작별의 인사를 나눠야할 것 같습니다. Sun에서 곧 JConsole의 기능을 강화한 Visual VM 도구를 다음 JDK와 함께 배포할 것이라고 합니다.

Visual VM은 JConsole처럼 모니터링 기능을 제공할 뿐만 아니라 프로파일링 기능도 제공합니다. 이제 프로파일링을 위해 이런 저런 도구를 찾아 헤매일 필요가 없을 것 같습니다.

참고로 이 도구를 내장한 통합개발환경이 넷빈즈입니다. 넷빈즈를 설치하면 손쉽게 프로파일링을 수행할 수 있습니다. 특히 iDE에 통합했기 때문에 프로파일로의 통계치에서 해당 클래스나 메소드를 더블 클릭하면 바로 문제 소스 코드를 살펴 볼 수 있습니다.

Visual VM: https://visualvm.dev.java.net/
넷빈즈 프로파일러: http://www.netbeans.org/features/java/profiler.html

Map <String, String> map;

이렇게 선언한 변수는 map 변수를 따라가야 Key에 넣은 String과 Value에 넣은 String의 값을 이해할 수 있습니다.

하지만 아래처럼 주석을 달면 좀 낫지 않을까요?

Map <String /*name*/, String /*address*/> map;

공부할 것 많았습니다. 자바도 영어도 ^^;

넷빈즈IDE

• 프로파일러가 공짜이지만 쓰기 쉽고 큰 도움이 될 것 같습니다.
  • https://visualvm.dev.java.net/ 을 넷빈즈에 통합한 것이고
  • 이클리스와 달리 넷빈즈를 설치하기만 하면 바로 프로파일러를 쓸 수 있습니다.
• SOA에 관심이 있다면 넷빈즈의 BPEL 디자이너 같은 GUI 도구를 눈여겨 봐야할 듯 합니다. http://www.netbeans.org/features/soa/index.html
• 자바스크립트 통합환경으로도 매우 훌륭합니다. (J)Ruby On Rails도 지원합니다!
  • 사용자가 만든 클래스 타입도 추론하여 "."을 찍으면 메소드를 추천하는 인텔리센스 기능 제공
  • 일부 기능이 IE에서는 완전하게 동작하지 않습니다. (디버깅이었던 듯) 데모를 지켜보던 제임스 고슬링이 IE를 가볍게 씹어주셨습니다. ^^

자바로 스크립트 언어 만들기

• JSR-223을 따르기만 하면 됩니다.: http://today.java.net/pub/a/today/2006/09/21/making-scripting-languages-jsr-223-aware.html
  • 스펙은 서블릿처럼 그냥 인터페이스 묶음입니다. ^^ 당연히 인터페이스를 다 '구현'해야 돌아갑니다.
• 특정 업무에 국한한 언어(Domain Specific Lanaguage)를 직접 만들어 볼 수 있습니다. 프로파일러와 더불어 업무에 바로 적용해보고 싶은 것입니다.
• JSR-223을 따르는 언어를 한 파일에 혼합해서 사용할 수도 있습니다.
  • if/while 문을 지원하는 언어를 만들려면 "휴... 언제 파서 만들고.." 캄캄합니다.
  • 하지만 if/while 기능은 groovy를 이용하고 각 if/while 블럭 안에 자기가 만든 스크립트 언어로 기술할 수 있습니다.

업무만 바라보다

• 다양한 분야(SOA, MIDP, 스크립트언어, 넷빈즈, GWT, 가비지 컬렉션)를 전체적으로 훓어보거나
• 일부는 직접 실습구현까지 해서
• 상당한 지식을 충전할 '준비'를 한 느낌입니다.

각 세션마다

• 60분이라는 짧은 시간이라서 강사도 충분히 지식을 전달하지 못했고, (Effective Java의 Joshua Bloch 세션은 훌륭했습니다)
• 영어이고 주제가 어려운 것도 많아서 충분히 흡수하지도 못했지만,
• 공부할 거리를 많이 들고 왔습니다. 지식 충전 '준비'

어제 이곳 시간으로 5일 오전, <POJOs in action>를 쓴 'Chris Richardson' 아저씨가 진행한 'Developing Enterprise Applications With the Spring Framework'를 들었습니다. (여기는 샌프란시스코 JavaOne...)

스프링 IoC, AOP, DAO, ORM을 전반적으로 다뤄 깊이 있지는 않았습니다. 그래도 3시간 반 정도 시간에 스프링 기본을 정리하여 나름 괜찮았습니다. 강사인 크리스 아저씨는 말도 천천히(어찌나 고마운지) 하고 질문에 답하는 모습이 말그대로 영국 신사였습니다.

교재는 132쪽 분량으로 제법 정성껏 정리를 잘해서 조금 더 살을 붙이면 책이 될 정도로 만족스러웠습니다. 1시간 일찍가서 교재를 보고 있는데, 대뜸 교재 괜찮냐고 물어 당황했습니다. ^^;; 다행히 대답은 안듣고 다음 사람에게 넘어갔습니다 흐.. ^^

강의 도중 바로 바로 질문을 받아가며 진행했습니다만, 질문이 마치 스프링을 좀 알면서 예외적인 상황을 묻는 것이거나, 그냥 해보면 알 수 있는 것들이라 강의 흐름만 끊었습니다. 하지만 크리스 아저씨는 질문마다 여러 미사여구를 붙여가며 친절히 답해주었습니다. (답변: "뒤에 나와요" ^^)

첫 번째 질문은 구글의 미친밥(Crazy Bob, Guice 개발자)도 한 이야기 인데 "당신은 POJO를 강조하는데 스프링 설정 파일을 쓰는 것 자체가 이미 포조가 아니지 않느냐?" 였습니다. 대답은 "Yes or No. 물론 XML설정파일은 스프링에 의존하는 것이지만 객체 자체는 어떠한 것도 의존하지 않기 때문이다" 뭐  특별한 말씀은 아니었습니다. ^^ 대답할 때 약간 당황하더군요.

강의가 끝나고 간단한 경품추첨을 했습니다. 종이 비행기를 날려서 잡은 사람에게 저자의 책 한 권을 주는 아주 아주 중요하고 멋진 행사였는데.... 제가 잡았습니다 ^^;;; 물론 크리스 아저씨의 싸인도 받았습니다.



그 뒤에 들은 'Filthy Rich Client' 세션은 강사가 너무 너무 너무 못해서 30분도 못 참고 나왔습니다. 저말고도 상당수가 탈출 -_- 잠시 쉴까 다른 것 들을까 고민하다 비싼 돈 들여온 곳이기에 'gwt' 세션으로 향했습니다.

GWT는 한 번 봐야지 봐야지 하고 못봤는데 이 세션 덕에 기초 지식은 쌓아 상당히 만족스러웠습니다. 발표자가 맘에 들어, 발표자가 쓴 책도 방금 사왔습니다. ^^

이제 40여분 뒤면 다음 강의입니다...

말이 필요없는 분! 'More "Effective Java"' 세션 뒤에 그의 두 번째 책 <Effective Java, 2nd  Ed.>싸인회에서 한 컷 찍었습니다.

'More ...'는 이 책에서 약 7개 정도의 내용을 뽑아서 진행했습니다. 굳이 여기 오실 필요는 없습니다. 책 사서 읽으면 충분합니다. ^^ 물론 여기에 오지 않는다면 조슈아 아저씨의 사인북도 얻을 수 없고 (샀지만..) 티셔츠도 얻을 수 없고, 사진도 찍을 수 없습니다.

http://stuffthathappens.com/blog/2008/04/04/simplified-array-syntax/ 블로그에서 재밌는 내용을 발견해서 소개합니다.

객체 배열을 초기화할 때 대개 다음과 같은 형식으로 작성합니다.

String[] names = new String[] { "cybaek", "milk012", "cymilk012"};

하지만 Java5를 사용한다면, 가변길이 인자, 정적 메소드 임포트, 제네릭 기능을 이용하여 다음과 같이 색다르게 기술할 수 있습니다. (글자수는 확 늘었군요 -_-)

String[] names = LangUtils.array("cybaek", "milk012", "cymilk012");

public class LangUtils {
  public static <T> T[] array(T... t) {
    return t;
  }
}

이번에는 LangUtils.array() 부분의 글자수를 더 줄여보겠습니다.

import static LangUtils.array;
String[] names = array("cybaek", "milk012", "cymilk012");

import static 구문으로 메소드를 선언하면 해당 메소드 이름만 적어도 사용할 수 있습니다. 이런 스타일은 JUnit4 테스트케이스에서 많이 씁니다. 이젠 간단한게 array라는 메소드 이름만으로 손쉽게 객체 배열을 만들 수 있습니다.

하지만 이 방법은 '객체'만 배열로 만든다는 단점이 있습니다. 다음과 같은 코드는 동작하지 않습니다.

int[] ids = array(1, 2, 3);

박싱/언박싱 기능 덕에 다음 코드는 동작합니다.

Integer[] ids = array(1, 2, 3);

int 배열을 반환하려면 원시타입을 위한 별도 메소드를 만들 수 밖에 없습니다. 하지만 원시 타입이 몇 개 되지 않으니 충분히 할 만합니다.

이 글은 자랑질입니다. 하하하.

5월 5일부터 9일까지 샌프란시스코에서 열리는 자바원에 참석합니다.

이야호!!!

비행기, 숙소 예약 완료!!!

남은 것은 예습과 관광스케줄 작성! ^^;

아래와 같은 동적 쿼리를 수행하면 필드 이름이 테이블 이름에 따라 다를 수 있습니다. 아이바티스는 디폴트로 해당 결과의 메타데이터(필드, 타입 등)를 캐쉬합니다. 따라서 두 번째 호출 때 다른 필드를 리턴한다면 오류가 발생합니다.

select * from $tableName$

오류 메시지:

check .어쩌고 저쩌고 . findAll-AuthResultMap ...

이런 경우 remapResults 속성을 true로 해주면 간단히 해결할 수 있습니다.

<select id="findAll" remapResults="true"...>
select * from $tableName$
</select>

자세한 설명은 http://openframework.or.kr/blog/?p=130

JSP에서 같은 컨텍스트에 있는 주소를 지정하는 방법입니다.

1. EL을 이용합니다.

${pageContext.request.contextPath}/a.jsp

깁니다. 당연히 못 외웁니다. ^^

2. JSTL을 이용합니다.

<c:url value="/a.jsp" />

EL보다 훨씬 낫지요?

JSTL을 이용하면 URL 뒤에 붙는 매개변수도 우아하게(?) 처리할 수 있습니다. 자세한 것은 첨부 파일을 참고하세요. ^^

jstl-1_2-mrel2-spec.pdf

ResourceBundle은 간단한 설정을 저장하기에 적합한 파일입니다. 그러나 한글을 자유롭게 쓰지 못하고 변경 내용을 자동으로 읽을 수 없습니다. 이 두 가지 문제점을 해결하기 위해 어려 해결책이 있지만 스프링의 ReloadableResourceBundleMessageSource이 쉽고 편합니다.

import org.springframework.context.support.ReloadableResourceBundleMessageSource;

ReloadableResourceBundleMessageSource bundle = new ReloadableResourceBundleMessageSource();

bundle.setBasename("config"); // config.xml, config.properties 등의 파일을 찾도록 설정
bundle.setCacheSeconds(60); // 1분 단위로 설정 파일 변경 여부 검사

bundle.getMessage("greeting", new String[] {"cybaek"}, null); // 세 번째 인자는 Locale

config.xml 번들 파일입니다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties version="1.0">
 <entry key="greeting">Hello {0}!</entry>
</properties>

참조:
스프링 레퍼런스: http://static.springframework.org/spring/docs/2.5.x/api/index.html
스프링 소스: spring-framework-2.5.1/test/org/springframework/context/support/ResourceBundleMessageSourceTests.java

순수한 OOP를 추종하는 사람들은 AOP 기술을 그리 달가워하지 않습니다. 대표적인 것이 메소드의 리턴값을 가로채어 다른 값으로 바꾸는 것입니다.

methodA()를 호출했고 디버거에서 분명히 "abc"를 리턴하는 것을 확인했는데 결과 값이 "ABC"라면 코드를 읽는 사람은 답답할 것입니다. 이런 상황은 아마도 다른 사람에게서 코드를 인수했을 때 많이 발생할 듯 합니다.

이런 혼란 때문에 AOP를 쓰더라도 프로그램 로직에 영향을 주지 않는 선까지만 적용하자는 의견이 있습니다. 그런 주장을 하는 사람들이 드는 예로 프로파일링을 위한 메소드 수행 시간 측정, 디버깅 등을 위한 로깅 등이 있습니다.

그렇다면 과연 이렇게 로직에 영향을 주지 않는 곳에만 써야 좋을까요? 아래 트랜잭션을 처리하는 자바 코드가 있습니다.

public void 계좌이체(long 금액) {
    dbCtx.begin();
    try {
        출금(금액);
        송금(금액);
    }
    catch(Exception ex) {
        dbCtx.rollback();
        return;
    }
    dbCtx.commit();
}

대개 이와 같은 코드를 작성합니다. 특히 빨간 코드는 트랜잭션 처리를 위해 들어간 코드입니다. 이것을 스프링 프레임워크의 자바 주해(annotation) 기능을 이용한 AOP를 적용하면 다음과 같이 간결하게 바꿔 쓸 수 있습니다.

@Transactional
public void 계좌이체(long 금액) {
    출금(금액);
    송금(금액);
}

이 코드에는 로직에 관여하는 AOP를 적용했습니다. 하지만 코드를 읽는데 혼란은 거의 없습니다. 이렇게 코드에 명백히 드러난다면, 로직에 관여하는 AOP라도 충분히 쓸만하다고 생각합니다.
 

후배와 나눈 이야기를 정리해서 올려봤습니다.

스프링 프레임워크가 2.0으로 넘어가면서 레퍼런스 양도 늘었습니다. 그 중에서도  Resource 클래스에 대해 집중적으로 설명한 ch4 Resources 가 단연 돋보입니다.

자원을 읽을 때 클래스패스에 있는 파일을 이용할 수도 있고, 절대 패스를 지정할 수도 있고, 바이트 배열로 받을 수 도 있습니다.

이런 다양한 접근 방법을 추상화한 결정체가 Resource 클래스입니다.

자바의 기본 객체처럼 유용한 클래스입니다. 실 사용예는 다음에 소개하도록 하겠습니다.

처음에는 @를 이용한 주해(annotation) 기능이 신선하여 좋았지만, 방금 이클립스 생성한 코드를 보니 왜 주해를 써야 하는지 모르겠습니다.

이클립스가 자동으로 생성한 코드:

public class OfficeToHtmlConfigTest {

 @Test
 public void testGetTempDir() {
  fail("Not yet implemented");
 }

Junit3를 썼을 때 코드:

public class OfficeToHtmlConfigTest {
 public void testGetTempDir() {
  fail("Not yet implemented");
 }

오히려 JUnit4를 썼을 때 "@Test" 다섯 글자 더 늘었습니다. ^^ JUnit3를 쓰던 습관이 있어서 테스트 메소드 이름을 test로 시작해야 마음이 편한 것을 어쩌겠습니까. ^^

레일즈를 필두로 CoC(Convention Over Configuration)가 대세인데 오히려 이런 주해(annotation)는 요즘 추세에 거꾸로 가는 것이 아닐까요?

그렇다고 JUnit4로 넘어갈 필요가 없다는 것은 아닙니다. ^^

지름길로 빠르게 배울 수 있는 자바 프로그래밍
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=1806437
TDD로 설명합니다. 즉 TDD를 자연스레 체득할 수 있고 TDD를 하니 JUnit은 덤으로 따라옵니다. ^^ 번역서 제목이 약간은 유치해보이지만 기본 서적 중에 단연 으뜸입니다.

절판됐지만 정보문화사에서 번역한 Beginning Java Objects도 추천합니다. 원서는 2판이 나왔습니다.


실용주의 프로그래머를 위한 단위 테스트 with JUnit
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=1428559
앞에 책을 성실히 따라 했다면 이 책은 하루면 다 볼 수 있습니다. JUnit3를 다뤄서 최신 버전과 맞지 않지만 기본은 어디서나 통합니다.


실용주의 프로그래머를 위한 프로젝트 자동화 : 빌드, 디플로이, 모니터링
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=1477082
개발할 때는 개발만 보이지만, 개발보다 긴 것은 운영입니다. 오픈소스를 이용하여 효율적으로 운영하는 법을 설명합니다. 이 책 역시 집중해서 보면 이틀 정도면 다 볼 수 있습니다.


실전 코드로 배우는 실용주의 디자인 패턴
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=2127215
일반적으로 디자인패턴 책은 패턴 카탈로그를 설명하는데 치우쳐 있지만 이 책은 실제로 어떻게 쓰는지 설명해줍니다. '이 패턴은 이렇게 인터페이스 만들고 이렇게 상속하고 이렇게 구현하지 않으면 그 패턴이 아닐거야'란 강박관념에서 벗어날 수 있습니다. 이 책의 백미는 책 뒤에 정리해놓은 패턴 요약집입니다.

절판된 책 중에 영진출판사에서 나온 일어 번역서 '자바 언어로 배우는 디자인 패턴 입문'도 쉽고 재밌습니다. 일본인 특유의 분석적인 내용이 우리 입맛에 맞습니다.


expert one-on-one J2EE 설계와 개발
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=428809
자바 세상의 구세주, 불세출의 영웅, 스프링 개발자, 스프링소스의 CEO 로드 존슨이 쓴 책입니다.  시간이 없다면 이 책의 4장만 읽어도 그 감동을 충분히 느낄 수 있습니다.

이 책을 읽고 스프링에 관심이 생겼다면 ProSpring을 권해드립니다. 조만간 ProSpring2가 나오니 조금 기다려 보는 것도 좋겠지요?

자카르타 커먼스(commons.lang) 패키지에 유용한 것이 많습니다. 그 중에 당장 쉽게 쓸 수 있는 것으로 ReflectionToStringBuilder가 있습니다.

문자열 덧셈 혹은 StringBuilder의 append를 호출해서 만드는 toString 작업을 한 줄로 해결할 수 있습니다.

import org.apache.commons.lang.builder.ReflectionToStringBuilder;

@Override
public String toString() {
 return ReflectionToStringBuilder.toString(this);
}

클래스 패스에 있는 파일을 읽는 방법(ClassLoader, Class, ResourceBundle)은 많습니다. 반면에 그렇게 읽은 파일의 절대 경로를 구하는 방법은 찾기 쉽지 않았습니다.

아래 스프링에 있는 ClassPathResource를 이용한 코드 조각이 있습니다.

import java.io.File;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.Resource;

Resource r =
  new ClassPathResource("com/cybaek/test/core/hello.doc");
File f = r.getFile();
String path = f.getAbsolutePath();

스프링 프레임워크 개발팀에서 사용하는 코딩 컨벤션 파일입니다. 이클립스를 쓰고 계신다면 바로 내려받으세요. 다음 링크 맨 아래에 있습니다.

http://www.springframework.org/development