IDE의 비교 쇼핑

얼마나 많은 시간을 들여 IDE를 사용하는지를 고려하면 어느 IDE가 최고인지에 대해 강한 의견을 갖게 된다. 일부 프로그래머들은 Emacs가 지난 세기부터 내려온 별난 유물이라고 생각할 수 있는 반면, 다른 프로그래머들은 자신들의 차가운 죽은 손가락이 키보드를 두드릴 때가 될 때에만 이를 포기할 것이다. 하나의 IDE는 독자를 더 생산적으로 만드는 정도까지만 다른 IDE보다 나으며, 20년 동안 Emacs로 C를 코딩한 프로그래머에게는 그것이 생산적인 환경이다.

Java 언어가 상대적으로 젊기 때문에 특정 개발 환경에서 존재하는 긴 코딩 유산은 존재하지 않는다(적어도 아직까지는 없다!). 다양한 각 Java IDE의 인기는 새 기능을 제공하고 성능을 개선하며 사용하기에 더 간편해지기 위한 경주에서 성쇠를 보이는 경향이 있다. 가장 흥미로운 새 개발은 두 가지 무료의 확장 가능한 오픈 소스 IDE인 Netbeans와 Eclipse를 소개하는 것이었다. 이는 상업용 오퍼링의 기능에 빠르게 접근하고 있다. 대부분의 개발자들은 이 두 가지 탁월한 개발 플랫폼이 제공하는 것 이상으로 필요하지 않을 것이다.

위로

Netbeans와 Eclipse 비교하기

이러한 두 가지 IDE의 가장 최신 버전은 -- Netbeans 3.6 및 Eclipse 3.0 -- 차이점보다 유사성이 훨씬 더 많다. 이는 둘 다 구문 검사, 코드 완성 및 코드 폴딩을 보유한다. 이는 둘 다 독자가 코드를 컴파일하고 실행하며 디버그할 수 있다. 이는 둘 다 Ant, CVS 및 JUnit를 지원한다. 또한, 둘 다 이제 GUI 빌더를 통합했다. 비록 Eclipse에서는 별도로 다운로드해야 하는 개별 컴포넌트인 Visual Editor이지만 말이다. Eclipse Visual Editor에 대한 자세한 정보는 이 기사의 후반부에서 참고자료 섹션에 나열된 "Building GUIs with the Eclipse Visual Editor"를 참조한다.

두 가지 IDE의 주된 차이점은 Netbeans가 웹 개발 지원을 통합하지만 Eclipse는 통합하지 않는다는 것이다. 그리고 Eclipse는 리팩토링을 자동화했지만 Netbeans는 자동화하지 않는다. 하지만 이 점이 중요하다고 하더라도 특정 기능의 부재가 결정적인 요인이 될 필요는 없다. 이러한 IDE 둘 다 플러그인을 사용하면 확장 가능하기 때문에, 차이를 메우기 위해 사용 가능한 무료이거나 저렴한 플러그인을 찾게 될 것이다. Tomcat으로 Struts 및 웹 애플리케이션을 개발하기 위한 플러그인을 확보하고 설치하며 사용하는 방법을 보여주는 기사는 참고자료 섹션에 나열된다.

많은 프로그래머들은 사용 편의성을 이유로 Eclipse를 선호한다. 즉, Eclipse의 전체적인 설계는 독자가 즉시 필요한 도구를 당장 사용하도록 유지한다. 또한 많은 프로그래머들은 Eclipse가 더 빠르고 더 안정적이라고 생각한다. 하지만 이러한 속성은 측정하기에 어렵기 때문에, 독자가 스스로 체험해보고 Eclipse가 Java 프로그래밍을 더 빠르고 간편하게 만드는지 여부를 판단해야 한다.

위로

Perspective의 문제

수영을 할 때 가장 어려운 단계는 뛰어드는 것을 결정하는 것일 수 있다. 물이 차가울 것이라는 것을 알지만, 이러한 느낌이 빠르게 사라지는 것도 알고 곧 편안해질 것이다. 마찬가지 방법으로 Eclipse로 처음 작업을 시작할 때, 사용자 인터페이스가 제한된 옵션 세트로 인해 다소 불편하다고 느낄 수 있다. 어떻게 시작하는가? Eclipse 사용자 인터페이스 또는 워크벤치는 Perspective의 개념을 기반으로 하며, Eclipse를 효율적으로 사용하기 전에 이러한 개념을 먼저 이해해야 할 것이다.

많은 대규모 컴퓨터 애플리케이션과 같이 Netbeans는 다른 태스크를 수행할 수 있는 다양한 창을 많이 사용한다. 시작할 때, 화면의 맨 위 왼쪽에 Filesystems 창을 통해 자원을 프로젝트로 추가하여 열 수 있고 오른쪽의 기본 창은 편집을 위한 것이다. 출력 창과 같은 더 많은 창들은 필요한 대로 자동으로 열리거나 다른 태스크를 수행하기 위해 열도록 선택하여 열린다.

Eclipse는 창의 여러 배치를 허용하여 이러한 기본 개념에서 빌드한다. 중앙 집중화된 코드 저장소에서 이를 사용하여 코딩, 디버깅 또는 코드 변경 병합과 같은 다른 태스크를 수행하면서 해당 태스크에 특별히 선택된 창의 배치를 사용할 수 있다. 이러한 태스크별 창 배치를 Perspective라고 한다. 보기 외에도 각 Perspective는 적절하게 다른 도구 단추와 메뉴 선택을 보유할 수 있다.

