javacc 버전 6.0에서 bin 디렉토리에는 javacc를 실행하는 스크립트가 없습니다. 그래서 Windows 명령 프롬프트에서 오류가 발생합니다. 있는 것은 lib 디렉토리에있는 jar 파일 javacc.jar입니다. 클래스 패스에 jar 파일을 추가하고 java.exe를 실행하고 javacc를 실행하는 기본 클래스를 전달하면 나중에 javacc라는 이름이 지정되므로 javacc를 실행하면됩니다.

cmd> java -cp C : \ javacc-6.0 \ bin \ lib \ javacc.jar javacc

최신 버전에서는 패키지의 bin 폴더에 스크립트를 추가하는 것을 잊어 버린 것 같다. 버전 5.0을 다운로드 할 수 있다. 필요한 모든 스크립트 파일을 포함하고 있다. javacc.bat라는 파일을 포함하고 있다.이 파일은 창 쉼표 프롬프트가 찾고있는 파일이며 사용자가 찾지 못한 파일이다.

좀 더 편한 방법은 5.0 버전의 스크립트를 6.0 버전의 bin 디렉토리에 복사하면 된다. C : \ javacc-6.0 \ bin을 포함하도록 경로를 설정 했으므로 명령 프롬프트 창을 닫지 않거나 전체 컴퓨터를 다시 시작하지 않고 전에 시도한 것처럼 실행할 수 있다.

  클래스나 메소드 혹은 변수를 선언할 때 final 제어자가 붙을 수 있는데 각각 다음과 같은 제한이 생기게 된다.

 자바에서 문자열을 저장하는데 사용되는 객체는 String, StringBuilder, StringBuffer 세 가지가 있다. 보통 문자열을 저장하는데 String 객체를 사용하지만 문자열을 빈번하게 수정할 필요가 있는 경우 String 객체보다는 StringBuilder 객체가 성능면에서 더 유리하다.

[표 1] 문자열 저장 객체간 비교

가변하는 문자열을 다루는데 있어서의 속도를 알아보기 위해서 다음과 같은 간단한 벤치마크 프로그램을 실행해 보았다. (JDK8 이용)

결과는 보다시피 StringBuilder가 가장 빨랐고 StingBuilder 와 StringBuffer 는 차이가 별로 나지 않았다. (JDK5 이상에서는 String 객체도 수정이 일어날 때 내부적으로 StringBuffer로 변환되어 사용된다고 알고 있었는데 좀 의외다.)

 다음으로 문자열 내에서 검색하는 속도를 마찬가지로 간단한 프로그램을 실행하여 측정해 보았다. (JDK8 사용)

결과에서 나타났듯이 String 이 근소하게 StringBuilder 에 비해서 빨랐다.

 따라서 다음과 같이 정리해 볼 수 있겠다.

1. 수정될 필요가 없는 문자열은 String 객체로 사용한다.

2. 빈번에게 수정되는 문자열을 다룰 때는 StringBuilder 객체를 사용한다.

3. 빈번에게 수정될 뿐만 아니라 서로 다른 쓰레드간 동기화를 시켜야 할 경우에는 StringBuffer를 사용한다.

 외부 패키지의 클래스를 불러 사용하고자 할 경우 원래는 클래스명 앞에 패키지를 명시해야 한다. 예를 들어서 Random이라는 클래스가 java.util 패키지에 속해 있다. 이것을 불러 사용하려면 다음과 같이 해야 한다.

즉, Random 클래스 앞에 java.util 이라는 소속 패키지의 이름을 명시해야 하는데 여러 군데에서 Random클래스가 사용된다면 패키지 이름이 중복되어 불편한다. 그래서 import 명령을 사용하면 클래스가 속한 패키지 명을 생략할 수 있다.

이와 같이 import 뒤에 패키지명을 포함한 클래스의 전체 경로를 명시해 주면 코드에서는 클래스 이름만 써주면 된다.

 만약 java.util.Data 라는 클래스를 사용하고 싶다면 import 문을 하나 더 추가하면 된다.

이런 식으로 현재 파일에서 사용하는 외부 클래스는 얼마든지 import문으로 불러와서 사용할 수 있다.

 동일한 패키지의 모든 클래스를 불러오고 싶다면 와일드카드(*)문자를 사용하면 된다. 예를 들어서 java.util 패지키의 모든 클래스를 불러오고 싶다면 다음과 같이 하면 된다.

이렇게 하면 java.util 패키지의 모든 클래스를 사용할 수 있다.

