7. 디버깅하기
일반적으로 디버깅은 어느 순간 어떤 메소드에 전달된 파라미터의 값이 무엇인지 알고 싶을 때, 제어문이 도대체 어떤 순서로 수행되는지 알고 싶을때, 혹은 어떠한 논리적인 오류는 없는지 확인하기 위해 사용한다.
디버깅을 하기 위해서는 컴파일 에러가 발생한 지점 근처나 에러의 근원지라고 의심이 되는 부분에 미리 표시를 해두어야 한다. 디버깅 실행을 하면 이클립스는 이런 표시가 있는 부분에서 잠시 정지하여 프로그래머가 각종 변수의 현재 상태를 파악할 수 있도록 해준다.
위에서 작성했던 예제로 디버깅을 해보도록 하겠다.
디버깅 과정을 통해 우리는 sayHello에서 인사말 출력을 위해 사용하는 m_to라는 변수에 “Kim”이란 올바른 값이 저장되어 있는지 확인하고자 한다.
먼저 26라인에서 줄번호가 보이는 공간에서 오른쪽 마우스 버튼을 클릭하면 다음과 같은 팝업 메뉴가 보일 것이다. 여기서 [Add Breakpoint]를 선택하도록 한다. 선택하고 나면 하늘색 마크가 보일 것이다.
도구모음에서
을 선택하면 자바 perspective에서 자동으로 디버그 perspective로 변경되고, 좀전에 표시한 지점까지 실행이 되며 breakpoint 지점에서 대기하고 있음을 알 수 있을 것이다. 다음 그림에서 보는 바와 같이 우측 상단의 [variables 뷰]를 통해 현재 m_to 변수가 String 타입이며 그 값은 “Kim”이란 사실을 알 수 있다. 더 이상의 자세한 디버깅 요령에 대해서 아직은 나도 잘 모르기 때문에 여기까지만 설명하고 차후에 더 자세한 내용을 익히게 되면 다시 설명할 기회가 있겠지? ^^
8. 프로젝트에 기존의 클래스를 추가하기
항상 클래스를 새로 만드는 것은 아니며 기존의 클래스 파일을 그대로 가져다가 쓰거나, 혹은 어떤 클래스 파일을 테스트해 보기 위해 프로젝트에 포함시킬 수도 있다. 본 예제에서는 “퍼포먼스 튜닝”의 예제 파일 중 일부를 TestProject에 추가해 보도록 하겠다. 이 예제 파일은 “F:STUDYeclipse_test”에 저장되어 있다고 가정하며, 디렉토리 구조는 다음과 같다.
참고로 이 클래스(PrintWrapper, Dict)는 각각 tuning.console, tuning.dict로 패키지화 되어있다.
이 두 클래스를 TestProject에 추가하도록 하겠다. 먼저 [package 뷰]에서 TestProject를 선택하고 오른쪽 마우스 버튼을 클릭하여 [Import] 메뉴를 선택한다. 그러면 아래의 왼쪽 그림과 같은 대화상자가 뜨는데, 여기서 [File System]을 선택하면, 오른쪽과 같은 대화상자가 뜬다.
이 상태에서 [Directory]의 [Browse...]버튼을 눌러서 “F:STUDYeclipse_test”를 선택한 후, 모든 클래스 파일을 체크하도록 한다. 다음 그림을 참고한다.
위의 두 클래스 파일이 포함된 결과 화면은 다음과 같다.
그런데, 위와 같이 임포트를 한 결과를 잘 살펴보면 “F:STUDYeclipse_test”에 있던 클래스 파일들이 “<이클립스설치홈>/workspace/TestProject” 아래에 그대로 복사된 것을 알 수 있을 것이다. 이런 식으로 복사해오는 것이 기본 설정이기 때문에 이렇게 작동을 하는 것인데, 만약에 규모가 꽤 큰 패키지를 임포트하는 경우라면 공간의 낭비가 아닐 수 없을 것이다.
이런 문제를 해결하기 위해 실제로 클래스 파일을 “이클립스 워크스페이스”로 복사하지 않고, 원본은 원래 위치에 그대로 두고 단지 경로 정보만 참조해서 프로젝트를 만들 수도 있다. tuning.XXX 패키지를 임포트하기 위해 TuningTest라는 프로젝트를 새로 만들어보자. 처음에 프로젝트를 생성했던 방법대로 하면 되지만, 한가지 다른 점은 다음처럼 프로젝트 경로명에서 [Use Default]를 언체크하고 임포트하려는 실제 경로를 선택해야 한다.
위와 같이 제대로 선택을 한 후, 더 이상 [Next]할 필요없이 [Finish]버튼만 누르면 프로젝트 생성이 완료된다.
TuningTest 프로젝트에서 오른쪽 마우스 버튼을 눌러 [Properties]를 선택하면 다음과 같은 정보창이 보일 것이다.
[Location] 정보를 보면 이클립스 워크스페이스가 아닌 원래 tuning 패키지의 위치를 참조하고 있음을 알 수 있을 것이다.
NOTE!!
지금까지로는 한 프로젝트에 여러 경로의 클래스 파일을 참조할 수는 없는 것으로 보인다. 즉, 어떤 클래스는 이클립스 워크스페이스에 있는 것을 참조하고, 다른 클래스는 외부 경로만 참조해서 프로젝트에 추가하는 것은 안되는 것이다. 만약 나중에 되는 방법을 알게 되면 수정토록 하겠다. 그런데, 굳이 이렇게 안되도 별로 상관은 없을 것 같기는 하지만 ^^;;
9. ANT 사용하기
이제부터는 ANT를 사용하는 방법을 알아본다. 우선 ANT를 실행시키려면 build.xml 파일이 있어야 한다. 나같은 경우 ServletStudy라는 프로젝트를 생성한 후, 챕터별로 SourceFolder를 생성하고 각 소스 폴더별로 소스 파일을 관리했다. 그 모양새는 다음과 같다. 각 소스 폴더별로 build.xml과 web.xml 파일이 존재한다.
왼쪽 그림에서 보는 바와 같이, build.xml 파일에서 마우스 오른쪽 버튼을 클릭하면, [Run Ant...]라는 메뉴를 볼 수 있다. 단순히 이 메뉴를 선택하면 다음 그림과 같은 대화상자가 보인다.
여기서 build.xml의 여러 타겟(target) 엘리먼트들 중에서 특정 타겟을 선정해야 하고 [Finish]버튼을 누르면 ANT 실행이 이루어진다.
그러나 두가지 정도 주의할 점이 있다.
하나는 ANT를 실행시키면 다음과 같은 에러 메시지가 뜰 수 있다.
이 에러 메시지를 살펴보면, 컴파일러를 찾을 수 없으니 JAVA_HOME 환경변수 설정을 제대로 했는지 확인하라고 한다. 그러나 실상 이 문제를 해결하려면 다른 방법으로 해야한다. 백날 시스템의 JAVA_HOME을 수정해밨자 아무 상관이 없다.
우선 메인 메뉴인 Windows -> Preferences -> External Tools -> Ant를 선택하면 다음과 같은 대화상자가 보일 것이다.
위의 문제를 해결하려면 [Classpath]탭에 J2SDK의 tools.jar 파일이 포함되어 있어야 한다. 네모 안에 있는 항목을 [Add Jar...]버튼을 눌러서 추가하도록 한다.
그리고 나서 다시 [Run Ant...]메뉴를 실행시켜 보자. 잘 될 수도 있고, 아닐 수도 있는데, 아마도 제대로 안된 경우라면 컴파일 에러가 발생할 것이다. 아마도 servlet과 COS에 관련된 클래스들을 찾을 수 없다는 메시지들일 것이다.
아직 정확한 이유는 모르겠지만 ANT를 이용해서 컴파일을 할 경우, 시스템 전역에 걸려있는 클래스패스는 별 의미가 없는 것으로 보인다. build.xml 파일 내에 컴파일 시에 정확한 클래스패스가 모두 명시되어 있어야 한다. 다음과 같이.
<property name="cp" value=".;D:/jakarta-tomcat-4.0.4/common/lib/servlet.jar;D:/jakarta-tomcat-4.0.4/common/lib/cos.jar"/>
<target name="compile" depends="init">
<mkdir dir="${build}"/>
<javac srcdir="${src}" destdir="${build}" classpath="${cp}"/>
</target>
10. JavaDoc 생성하기
자바 헬프 문서를 생성하는 것은 더욱 간단하다. 디렉토리나 프로젝트 혹은 클래스 파일에서 오른쪽 마우스 버튼을 클릭하여 [Export] 메뉴를 선택한다.
왼쪽 그림과 같은 대화상자가 보이면, [javadoc]을 선택하고 [Next>]버튼을 클릭한다.
왼쪽 그림처럼 자바 헬프 문서로 만들고 싶은 자바 소스 파일을 선택하고, 자바 문서를 생성할 디렉토리 경로도 지정한다.
그냥 [Finish]만 눌러줘도 충분하다.
다른 옵션들을 더 보고 싶으면 계속 [Next]버튼을 눌러서 확인해 보도록.
이로써 자바 문서 생성도 완료되었다. ^^...
이렇게 자바 헬프 문서로 export하는 것 외에, JAR 파일로 export할 수도 있다. 방법은 간단하므로 설명을 생략한다.
한가지 언급하고자 하는 기능 중에 “삭제 파일 되돌리기” 기능이 있다. 이클립스 상에서 실수로 파일을 지운 경우 윈도우즈 휴지통에는 흔적이 남지 않기 때문에 정상적인 방법으로는 복구가 불가능하다. 게다가 이클립스는 파일을 지울 때, 별달리 경고도 없이 보통은 그냥 지우는 경향이 강하다. 하지만 이런 위험천만한 스타일이 가능한 이유가 있었다. 처음에는 몰라서 잘못 지운 파일을 다시 코딩하는 우를 범했는데, 알고 보니 이클립스 자체적으로 이러한 파일들에 대한 히스토리를 관리하고 있었다. 즉, 자체적으로 휴지통 기능 혹은 되돌리기 기능이 있는 셈이었다.
[package 뷰]에서 디렉토리나 패키지, 혹은 파일을 선택한 후에, 오른쪽 버튼 클릭으로 팝업 메뉴를 띄워보면 [Restore from Local History]라는 메뉴가 있다. 이 기능을 선택하면 처음부터 지금까지 지워졌던 기억이 있는 모든 기록들이 시간별로 쫘악 정리되어 있는 것을 볼 수 있다. 그 중에서 어느 것이 내가 원하는 시점의 파일인지 파악한 후, 복구하고자 하는 적당한 파일들을 체크하고 [Restore] 버튼을 클릭하면 된다. 이 기능이 없다면 정말 피말리는 사건들이 자주 생길 것이다. ^^ 다음의 화면은 참조하기 바란다.
11. 기타 유용한 기능들
1. Organize Import / Add Imports
보통 import java.io.*; 이런식으로 임포트를 하게 되는데, 코딩을 다 끝낸 후에 Organize import 기능을 사용하면 소스 상에서 실제로 사용한 클래스들만을 임포하도록 import 문장을 수정해 준다. 예를 들어,
2. Code Formatter
코딩 스타일을 상세하게 지정할 수 있어서 자신의 코딩 스타일을 그대로 사용할 수 있고, 소스 Formatter 기능이 있어 뒤죽박죽되어 있는 소스를 자신이 익숙한 스타일로 한꺼번에 변경할 수 있다.
3. Refactor
클래스 이름을 수정하거나 패키지가 변경되면, 그 클래스를 참조하고 있던 다른 모든 클래스까지도 자동으로 수정을 해서 소스 관리가 자동으로 이루어진다.
4. 코딩 중 실시간 문법 검사 및 해결책 제시
코딩 중에 실시간 문법 검사를 하며, 문제가 발생하면 가능한 해결책을 여러 가지 제시한다. 여러 가지 해결책을 직접 입력할 필요도 없으며 단지 그 해결책이 나열된 팝업 메뉴 중에서 한 가지를 선택하면 스스로 수정해준다.
5. 코드 어시스트
다른 툴에도 존재하는 기능이며, MS의 비쥬얼 스튜디오보다는 약간 사용하기 불편하지만 그래도 꼭 필요한 기능이며, 코딩 속도를 높여주고, API 문법을 빠삭하게 외우지 않아도 코딩이 가능하도록 해준다. 기본적으로 .(점)을 누르고 500 밀리초 후에 어시스트 팝업이 뜨도록 되어있는데, 이는 너무 느린것 같고 개인적으로는 100 밀리초로 설정하여 사용하고 있다.