초기 시작 화면을 닫을 때 Eclipse를 시작하는 기본 Perspective는 다음 그림 1과 같이 Resource Perspective라고 한다.

Netbeans와 같이 Resource Perspective는 Navigator라고 하는 자원을 탐색하고 관리할 수 있는 맨 위 왼쪽의 트리 지향 창이 있다. Eclipse의 대부분의 창과 마찬가지로 이 창은 보기라고 한다. 처음에 Resource Perspective에 다른 두 가지 보기가 있다 -- Navigator 아래 Outline 보기 및 기본 편집기 영역 아래 Task 보기.

Eclipse는 보기와 편집기 사이에 구별한다. Perspective는 보기를 많이 가질 수 있지만 편집기는 워크벤치의 중앙점인 하나의 편집기만 가질 수 있다. 일반적으로 말해서, 편집기에서 파일을 여는 경우 다른 보기는 해당 파일의 다른 측면을 반영한다. 만약 이는 Java 파일이고 Java Perspective에 있으면 하나의 보기인 Package Explorer는 실제로 파일과 패키지 계층 구조에서의 위치를 보여준다. 그리고 다른 Outline 보기는 (다른 무엇보다도) 클래스의 메소드 및 속성을 보여준다. 여러 Java 파일이 있는 경우, 이러한 보기는 편집기에서 다른 파일들 사이에 전환하는 대로 변경한다.

비록 새 Perspective를 열고 이들 사이에 전환하는 것이 간편하지만, 독자가 작업하면서 적절할 때 Perspective가 자동으로 변경하기 때문에 일반적으로 필수는 아니다. (물론 Eclipse에서 먼저 독자가 허락하는지 묻는다.) 우리가 Java 프로젝트를 작성하고 나중에 Java 프로그램을 디버그할 때 곧 이를 확인할 것이다. Perspective를 사용하는 데 익숙해지면 Perspective가 UI 도구에서 당면한 문제에 적절하지 않은 단추, 메뉴 및 보기를 삭제하기 때문에 Perspective가 작업하기에 원활하고 자연스러운 방법임을 알게 될 것이다. 이렇게 하면 관련 도구를 찾는 것이 훨씬 더 간편해진다.

위로

Eclipse에서 새 프로젝트 작성

Eclipse에서 작업을 시작하려면 먼저 프로젝트를 작성해야 한다. Eclipse 및 Netbeans 둘 다 단어 "프로젝트"를 사용하여 파일과 다른 자원을 구성하는 기본 방법 중 하나를 설명하지만, 이들은 기본적으로 다른 것을 가리킨다.

Eclipse에서 단어 "프로젝트"의 사용을 이해하려면 Eclipse가 작업공간이라는 디렉토리와 연관되었음을 먼저 이해하는 것이 중요하다. 처음 Eclipse를 시작할 때, 이 디렉토리의 위치에 대한 프롬프트가 표시되고(이를 명령행 옵션으로 지정하지 않는다고 가정함) 존재하지 않는 경우 Eclipse에서 독자를 위해 이를 작성한다. 기본값으로 모든 정보가 -- 일부 Eclipse별 정보, 독자의 Java 소스 및 클래스 파일, 이미지 및 기타 등등 -- 이 디렉토리에서 서브디렉토리나 폴더에 저장된다. 이 디렉토리의 각 폴더는 하나의 프로젝트에 해당하고 일반적으로 독립형 애플리케이션, 웹 애플리케이션 또는 일부 유형의 컴포넌트가 들어있다.

더 잘 구성되게 유지하기 때문에 작업공간을 사용하는 것이 권장되지만, Eclipse 3.0은 프로젝트 폴더로 사용하기 위해 기존 작업공간 외부에 기존 디렉토리를 지정하거나 작성하는 기능을 제공한다. 이는 엄격하게 구성된 디렉토리 구조를 장려하지 않는 다른 IDE에서부터 마이그레이션하고 있는 경우 특히 유용할 수 있다.

위로

코딩을 시작하자

독자가 따라해 보려고 하고 아직 Eclipse를 시작하지 않았다면 이제 시작하자. 아직 Eclipse를 설치하지 않았다면 참고자료에 나열된 "Eclipse Platform 시작하기" 기사를 참조할 수 있다. 최초로 Eclipse를 실행할 때, 시작 화면이 표시된다. 이를 통해 튜토리얼과 다른 흥미로운 항목으로 이르게 되지만 지금은 맨 위 탭에서 "X"를 클릭하여 닫는다. 나중에 기본 메뉴에서 Help > Welcome을 선택하여 이 화면으로 다시 돌아갈 수 있다.

그림 1과 같이 Resource Perspective가 표시되었을 것이다. Eclipse에서는 항상 작업하는 방법이 하나 이상 있지만 -- 단축키, 도구 모음 또는 메뉴 선택 사용 -- 이 기사 전체에서는 일반적으로 메뉴를 사용할 것이다. 여기에서 다음과 같이 컨텍스트 메뉴를 사용하여 프로젝트를 작성할 것이다.

• Resource Perspective에서 Navigator 보기를 마우스 오른쪽 단추로 클릭하고 New>Project를 선택한다.
• New Project 마법사에서 Java Project를 선택한다.
• 프로젝트의 이름은 예를 들어, "Hello"를 입력한다.
• Location 섹션에서 프로젝트를 외부 위치에서 작성하기 위한 옵션이 있음을 인식한다. 하지만 기본값 "Create project in workspace"를 수락한다.
• 또한 Project Layout 섹션에서 기본값 선택인 "Use project folder as root for sources and class files"를 수락한다. 일반적으로 개별 디렉토리를 사용하는 것이 더 낫지만(대개 src 및 bin), 지금으로서는 단순하게 유지하고 기본값을 수락할 것이다.
• Next를 클릭하면 라이브러리를 구성할 수 있고 이 프로젝트가 의존하는 클래스 경로로 다른 프로젝트를 추가할 수 있지만, 우리는 그렇게 할 필요는 없다. 대신에 Finish를 클릭한다.
• 잠시 후에 Eclipse에서 "This kind of project is associated with the Java Perspective. Do you want to switch to this perspective now?"라는 질문이 표시된다. "Remember my decision"으로 표시된 상자를 선택하고 Yes를 클릭한다.