이 예에서 Random, Data, List 클래스는 모두 java.util 패키지에 속해 있으르모 하나의 import 문으로 충분하다. 하지만 와일드카드를 사용한 import 가 하위 패키지의 클래스까지는 포함하지 않는다는 점에 유의해야 한다.

 같은 패키지 내의 클래스는 import를 할 필요가 없이 바로 사용 가능하다. 그리고 java.lang 패키지의 클래스도 import할 필요가 없다. 따라서 String 클래스는 java.lang 패키지 내에 있지만 import하지 않아도 바도 사용할 수 있는 것이다.

 가상 머신(virtual machine)이라는 것은 소프트웨어로 작성된 기계 (영어권에서는 컴퓨터 하드웨어를 machine이라고 지칭하기도 한다.) 즉, 코드로 작성된 가상의 물리적인 하드웨어라는 의미이다. 가상 머신은 컴퓨터 안에 존재하는 소프트웨어로 구현된 컴퓨터를 의미하며 광범위하게 사용되고 있는 기술 분야이다.

[그림 1] 윈도 머신에서 가상 머신으로 데비안 리눅스를 실행하고 있는 모습

 자바 가상 머신 (java virtual machine, JVM)은 자바 애플리케이션을 수행하기 위한 가상 머신이다. 일반적으로 보통의 응용 프로그램은 운영 체제를 거쳐서 물리적인 머신(machine)에서 수행된다.

[그림 1] 일반적인 응용 프로그램의 수행 단계

하지만 자바 애플리케이션은 운영 체제와 물리적인 머신이 아니라 JVM 위에서만 수행되고 그 밑단의 모든 동작은 JVM이 알아서 처리하는 방식으로 동작한다. 따라서 자바로 작성된 프로그램은 윈도우즈용 JVM이 설치된 윈도 머신에서도 동작하며 맥용 JVM에 설치된 맥 머신에서도 동일한 코드가 동일하게 수행된다.(Write once, run everywhere.)

[그림 2] 자바 가상 머신에서의 자바 프로그램 동작 단계

윈도만을 혹은 맥만을 주로 사용하는 일반 사용자들은 JVM을 별도로 설치해야 하는 번거로움이 있기 때문에 별 의미가 없을 수 있다. 하지만 개발자 입장에서는 이것은 커다란 장점이다. 자바로 한 번 작성해 놓은 코드는 OS와 피지컬 머신에 상관없이 어디에서나 동일하게 수행되기 때문이다.

 이런 동작 방식의 단점은 JVM이라는 단계를 하나 더 거치기 때문에 성능은 일반적인 프로그램(예를 들어서 컴파일된 C/C++ 프로그램)에 비해서 떨어진다는 점이다. 컴파일된 자바 프로그램은 JVM에서 수행되는 바이트 코드(byte code)로 구성되고 이것을 JVM이 하나씩 해석하여 수행하는 방식으로 동작하기 때문이다. 하지만 요즈음에는 JVM 자체의 성능도 상당히 향상되어 네이티브 프로그램의 수행 속도와 거의 동등한 결과를 보여주고 있다. 이는 바이트 코드를 수행하기 전에 컴파일하는 JIT (just-in-time) 컴파일링과 자바 바이트 코드를 피지컬 머신에 최적화된 네이티브 기계어 코드로 변환하는 핫스팟(hotspot) 기능이 JVM에 도입되었기 때문이다.

 자바의 패키지(package)는 클래스(interface, enum..)의 묶음으로서 하나의 디렉토리(폴더)이다. 패키지의 이름과 같은 디렉토리 내에 클래스 파일들을 포함하며 하위 패키지도 포함하는 중첩된 구조도 가능하다. ( C/C++에 비해서 무척 단순한 구조를 가지고 있다.)

[그림 1] 자바의 패키지 구조. 패키지는 디렉토리임.

퍼블릭 클래스(퍼블릭 인터페이스, 퍼블릭 이넘..)가 물리적으로 하나의 파일인 것과 유사하게 패키지는 물리적으로 하나의 디렉토리이다. 즉, 같은 폴더 내의 이러한 파일들이 패키지를 구성한다. 예를 들어서 java.lang.System 클래스는 java패키지의 하위 패키지인 lang에 속한다. 따라서 물리적으로 java디렉토리 밑의 lang디렉토리 밑의 System.class 파일이다.

 예를 들어서 netbean에서 tut01이라는 프로젝트를 생성하면 처음에 다음과 같으 구조를 가진다. tut01이라는 프로젝트 폴더 밑에 src/tut01 폴더가 tut01 패키지가 된다. 그리고 그 안에 Tut01.java파일이 자동으로 생성되며 맨 첫 줄에 패지지가 명시되어 있다.

[그림 2] tut01 프로젝트 생성