이제 프로젝트가 있으니 클래스를 작성할 수 있다. 우리는 표준 Hello, world 프로그램의 변형을 작성할 것이다.

• Hello 프로젝트를 마우스 오른쪽 단추로 클릭하고 New>Class를 선택한다. 이렇게 하면 New Class 마법사가 표시된다.
• 패키지 이름으로 com.example.hello를 입력한다.
• 클래스 이름으로 HelloObject를 입력한다.
• java.lang.Object를 수퍼클래스로 둔다.
• main() 메소드에 대한 스텁을 작성하는 옵션이 선택되었는지 확인한다.
• Finish를 누른다. (그림 2 참조.)

이 클래스를 작성한 후에 수많은 다양한 내용을 인식하게 된다. 먼저, 몇 가지 "TODO" 항목이 파일에 나타나 주석을 생성하는 템플리트를 사용자 정의할 필요성을 표시한다. 이는 책갈피, 중단점 및 구문 문제와 같은 다른 어노테이션과 마찬가지로 편집기의 왼쪽 여백에 하나의 기호로 표시된다. 나중에 방향에 따라 이 주석에 대한 코드 템플리트를 수정해야 하지만 지금은 있는 그대로 남겨둔다.

또한 왼쪽 열에서 각 기호에 해당하는 것이 오른쪽 열에서 동일한 색상의 작은 상자라는 점을 인식하자. 왼쪽 여백이 현재 편집기에서 보이는 것만 표시하는 반면, 오른쪽 여백은 파일에 표시된 모두를 보여준다. 끝부분에 오류가 있는 긴 파일이 있다면, 파일의 어느 부분이 편집기에서 표시되고 있는지에 관계 없이 오른쪽 여백의 맨 아래 작은 빨간 상자가 될 것이다. 이를 클릭하면 오류로 안내할 것이다.

맨 왼쪽 여백에서 선택 표시 기호 외에도 이 오른쪽으로 열에서 작은 삼각형이 있다. 이는 코드 폴딩을 제어하는 더하기 및 빼기 부호에 해당한다. 클래스 정의가 주석을 삭제하는 선행하는 주석 바로 옆에 첫 번째 삼각형을 클릭하여 생략 부호로 대체하며, 다음 그림 3과 같다.

참고: Eclipse에서 코드로 작업하면서, 왼쪽 여백에서 어노테이션과 코드 폴딩 제어 사이에 또 다른 열을 인식할 것이다. 이는 편집기의 현재 코드와 해당 코드의 이전 버전을 비교할 수 있는 색상 막대가 들어있다. 이 기능은 QuickDiff라고 하며, 나중에 이를 스스로 탐색하려 할 수 있다.

이제 일부 코드를 추가할 것이므로 흥미롭게 작업할 내용이 있다. names라는 Vector를 작성하는 main() 메소드로 행을 추가한다. Vector 유형을 가져오지 않았으므로, 다음 그림 4와 같이 왼쪽 여백에 "X"가 있는 빨간색 상자와 노란색 전구를 결합한 기호가 있을 것이다.

물론 "X"는 문제점이 있음을 의미하지만 전구는 Eclipse에 QuickFix가 있음을 의미한다. 즉, 이는 문제를 해결하기 위한 하나 이상의 제안이다. 전구를 클릭하거나 Vector를 클릭하고 Ctrl-1(QuickFix 단축키)을 클릭한다. 팝업이 "Import Vector," "Rename in File" 및 "Create Class Vector"를 비롯한 가능한 수정사항을 나열하며 표시될 것이다. Eclipse가 추가한 중요한 명령문을 보기 위해 첫 번째 제안을 두 번 클릭할 수 있다.

Eclipse에 대한 흥미로운 사항은 독자가 입력하면서 코드를 컴파일하기 위해 증분 컴파일러를 사용하는 점이다. 구문 오류가 있으면, 코드를 올바르게 해석할 수 없을 것이고 QuickFix를 제공할 수 없을 것이다. 예를 들어, 위의 중요한 문제점을 수정하지 않지만 대신에 다음 행에서 이름을 계속 입력한다면, 이름은 구문 오류를 표시하는 빨간색 곡선으로 밑줄 처리되지만, 맵이 정의한 이전 행에 문제점이 있음을 더 이상 표시하지 않을 것이다.

마우스 포인터를 이와 같은 구문 오류에 대고 있으면 문제점을 설명하는 풍선 팁이 표시된다. 이 경우에 이는 세미콜론이 필요한 불완전한 명령문임을 표시한다. (이는 물론 누락된 내용이 전부 나온 것은 아니지만 시작이다.) 이를 기능으로 고려할 수 있다. 즉, 이는 진행하면서 오류를 수정하도록 권장한다. 물론 이렇게 할 필요는 없지만, 하지 않는다면 Eclipse를 가능한 효율적으로 사용하지 않을 것이다.