클래스 파일의 (주석과 공백을 제외한) 맨 처음에는 소속 패키지를 선언하는 단일문이 위치해야 한다. [그림 2]에서도 맨 첫 줄에 ‘package tut01;’이라고 소속 패키지가 명시되어 있다.

 하나의 프로젝트는 일반적으로 하나 이상의 패키지를 포함한다. <프로젝트 디렉토리>/src 디렉토리 안에 패키지를 생성할 수도 있고 특정 패키지 안에도 하위 패키지를 생성할 수 있다.

[그림 3] 새로운 패지키들의 생성

해당 폴더에 들어가서 확인해 보면 새로운 패키지를 생성하면 같은 이름의 폴더가 생성된 것을 알 수 있다.

[그림 4] 생성된 폴더

위 그림에는 안 보이지만 tut01 폴더 하위에 sub01 패키지(폴더)가 생성되어 있고 src 밑에는 tut02, tut03 이라는 폴더가 생성된 것을 알 수 있다.

 그리고 자바 프로젝트를 빌드하면 <프로젝트디렉토리>/dist 디렉토리 밑에 jar 파일이 생성되는데 이것은 프로젝트 내의 모든 컴파일된 패키지를 포함한 압축파일이다. 예를 들어서 위의 프로젝트를 빌드하면 tut01/dist/tut01.jar 파일이 생성된다. 이 파일을 열어보면 이 프로젝트에 포함된 패키지들이 생성되어 있음을 알 수 있다.

[그림 5] winrar로 본 tut01.jar의 내용. tut01, tut02, tut03 패키지(디렉토리)가 보인다.

이것을 실행하려면 명령창에서 다음과 같이 하면 된다.

[그림 6] 일반적인 자바 프로젝트(jar파일) 구조

 이와 같이 프로젝트는 패키지의 모음이며 패키지는 클래스 파일들의 묶음이라는 자바 디렉토리의 구조를 이해해야 한다.

 자바 인터페이스(interface)는 추상 클래스와 비슷한 점이 있지만 한 단계 더 추상화된 클래스이다. 기본적으로 다음과 같이 정의한다.

인터페이스의 멤버 변수는 public static final 로만 지정 가능하고 이것은 생략할 수 있다. 인터페이스 변수는 final 이므로 반드시 변수값을 선언부에 지정해 주어야한다.  멤버는 public abstract 가 기본형으로서 이것도 생략할 수 있다. 예를 들면 다음과 같다.

인터페이스도 추상 클래스와 마찬가지로 직접 객체를 생성할 수 없으며 이것을 구현하는 클래스는 객체화 할 수 있다.

추상클래스와 다르게 인터페이스는 이를 구체화하기 위해 implements 라는 키워드를 사용하고 그 뒤에 구현할 인터페이스 명을 써야한다. IA를 구체화하기 위해서는 반드시 추상 메소드인 fun()의 본체를 위와 같이 정의하여야 한다. 그리고 fun()의 접근 지정자는 반드시 public이어야 한다. 그 이유는 인터페이스에서 (생략되었다 할 지라도) public abstract 으로 정의되었기 때문이다.

 실행 가능한 예를 들면 다음과 같다.

이 예에서는 Playable 이라는 인터페이스를 구현한 Violin과 Guitar 클래스를 작성하였다. 인터페이스의 이름은 관례적으로 ~able 로 끝나는 것들이 많다.

 이와 같이 인터페이스는 구현하고자하는 여러 클래스의 공통적인 부분(정적 변수와 public 함수)만 기술해 놓은 기초 설계도와 같고 인터페이스를 구현하는 클래스에서 추상 메소드의 몸체를 모두 정의하도록 강요한다. 만약 인터페이스 구현하는 어떤 클래스가 모든 추상 메소드를 구현하지 않는다면 그 클래스는 추상 클래스가 되어야 한다는 점도 알아두어야 한다. JAVA8에서는 인터페이스에 대한 규약이 좀 더 확장되었는데 이것은 다른 포스트에서 다루도록 하겠다.

 자바도 클래스의 멤버 각각에 외부에서 접근할 수 있는 범위를 지정하는 접근 지정자(access modifier)를 둘 수 있다. 다음과 같은 네 가지가 있다.

public

 공개 정도가 가장 높고 어디에서든 자유롭게 접근할 수 있다.

protected

 같은 패키지 내에서 접근이 가능하고 다른 패키지에서도 상속을 받은 클래스 내부에서는 사용 가능하다. public과 다른 점은 다른 패키지의 자식 클래스 외부에서는 접근할 수 없다는 것이다.

default (package private)

 같은 패키지 내에서만 접근이 가능하다. 아무런 접근 지정자도 없을 경우 이 옵션이 자동으로 적용된다.

private

 동일 클래스 내에서만 접근이 가능한 가장 낮은 단계의 자유도를 갖는다.

다음과 같이 tut02 패키지의 CA클래스와 이를 상속받은 CB클래스가 있다고 하자.

같은 패키지(즉 tut02 패키지) 내에서는 클래스 외부에서 변수 ia, ib, ic를 자유롭게 접근할 수 있고 id는 외부에서는 접근이 안된다. 이 클래스가 같은 패키지 내에서는 public, protected, default 가 같은 효과를 갖는다. 이것을 상속받은 자식 클래스에서도 ia,ib,ic는 접근 가능하다.

 만약 외부에서 tut02패키지의 CA 클래스를 불러서 사용하는 경우를 보자.

객체 a와 c는 외부에서 ia 멤버만 접근할 수 있다. 즉 클래스 외부에서 접근할 수 있는 멤버는 public으로 지정된 것만이다. protected로 선언된 멤버들은 CA를 상속하는 CC 내부에서만 사용 가능하다. 즉, protected로 선언된 멤버는 다른 패키지에서 이것을 상속받은 자식 클래스의 private 멤버가 되는 것이다. 클래스 CC내부에서도 CA의 ic, id는 접근할 수 없는데 default, private 멤버는 다른 패키지에서는 접근이 안 되기 때문이다.

 추상 클래스(abstract class)란 하나 이상의 추상 메소드(abstract method)를 포함하는 클래스이다. 추상 메소드는 선언만 있고 본체는 없는 함수이며 선언부에 ‘abstract’ 라는 키워드를 붙인다. 추상 메소드가 포함되었다면 클래스도 추상 클래스이므로 클래스명 앞에도 ‘abstract’키워드를 붙여야 한다.

추상 클래스는 추상 메서드를 포함하고 객체화 할 수 없다는 점만 제외하고 일반 클래스와 다르지 않으며 생성자, 멤버변수와 일반 메서드도 가질 수 있다. 추상 클래스 자체로는 클래스로의 역할을 하지 못하며 객체를 생성할 수 없지만 새로운 클래스를 작성하는데 있어서 부모 클래스로서 중요한 역할을 갖는다. 위의 예에서 Animal 클래스는 직접 객체를 생성하지 못하고 이를 상속받는 자식 클래스에서는 추상 메소드의 구체적인 본체를 가질 수 있다.

추상 메소드의 접근 지정자로 private는 사용할 수 없는데 이는 자식 클래스에서 받아서 구현되어야 하므로 당연하다. 다른 접근 지정자(public, protected)는 사용할 수 있고 생략되면 default (즉, 같은 패키지 안에서만 접근 가능)인 것은 일반 클래스와 동일하다.

 위의 예에서 처럼 추상 클래스는 다른 클래스들에게서 공통으로 가져야하는 메소드들의 원형을 정의하고 그것을 상속받아서 구현토록 하는데 사용된다. 메소드 오버라이드(override)와 유사해서 혼동하기 쉬우나 오버라이드는 안해도 상관없지만 추상 메소드는 자식 클래스에게 그 구현을 강요하는 기능을 한다. 위 예에서도 Dog 클래스는 move()메소드를 오버라이드 했지만 Cat클래스는 그러지 않았다. 하지만 howl()메소드는 반드시 구현해야 한다. 그리고 만약 어떤 추상클래스를 상속 받은 자식 클래스에서 추상 메소드를 구현하지 않았다면 자식 클래스도 추상 클래스가 되어야 한다는 점도 알아 두자.

 이전 포스트에서 설명한 포장형(wrapper class)의 생성자를 이용하면 문자열을 기본형 값으로 바꿀 수 있다.

[표 1] 포장형의 기본형 값을 반환하는 객체 메쏘드

예를 들어서 다음과 같이 Integer 형 객체에서 다양한 기본형 값을 얻을 수 있다.

위의 (*)에서와 같이 손실 변환(lossy conversion)의 경우에도 별다른 경고나 오류를 발생하지 않는다. 따라서 같은 형의 데이터의 변환에만 쓰는 것이 바람직하다.

 포장형으로 부터 기본형 값을 얻는 메소드로 parse 로 시작하는 정적 메소드들이 있다. 이 메소드를 이용하면 정수형을 반환하는 메소드는 기수를 지정해 줄 수도 있다.

[표 2] 포장형의 기본형 값을 반환하는 메쏘드

실제 프로그램에서는 주로 [표 2]의 정적 메소드를 자주 사용하게 된다.

 포장형 객체를 반환하는 valueOf() 이라는 정적 메소드도 있다.

[표 3] 문자열로 부터 포장형 객체를 반환하는 메쏘드

예를 들어서

이렇게 하면 자동 언박싱이 일어나서 변수 ia에 1234567이란 값이 저장된다. 하지만 parseInt()함수보다는 당연히 성능이 떨어진다.