Vector를 제대로 가져오도록 한 다음에 이름을 입력하여 다시 새 행을 시작한다. Vector 이름에 항목을 추가하기 위한 적합한 메소드를 찾기 위해 코드 완성을 사용할 수 있다. Eclipse에서 코드 완성은 Netbeans에서 하는 것과 완전히 동일하게 작업한다. 즉, 유형 또는 ID의 첫 부분을 입력한 후에 Ctrl-Space를 누르면 옵션 목록이 표시된다. 여기에서 이는 필요한 메소드의 이름을 잊어버렸다면 특히 유용하다 -- put()인가 add()인가?

물론 이는 원하는 add()이고 목록에서 단일 매개변수 버전을 선택한 후에 Eclipse가 메소드 이름을 완성할 뿐만 아니라 열기 및 닫기 소괄호도 추가하고, 소괄호 내에 정규 커서를 놓으며 닫기 소괄호 이후에 초록색 선(커서와 유사함)도 그리는 것을 인식할 것이다. Eclipse에서 코드를 입력하면서 이 초록색 선을 자주 보게 될 것이고, 명백한 효과 없이 이를 간단히 무시할 수 있는 반면 현재로서는 분명히 설명할 가치가 있다. 나중에 자체 코드 완성 템플리트를 쓰는 경우(Eclipse에서는 수행하기에 매우 간단한 것), 이 기능을 활용하려 할 것이다.

초록색 선은 삽입 지점이고 Tab 키를 눌러 해당 위치로 커서를 이동할 수 있다. add()에 대해 인수를 추가한 후에, 추측하건대 코드나 세미콜론을 더 추가하기 위해 소괄호를 지나 이동하려 할 것이기 때문에 여기에 제공된다.

하드코드된 문자열 "Moe"를 names Vector에 추가한다. 열기 따옴표를 입력할 때, Eclipse는 유용한 닫기 따옴표를 제공하며 커서를 두 개의 따옴표 사이에 이동하고 닫기 따옴표 이후에 새 삽입 지점을 제공한다. Moe를 입력한 후에 Tab을 눌러 닫기 따옴표를 지나 이동한다. 닫기 소괄호 이후에 첫 번째 삽입 지점이 이제 다시 나타난다. Tab을 다시 눌러 명령문의 끝으로 이동하고 세미콜론을 입력한다.

마찬가지로 두 가지 이상의 이름을 names 벡터인 Curly와 Larry에 추가한다. 코드는 이제 다음과 같다.

			
    public static void main(String[] args) {
        Vector names = new Vector();
        names.add("Moe");
        names.add("Curly");
        names.add("Larry");
        }
    }

Eclipse에서 코드 완성과 관련하여 훌륭한 점 중 하나는 Eclipse가 컨텍스트를 인식하는 것이다. 여기에서 for를 입력하고 Ctrl-Space를 누르면, 컬렉션에 대해 반복하는 몇 가지 옵션 중 하나가 있다. 이를 선택하면 코드가 다음 그림 5와 같이 삽입된다.

Eclipse가 추가한 각 ID의 첫 번째 인스턴스가 상자에 포함되는 것을 인식하자. 이를 변경하는 경우 Eclipse는 표시되는 위치마다 하나씩 걸러서 변경한다. iter을 i로 이름을 바꾸면, 다른 인스턴스도 자동으로 변경한다. 여기에서 반드시 변경해야 할 유일한 것은 유형을 String으로 하는 것이지만, 요소를 이름으로 변경하려 할 수도 있다. 이들 각각 사이에 이동하려면 Tab과 Shift-Tab을 누를 수 있다. 이렇게 변경하고 호출을 as-yet-nonexistent 메소드 greet()로 추가한 후에 코드의 모양은 다음과 같다.

			
        for (Iterator i = names.iterator(); i.hasNext();) {
                String name = (String) i.next();
                greet(name);
        }

그 다음으로 Eclipse의 QuickFix(예를 들어, greet를 클릭하고 Ctrl-1을 누름)를 사용하여 greet()의 메소드 스텁을 생성하고, 다음과 같이 코드를 스텁에 추가한다.

			
    private static void greet(String name) {
          System.out.println("Hello, " + name);
    }

이제 코드에 오류가 없어야 한다. 편집기를 마우스 오른쪽 단추로 클릭하고 컨텍스트 메뉴에서 Save를 선택한다.

위로

프로그램 실행 및 디버깅

언급한 대로 Eclipse는 증분 컴파일러를 사용하므로 Java 파일을 표면적으로 컴파일하는 것이 필수는 아니다. 컴파일된 클래스 파일은 Java 파일을 저장할 때 저장된다. 프로그램을 실행하려면 편집기 또는 Package Explorer에서 Java 파일을 선택한 다음 기본 Eclipse 메뉴에서 Run > Run As > Java Application을 선택한다. (이는 Run > Run... 메뉴 옵션과는 다르다는 것을 인식하자. 나중에 확인할 것이다.) 이는 Editor 아래 Console 보기에서 다음 출력을 작성해야 한다.

			
Hello, Moe
Hello, Curly
Hello, Larry

디버거에서 간단한 프로그램을 실행하는 것은 유사하다. 먼저, 왼쪽 여백에서 두 번 클릭하여(Netbeans와 같이 한 번 클릭이 아님) main() 메소드에서 greet()로 호출에서 중단점을 설정한다. 조건적 중단점을 -- i==2가 true와 같은 특정 표현일 때 중지하는 것 또는 특정 히트 수 이후에 중지하는 것 -- 설정하려면 중단점에서 마우스 오른쪽 단추로 클릭하고 컨텍스트 메뉴에서 Breakpoint 특성을 선택할 수 있다.

디버깅을 시작하려면 기본 메뉴에서 Run > Debug As > Java Application을 선택한다. Eclipse는 Java Perspective보다 디버깅에 더 적합한 Debug Perspective가 있기 때문에, 이러한 Perspective로 변경하려는지 질문할 것이다. "Remember my decision" 상자를 선택한 다음 Yes를 클릭한다. 이는 그림 6에 표시된다.

Debug Perspective에서 대부분의 보기는 비록 Netbeans의 창과 다른 이름을 가질 수 있지만 이러한 창에 다소 익숙해야 한다. Debug 보기(Debug Perspective와 혼동되지 않기 위해)는 호출 스택을 표시하고, Variables 보기는 프로그램의 변수의 현재 상태를 표시하고 Console 보기는 프로그램을 표시한다.

Debug 보기의 도구 모음에서 실행을 제어하기 위해 도구 단추(Step over, Step into 및 기타 등등)가 있음을 인식해야 할 것이다. 이러한 제어가 호출 스택과 함께 여기에 있는 이유는 하나 이상의 프로그램(또는 프로그램의 인스턴스) 또는 여러 스레드로 프로그램을 디버그하고 있으면, 호출 스택에서 이를 클릭하여 제어하기 위해 프로그램 또는 스레드를 선택할 수 있다. 독자가 선호하는 경우, 첫 번째 인스턴스를 종료하지 않고 이 예제 프로그램을 다시 실행하여 이를 통해 흥미롭게 작업할 수 있다.

독자는 때로는 간단한 메뉴 선택 Run > Run As > Java Application을 사용하여 프로그램을 실행하려고 하지 않는다(또는 할 수 없다). 실행하는 프로그램 또는 VM 중 하나로 인수를 전달해야 하는 경우, 대신에 Run > Run... 메뉴 옵션을 사용해야 할 것이다. 이렇게 하면 그림 7과 같이 이러한 옵션과 다른 옵션을 설정하기 위해 사용할 수 있는 대화 상자가 표시된다.

위로

Resource Perspective 재고

Perspective의 훌륭한 점 중 하나는 클러스터에서 화면을 자유롭게 두는 것이다. 예를 들어, 클래스 파일이 Java Perspective에서 Package Explorer에 표시되지 않는 것을 인식할 수 있다. Eclipse가 Java 파일을 컴파일 할 수 있다고(그리고 할 수 없는지 알려줄 것임) 가정하면, 프로그램을 빌드하고 실행하며 디버그하기 위해 이와 관련하여 실제로 아무 것도 할 필요가 없다. 하지만 한 번 완료하면 클래스 파일을 다른 디렉토리로 복사하거나 다른 사람에게 이메일을 전송하기 위해 압축하려 할 수 있다.

이를 수행하는 한 가지 방법은 작업 공간 디렉토리가 어디인지 알기 때문에 Eclipse 외부로 나가는 것이다 -- 이 디렉토리 또는 프로젝트 파일이 유지되는 Hello 서브디렉토리에 특별한 것은 없다. 하지만 기본 메뉴에서 File > Export를 선택하여 Eclipse 내부에서부터 이를 수행할 수도 있다. 하지만 먼저 모든 파일을 보기 위해 Resource Perspective로 리턴해야 할 것이다. 그림 8과 같이 워크벤치의 맨 위 오른쪽 모서리에서 Resource Perspective 단추를 클릭하여 이를 가장 간단하게 수행할 수 있다.

여기에서는 Java Perspective에 숨겨진 몇 가지 파일이 나타날 것이다. 즉, 이는 클래스 파일, HelloObject.obj 및 프로젝트 정보를 저장하기 위해 Eclipse가 사용하는 두 가지 메타데이터 파일이다(.project 및 .classfile). 클래스 파일을 압축하려면 다음을 수행한다.

• HelloObject.class를 클릭하여 이를 선택한다.
• 기본 메뉴에서 File > Export를 선택한다.
• 내보내기 대상으로 Zip 파일을 선택하고 Next를 클릭한다.
• 압축하기 위한 파일은 다음 화면에서 이미 선택되어야 한다. 즉, 이는 "To zip file:"로 레이블된 필드에서 작성하려는 압축 파일의 경로와 파일 이름을 찾아보거나 입력하고 Finish를 클릭한다.

위로

리팩토링

Netbeans는 클래스 속성을 위해 getter와 setter를 생성하기 위한 기능과 같은 리팩토링과 유사한 일부 코드 생성 기능을 보유한다. 하지만, 이는 새 기능을 추가하는 면에서 리팩토링과는 다르다. 리팩토링은 기능을 변경하지 않고 코드를 다시 구성하는 면에서 자동화된 코드 생성과는 다르다.

코드를 전달하는 JUnit 테스트의 포괄적인 세트가 있으면, 코드는 리팩토링 이후에 동일한 테스트를 계속 전달해야 한다. (일부 경우에 유닛 테스트 자체는 리팩토링으로 변경될 수 있지만 요점은 이는 자동으로 발생해야 한다는 점이다.) 리팩토링에 대한 자세한 정보 및 Eclipse에서 사용 가능한 많은 리팩토링의 소개는 참고자료에 나열된 기사 "Refactoring for everyone"을 참조하자.

여기에서는 상대적으로 간단한 리팩토링인 Change Method Signature를 간단하게 살펴볼 것이다. 예제 프로그램의 greet() 메소드에서 String 매개변수의 유형을 Object로 변경하기 위해 이를 사용하고 인쇄하는 인사말에 대해 유형 String의 추가 매개변수를 추가할 것이다. 이렇게 하려면 다음을 수행한다.

• 편집기의 이름 또는 Outline 보기에서 마우스 오른쪽 단추로 클릭하여 greet() 메소드를 선택한다.
• 컨텍스트 메뉴에서 Refactor > Change Method Signature...를 선택한다. (아래 그림 9 참조.)
• Parameters로 레이블된 테이블에서 String 유형을 클릭하고 Object로 이를 변경한다.
• 매개변수의 이름을 Object로 변경한다.
• 오른쪽에서 Add 단추를 클릭한다. 이렇게 하면 기존 매개변수 아래 새 항목을 추가한다. 유형을 String으로, 이름을 greeting으로, 기본값을 "Welcome"으로 변경한다.
• 새 인사말 매개변수가 첫 번째 매개변수가 되도록 하려고 한다. 즉, 이것이 선택한 매개변수인지 확인하고 Up 단추를 클릭한다. (또는 원래 매개변수를 선택하고 Down 단추를 클릭한다.)

이제 모든 리팩토링에 두 가지 옵션이 있다. 첫 번째는 "Just Do It" 옵션이다. 일반적으로 Eclipse는 리팩토링을 올바르게 한다 -- 그리고 올바르게 하지 않는 드문 경우에 Refactor > Undo 메뉴 선택을 사용하여 항상 실행 취소할 수 있다. (비록 이 제안은 리팩토링 이후에 제한된 시간에만 유효하다. 수반된 어느 파일이나 변경하는 경우 리팩토링을 더 이상 실행 취소할 수 없을 것이다.) 이에 대해 익숙하다면 OK를 클릭할 수 있다. 일반적으로 이는 가장 간편하게 수행하는 방법이지만 지금은 하지 않는다.

두 번째 옵션인 "I want to micromanage" 옵션은 적어도 한 번은 확인하기에 흥미롭다. Preview를 클릭할 때, Eclipse는 맨 위에 영향 받은 모든 파일에서 특정 변경을 선택할 수 있는 대화 상자를 표시하고, 이 아래 선택한 파일을 나란히 이전과 이후로 비교를 표시한다. (물론 이 경우에 하나의 파일만 있다.) 여기에서는 제안된 리팩토링 파일별로 변경마다 조사할 수 있고 각 변경을 개별적으로 수락하거나 거부할 수 있다(그림 10 참조). 선택한 모든 변경사항을 남겨두고 OK를 클릭한다.

이는 리팩토링 이후 코드 모양이다.

			
    public static void main(String[] args) {
        int x = 100;

        Vector names = new Vector();
        names.add("Moe");
        names.add("Curly");
        names.add("Larry");
        for (Iterator i = names.iterator(); i.hasNext();) {
            String name = (String) i.next();
            greet("Welcome, ", name);
        }
    }

    /**
     * @param greeting TODO
     * @param object
     */
    private static void greet(String greeting, Object object) {
            System.out.println("Hello, " + object);
    }
	

리팩토링이 main() 메소드에서 greet() 메소드 호출을 업데이트했고, 첫 매개변수에 기본값 Welcome을 사용했을 뿐만 아니라 메소드 그 자체도 변경하는 것을 인식한다. 프로젝트에서 다른 파일이 있고 이를 또한 greet()라고 하는 경우, 이는 동일한 방식으로 변경될 것이다.

이제 프로그램을 실행하면 어느 적합한 리팩토링이나 해야 하는 것과 같이 이전과 완전히 동일한 결과를 작성한다. 우리가 확보한 것은 greet() 메소드를 호출할 때마다 다른 인사말을 인쇄하여 사용하는 기능이지만, 이는 다음과 같이 System.out.println() 호출을 변경하여 스스로 만들어야 하는 함수적 코드 변경이다.

System.out.println(greeting + Object);

위로

CVS 사용하기

비록 Netbeans와 Eclipse 둘 다 CVS 및 다른 버전 제어 시스템에 대한 지원이 있지만, Eclipse는 두 가지 개별 Perspective를 사용하여 훨씬 더 정교한 인터페이스를 제공한다. 첫 번째는 연결하기 위해 CVS 저장소와 모듈을 선택하고 들어 있는 파일을 탐색하기 위한 CVS Repository Exploring Perspective이다. 두 번째는 변경을 저장소로 병합하기 위한 Team Synchronizing Perspective이다. 비록 이로 인해 CVS가 처음에 사용하기에 조금 더 어려워질 수 있지만 이 접근방식은 훈련되고 구조화된 워크플로우를 장려한다. 게다가, Eclipse는 Netbeans보다 클라이언트-서버 연결 유형을 더 많이 지원한다. 특히, Netbeans는 pserver 프로토콜에 대해 내장 지원만 있으며, 이는 일반 텍스트로 비밀번호를 전송하므로 기본적으로 안전하지 않다. Eclipse는 pserver 및 ssh를 둘 다 지원하며, 다음에 이를 살펴본다.

시작하려면 이에 연결하기 위해 필요한 정보와 CVS 저장소에 액세스해야 할 것이다. Eclipse 기본 메뉴에서 Window > Open Perspective > Other를 선택하고 CVS Repository Exploring을 선택하여 CVS Repository Exploring Perspective를 연다. 이 Perspective에 몇 가지 흥미로운 보기가 있지만 가장 주된 것은 왼쪽 맨 위에 CVS Repositories이다. 여기를 마우스 오른쪽 단추로 클릭하고 New > Repository Location을 선택하면 CVS 서버로 연결하기 위해 필요한 정보를 입력할 수 있다(그림 11 참조). ssh를 사용하려면 Eclipse의 extssh 연결 유형을 선택해야 함을 인식하자.

Eclipse 프로젝트에서 새 CVS 모듈을 작성하려면 다음을 수행한다.

• Java 또는 Resource Perspective로 전환한다.
• 프로젝트 이름을 마우스 오른쪽 단추로 클릭하고 컨텍스트 메뉴에서 Team > Share Project...를 선택한다.
• 옵션 "Use existing repository location selection"을 선택한 대화 상자가 나타난다. 이 아래 이전에 입력한 저장소가 선택된다. Next를 클릭한다.
• 이어지는 대화 상자에서 프로젝트 이름을 모듈 이름으로 사용하는 옵션을 수락하고 Next를 클릭한다.
• 다음 대화 상자를 통해 체크인할 것을 검토할 수 있다. 즉, 문제가 없는 경우 Finish를 클릭한다.
• 마지막 대화 상자에서는 변경을 아직 커미트하지 않았음을 알리고 커미트하려는지 질문한다. Yes를 클릭한다.

이제 아직 버전 제어에 없는 여섯 가지 자원이 있음을 알게 된다. 괜찮다면 간단히 Yes로 응답할 수 있지만, 이러한 자원이 무엇인지 알아보고 싶다면 먼저 Details를 클릭한다. 이는 두 가지 Eclipse 메타데이터 파일인 .project와 .classpath, Java 소스 파일인 HelloObject.java 및 Java 소스 파일(패키지에 해당)이 저장된 중첩된 폴더: /Hello/com, /Hello/com/example 및 Hello/com/example/hello임을 알게 될 것이다.

• 아직 해 본 적이 없다면 Yes를 클릭한다.
• 주석에 대해 프롬프트가 표시되면 "Initial version"을 입력한다.

CVS에서 파일을 체크인 또는 체크아웃하고 일부에 대해 더 작업한 후에 변경을 확인하기 전에 변경이 다른 사람의 변경과 충돌하지 않도록 해야 할 것이다. 실제로 충돌하는 변경이 존재하는 경우, CVS에서 이를 체크인하도록 허용하지 않을 것이다.

두 가지 방법으로 코드를 해결하고 저장소와 병합할 수 있다. 가장 간단하며 가장 위험한 방법은 프로젝트를 마우스 오른쪽 단추로 클릭하고 컨텍스트 메뉴에서 Team > Update를 선택하여 CVS 저장소에서부터 로컬 파일을 변경으로 업데이트하기만 하는 것이다. 변경이 있는 경우, 이는 diff 형식(코드에 어느 행이 있지만 저장소에는 없음을 표시하는 부등호가 많음, 그 반대도 마찬가지임)을 사용하여 파일로 자동으로 병합될 것이다. 이를 단순화하려고 시도하는 것은 지루하며 오류가 발생하기 쉬울 것이다.

Eclipse의 Team Synchronizing Perspective를 사용하는 것이 더 낫다. 이는 변경된 파일을 나란히 제시하여 어느 파일에서나 변경을 검토하고 수락하거나 거부할 수 있다. 이렇게 하려면 다음을 수행한다.

• 프로젝트 이름을 마우스 오른쪽 단추로 클릭하고 컨텍스트 메뉴에서 Team > Synchronize with Repository를 선택한다.
• 이 태스크가 Team Synchronizing Perspective와 연관되어 있다는 알림을 받고 이 Perspective로 전환하려는지 묻는다. "Remember my decision"을 선택하고 Yes를 클릭한다.

다른 많은 Perspective와 마찬가지로 처음에 살펴보려는 보기는 워크벤치의 맨 위 왼쪽에 있으며, 이 경우에는 Synchronize 보기이다. 맨 위에 Incoming Mode, Outgoing Mode, Incoming/Outgoing Mode 및 Conflicts Mode를 비롯한 몇 가지 도구 단추가 있다. 처음에 어느 모드가 선택되느냐는 저장소에 변경이 있는지 여부, 로컬 코드에서 변경 또는 둘 다에서 변경이 있는지(그리고 둘 다 충돌에서 변경이 있는지 여부)에 따라 다르다. 모드는 이 보기에서 어느 파일이 표시되는지 판별한다. 즉, 이는 변경된 로컬 파일, 변경된 저장소 파일 또는 둘 다이다. 이는 혼란스럽게 들릴 수 있지만 실제로는 정말로 세부사항에 대해 걱정할 필요가 없다. 가장 중요한 것은 이는 불필요한 정보를 필터링해서 빼내기 위해 작동한다는 점이다. 저장소에 최신 상태의 소스 코드를 가져오기 위해 검토해야 하는 파일만 확인할 것이다.

일부 코드를 HelloObject로 추가하고(그러므로 이는 다른 오브젝트와 다르게 String을 처리함) 동시에 다른 사람이 코드를 체크아웃하고 다르게 변경했다고(main() 메소드로) 가정하자. 반드시 이 내용을 알 필요는 없지만 파일을 체크인하기 전에 마우스 오른쪽 단추로 클릭하여 Team > Synchronize with Repository...를 선택할 수 있다. 이렇게 하면 Repository Synchronizing Perspective(당연히 수락한 후에)를 열고 로컬 파일과 Repository에서 파일을 나란히 비교하여 보여준다(그림 12 참조).

여기에서는 각 파일의 각 변경을 검토할 수 있고 Java Source Compare 보기에서 Copy Right to Left 도구 단추를 클릭하거나 적절하게 수동으로 로컬 파일을 편집하여 독자의 스코어로 복사할 수 있다. 병합에 만족할 때, Synchronize 보기에서 파일 이름을 마우스 오른쪽 단추로 클릭하고 컨텍스트 메뉴에서 "Mark as Merged"를 선택하여 파일을 병합됨으로 표시한다.

한 번 어느 충돌이나 해결하고 모든 파일을 Synchronize 보기에서 병합하면, Java 보기로 리턴하고 다음과 같이 코드를 체크인하기 전에 프로젝트가 올바르게 빌드하고 실행하는지 확인해야 한다.

• 프로젝트 이름(또는 단일 파일을 커미트하기 위한 파일 이름)을 마우스 오른쪽 단추로 클릭하고 프로젝트 메뉴에서 Team > Commit를 선택한다.
• 프롬프트로 표시되면 주석을 입력한다. (프로젝트에서 체크인하고 있으며 여러 파일이 변경된 경우 이 주석이 모든 파일에 적용될 것임을 인식한다. 개별 파일에 주석을 입력하려면 파일을 개별적으로 체크인해야 할 것이다.)

위로

요약

기능 대 기능을 보면 Eclipse와 Netbeans는 훌륭하게 일치된다. 실제로 둘 다 확장 가능하기 때문에 둘 사이에 어느 기능 차이나 써드파티 플러그인으로 채워질 수 있다. 둘 사이의 중요한 차이점은 사용자 인터페이스가 설계된 방법에 달려있다. Eclipse는 적절한 도구(및 적절한 도구만)가 바로 가까이 있기 때문에 작업을 간편하게 처리해주는 Perspective의 개념을 중심으로 구성된다. Eclipse는 수많은 추가 기능을 통해 QuickFix, QuickDiff 및 책갈피나 클래스 아웃라인을 사용하여 소스 코드 내에서 간편한 탐색과 같이 Java 프로그래머에게 더 효율적인 도구가 된다. Netbeans에서 발견하지 못할 Eclipse 3.0에서 리팩토링과 CVS에 대한 강력한 지원도 발견할 것이다. 이렇게 하면 Eclipse를 체험해보고 숙련되기 위해 현재 Netbeans 애호가를 비롯한 어느 프로그래머에게나 흥미진진한 경우가 될 것이다.

참고자료

• Eclipse 웹 사이트에서 더 자세히 배우고 Eclipse 플러그인의 포괄적인 목록을 확인하자.
  
  
• Netbeans의 최신 버전은 Netbeans 웹 사이트에 있다.
  
  
• David의 기사 Eclipse Platform 시작하기(developerWorks, 2002년 11월)에서는 Eclipse와 플러그인을 설치하는 방법에 대한 세부사항을 비롯한 Eclipse의 개요 및 역사를 제시한다. 또한 그의 저서 Eclipse In Action: A Guide for Java Developers(Independent Pub Group, 2003년)는 Eclipse를 사용하는 Java 개발자를 위한 필독서이다.
  
  
• Visual Editor와 그 배후의 기술에 대한 개요 및 AWT/Swing 애플리케이션을 빌드하기 위한 Visual Editor 0.5의 기능의 간략한 데모와 Visual Editor 1.0에서 SWT 지원의 미리보기는 Build GUIs with the Eclipse Visual Editor(developerWorks, 2004년 5월)를 참조하자.
  
  
• Refactoring for everyone(developerWorks, 2003년 9월)은 Eclipse 2.1.x의 모든 리팩토링 기능과 Eclipse 3.0에서 대부분의 리팩토링 기능의 예제가 있는 Eclipse의 자동화된 리팩토링 기능을 사용하는 방법과 이유를 보여준다.
  
  
• Using Eclipse as development environment with Jakarta Tomcat(developerWorks, 2004년 5월)에서는 Eclipse와 Sysdeo Tomcat 플러그인을 사용하여 Tomcat 애플리케이션을 개발하는 방법을 보여준다. 지시사항은 Tomcat 및 플러그인을 설치하기 위해 포함된다.
  
  
• Eclipse 플랫폼에서의 디버깅(developerWorks, 2003년 5월)은 Eclipse에서 디버깅의 개요를 제공한다.
  
  
• Developing Struts with Easy Struts for Eclipse(developerWorks, 2004년 4월)은 Easy Struts 플러그인을 사용하여 Eclipse에서 Struts 애플리케이션을 개발하는 방법을 보여준다. 지시사항은 Struts 및 플러그인을 설치하기 위해 포함된다.
  
  
• David는 IntelligJ IDEA 및 JBuilder 사용자가 Eclipse로 마이그레이션하는 데 도움을 주기 위해 유사한 방법론 기사를 작성했다. 즉, 이는 Migrating from IntelliJ IDEA to Eclipse(developerWorks, 2004년 9월) 및 Migrating from JBuilder to Eclipse(developerWorks, 2004년 9월)이다.
  
  
• 개방형 표준 기반 개발을 향한 많은 다른 마이그레이션 경로를 보려면 developerWorks Migration station을 참조하자.
  
  
• developerWorks의 모든 Eclipse 기사 뿐만 아니라 developerWorks 오픈 소스 영역 및 developerWorks Java 영역에서 Eclipse로 개발하기 위한 자원을 더 많이 찾아보자.
  
  
• developerWorks 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  
• 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  

필자소개

아티클 순위

의견

위로

목차

• IDE의 비교 쇼핑
• Netbeans와 Eclipse 비교하기
• Perspective의 문제
• Eclipse에서 새 프로젝트 작성
• 코딩을 시작하자
• 프로그램 실행 및 디버깅
• Resource Perspective 재고
• 리팩토링
• CVS 사용하기
• 요약
• 참고자료
• 필자소개
• 의견