명령행 인수

Eclipse 런타임의 다양한 부분에서 처리하는 명령행 인수가 아래에 나열됩니다. -D VM 인수를 사용하는 명령행에서 시스템 특성을 사용하거나 config.ini 파일에서 값을 지정하여 이러한 값 대부분을 지정할 수도 있습니다. 후자의 방법을 사용하면 명령행 인수를 사용하지 않고 Eclipse를 사용자 정의할 수 있습니다.

목록의 각 인수에서 해당 시스템 특성 키를 {}로 묶어 지정합니다. 또한 ()로 묶인 명령행 인수를 처리할 Eclipse 런타임 계층도 지정됩니다. 이 방법은 런타임 부분을 특수한 요구에 맞게 바꾸는 사용자에게 유용합니다.

-application <id> (Runtime)

eclipse.application을 <id>로 설정하는 것과 동등함

-arch <architecture> (OSGi)

osgi.arch를 <architecture>로 설정하는 것과 동등함

-clean (OSGi) NEW

osgi.clean을 "true"로 설정하는 것과 동등함

-configuration <location> (Main)

osgi.configuration.area를 <location>으로 설정하는 것과 동등함

-console [port] (OSGi) NEW

osgi.console을 [port] 또는 기본 포트를 사용할 경우(즉, 포트가 지정되지 않은 경우) 빈 문자열로 설정하는 것과 동등함

-consoleLog (Runtime)

eclispe.consoleLog를 "true"로 설정하는 것과 동등함

-data <location> (OSGi)

osgi.instance.area를 <location>으로 설정하는 것과 동등함

-debug [options file] (OSGi)

osgi.debug를 [options file] 또는 예를 들어 옵션 파일 위치를 지정하지 않은 경우 간단히 디버그를 사용할 수 있도록 빈 문자열로 설정하는 것과 동등함

-dev [entries] (OSGi)

osgi.dev를 [entries] 또는 예를 들어 항목을 지정하지 않은 경우 간단히 dev 모드를 사용할 수 있도록 빈 문자열로 설정하는 것과 동등함

-endSplash <command> (Main)

스플래시 화면을 아래로 내릴 때 사용할 명령을 지정합니다. 보통 Eclipse 실행 파일에서 제공합니다.

-feature <feature id> (Runtime)

eclipse.product를 <feature id>로 설정하는 것과 동등함

-framework <location> (Main) NEW

osgi.framework를 <location>으로 설정하는 것과 동등함

-initialize (Main)

실행 중인 구성을 초기화합니다. 모든 런타임 관련 데이터 구조 및 캐시를 새로 고칩니다. 모든 사용자/플러그인의 정의된 구성 데이터가 제거되지 않습니다. 모든 응용프로그램이 실행되지 않고 모든 제품 스펙이 무시되며 UI가 표시되지 않습니다. 예를 들어 스플래시 화면이 그려지지 않습니다.

-install <location> (Main)

osgi.install.area를 <location>으로 설정하는 것과 동등함

-keyring <location> (Runtime)

디스크에서 권한 데이터베이스의 위치입니다. 이 인수는 -password 인수와 함께 사용해야 합니다.

-nl <locale> (OSGi)

osgi.nl을 <locale>로 설정하는 것과 동등함

-noLazyRegistryCacheLoading (Runtime)

eclipse.noLazyRegistryCacheLoading을 "true"로 설정하는 것과 동등함

-noRegistryCache (Runtime)

eclipse.noRegistryCache를 "true"로 설정하는 것과 동등함

-noSplash (Executable, Main)

스플래시 화면의 표시 여부를 제어합니다.

-os <operating system> (OSGi)

osgi.os를 <operating system>으로 설정하는 것과 동등함

-password <password> (Runtime)

권한 데이터베이스의 암호

-pluginCustomization <location> (Runtime)

eclipse.pluginCustomization을 <location>으로 설정하는 것과 동등함

-product <id> (OSGi) NEW

eclipse.product를 <id>로 설정하는 것과 동등함

-showSplash <command> (Main)

스플래시 화면을 표시할 때 사용할 명령을 지정합니다. 보통 Eclipse 실행 파일에서 제공합니다.

-user <location> (OSGi) NEW

osgi.user.area를 <location>으로 설정하는 것과 동등함

-vm <path to java executable> (Executable, Main) NEW

Eclipse 실행 파일에 전달하는 경우 이 옵션은 Eclipse 실행에 사용할 Java VM 위치를 찾는 데 사용됩니다. 이 때 찾는 위치는 해당 Java 실행 파일의 전체 파일 시스템 경로여야 합니다. 경로를 지정하지 않으면 Eclipse 실행 파일은 검색 알고리즘을 사용하여 적절한 VM을 찾습니다. 모든 경우 실행 파일은 -vm 인수를 사용하여 Java 기본에 사용된 실제 VM의 경로를 전달합니다. 그 다음 Java 기본은 이 값을 eclipse.vm에 저장합니다.

-vmargs [vmargs*] (Executable, Main) NEW

Eclipse에 전달하는 경우 이 옵션은 Eclipse 실행에 사용할 Java VM 조작 위치를 찾는 데 사용됩니다. 위치를 지정하는 경우 이 옵션은 명령행의 끝에 와야 합니다. 위치를 실행 파일 명령행에 지정하지 않는 경우에도 실행 파일은 -vmargs 인수를 사용하는 Java로 전달된 명령행에 실행 중인 클래스를 포함한 관련 인수를 자동으로 추가합니다. 그 다음 Java 기본은 이 값을 eclipse.vmargs에 저장합니다.

-ws <window system> (OSGi)

osgi.ws를 <window system>으로 설정하는 것과 동등함

더 이상 사용하지 않는 명령행 인수

다음 명령행 인수는 더 이상 관련이 없거나 대체된 상태이고 역방향 호환성을 유지보수하도록 런타임에서 이용되며 실행 중인 응용프로그램에 전달되지 않습니다.

-boot

-configuration 참조

-classLoaderProperties

더 이상 관련 없음

-firstUse

더 이상 관련 없음

-newUpdates

더 이상 관련 없음

-noPackagePrefixes

더 이상 관련 없음

-noUpdate

더 이상 관련 없음

-plugins

더 이상 관련 없음

-update

더 이상 관련 없음

기타

다음 명령행 인수는 다양한 Eclipse 플러그인에서 정의되며 정의하는 플러그인이 설치, 해석 및 활성화된 경우에만 지원됩니다.

-noVersionCheck (workbench)

<description>

-perspective (workbench)

<description>

-refresh (org.eclipse.core.resources)

<description>

-showLocation (org.eclipse.ui.ide.workbench)

<description>

-allowDeadlock

<description>

시스템 특성

다음 시스템 특성은 Eclipse 런타임에서 사용됩니다. "osgi"로 시작하는 이러한 시스템 특성은 OSGi 프레임워크 구현에 특정하지만 "eclipse"로 시작하는 일부 시스템 특성은 OSGi 프레임워크의 맨 위에 계층화된 Eclipse 런타임에 특정함에 유의하십시오.

이러한 특성 대부분은 명령행과 동등합니다({} 중괄호의 값 및 명령행 인수 섹션 참조). 사용자는 명령행 또는 특성 설정을 사용하여 값을 지정할 수 있습니다. 특성은 다음과 같은 방법으로 설정될 수 있습니다.

• -DpropName=propValue를 Java VM의 VM 인수로 사용
• 해당 구성 영역에서 config.ini 파일에 필요한 특성 설정

eclipse.application {-application}

실행할 응용프로그램 ID입니다. 여기에 지정된 값은 실행 중인 제품(eclipse.product 참조)에서 정의한 응용프로그램을 대체합니다.

eclipse.commands

sdf

eclipse.consoleLog

"true"인 경우 로그 출력도 Java의 System.out에 송신됩니다. 보통 명령 쉘에 다시 송신됩니다. -debug와 함께 결합하면 유용합니다.

eclipse.debug.startupTime

이 세션에서 Java VM이 시작된 시간(밀리 초)

eclipse.exitcode

<description>

eclipse.exitdata

<description>

eclipse.manifestConverter

레거시 plugin.xml 파일을 manifest.mf 파일로 변환할 때 사용할 manifest 변환기의 클래스 이름

eclipse.noExtensionMunging

"true"인 경우 레거시 레지스트리 확장은 그대로 남아 있습니다. 기본적으로 이러한 확장은 갱신하여 Eclipse 3.0에 있는 새 확장점 ID를 사용합니다.

eclipse.noLazyRegistryCacheLoading {-noLazyRegistryCacheLoading}

"true"인 경우 플랫폼의 플러그인 레지스트리 캐시 로드 최적화가 비활성화됩니다. 기본적으로 구성 요소는 레지스트리 캐시가 사용 가능한 경우 요청할 때에만 해당 레지스트리 캐시에서 로드되어 메모리 예정 범위를 줄입니다. 이 옵션은 시작할 때 레지스트리 캐시를 전체적으로 로드하도록 강제 실행합니다.

eclipse.noRegistryCache {-noRegistryCache}

"true"인 경우 내부 확장 레지스트리 캐시의 읽기 및 쓰기가 불가능합니다.

eclipse.pluginCustomization {-pluginCustomization}

플러그인 환경 설정의 기본 설정이 들어 있는 특성 파일의 파일 시스템 위치입니다. 이 기본 설정은 1차 기능에 지정된 기본 설정을 대체합니다. 상대 경로는 Eclipse 자체의 현재 작업 디렉토리에 따라 해석됩니다.

eclipse.product {-product}

실행 중인 제품 ID입니다. 이 ID를 통해 다양한 브랜딩 정보 및 사용되는 응용프로그램을 제어합니다.

eclipse.vm {-vm}

Eclipse 실행에 사용한 Java 실행 파일의 경로입니다. 이 정보는 재실행 명령행을 구성하는 데 사용됩니다.

eclipse.vmargs {-vmargs}

Eclipse 실행에 사용한 VM 인수를 나열합니다. 이 정보는 재실행 명령행을 구성하는 데 사용됩니다.

osgi.adaptor

사용할 OSGi 프레임워크 어댑터의 클래스 이름

osgi.arch {-arch}

-arch 참조

osgi.baseConfiguration.area

asf

osgi.bundles

시스템을 가동하여 실행하면 자동으로 설치되어 선택적으로 시작되는 쉼표로 구분된 번들 목록입니다. 다음은 각 항목 양식입니다.

    <URL | simple bundle location>[@ [<start-level>] [":start"]]

시 작 레벨(>0인 정수)이 누락되면 프레임워크에서는 번들의 기본 시작 레벨을 사용합니다. "start" 태그를 추가하면 번들은 설치 후 시작됨으로 표시됩니다. 단순 번들 위치는 프레임워크의 상위 디렉토리에 상대적으로 해석됩니다. 시작 레벨은 번들을 실행해야 하는 경우에 OSGi 시작 레벨을 표시합니다. 이 값이 설정되지 않으면 시스템에서 적절한 기본값을 계산합니다.

osgi.clean

"true"로 설정하면 OSGi 프레임워크 및 Eclipse 런타임에 사용되는 캐시된 데이터가 정리됩니다. 그러면 번들 종속성 분석 및 eclipse 확장 레지스트리 데이터를 저장하기 위해 사용되는 캐시가 정리됩니다. 이 옵션을 사용하면 eclipse는 이 캐시들을 다시 초기화하게 됩니다.

osgi.configuration.cascaded

"true"로 설정하면 이 구성은 상위 구성에 계단식으로 설정됩니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.configuration.area {-configuration}

이러한 플랫폼을 실행하는 데 사용할 구성 위치입니다. 구성에서는 실행한 플러그인 및 다양한 기타 시스템 설정을 판별합니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.configuration.area.default

이러한 플랫폼을 실행하는 데 사용할 기본 구성 위치입니다. 구성에서는 실행한 플러그인 및 다양한 기타 시스템 설정을 판별합니다. 이 값, 즉 기본 설정은 osgi.configuration.area에 설정된 값이 없는 경우에만 사용됩니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.console {-console}

널이 아닌 값으로 설정하면 OSGi 콘솔을 설치한 경우 해당 콘솔이 사용 가능합니다. 값이 적절한 정수인 경우 이 값은 콘솔이 청취하는 포트로 해석되어 지정된 포트로 해당 출력을 지정합니다. 시스템 상태를 조사할 때 유용합니다.

osgi.console.class

요청할 경우 실행할 콘솔의 클래스 이름

osgi.debug {-debug}

널이 아닌 값으로 설정하면 플랫폼은 디버그 모드가 됩니다. 값이 문자열인 경우 이 값은 .options 파일 위치로 해석됩니다. 이 파일은 플러그인에서 사용 가능한 디버그 확장점 및 이러한 확장점의 사용 가능 여부를 표시합니다. 위치를 지정되지 않은 경우 플랫폼에서는 설치 디렉토리 아래의 .options 파일을 검색합니다.

osgi.dev {-dev}

빈 문자열로 설정하면 dev 모드가 간단히 켜집니다. 또한 이 특성은 플러그인 세트의 사용자 정의 클래스 경로 추가가 들어 있는 Java 특성 파일의 URL 또는 각 플러그인의 클래스 경로에 추가되는 쉼표로 구분된 클래스 항목에 설정됩니다. 사용자 정의된 dev 시간 클래스 경로를 요구하는 각 플러그인의 경우 해당 파일에 다음 양식의 항목이 들어 있습니다.

    <plug-in id>=<추가할 쉼표로 구분된 클래스 경로 항목>

여기서 plug-in id "*"는 별도의 언급이 없는 한 모든 플러그인과 일치합니다.

osgi.framework

OSGi 프레임워크 URL 위치입니다. Eclipse 설치를 해체할 경우 유용합니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.frameworkClassPath

OSGi 프레임워크 구현에 사용할 쉼표로 구분된 클래스 경로 항목 목록입니다. 상대 위치는 프레임워크 위치에 따라 해석됩니다(osgi.framework 참조).

osgi.install.area {-install}

플랫폼의 설치 위치입니다. 이 설정은 기본 Eclipse 플러그인의 위치를 표시하며 Eclipse 설치를 해체할 경우 유용합니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.instance.area {-data}

이 세션에서의 인스턴스 데이터 위치입니다. 플러그인에서는 이 위치를 사용하여 데이터를 저장합니다. 예를 들어 자원 플러그인에서는 이 위치를 프로젝트(작업공간이라고도 함)의 기본 위치로 사용합니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.instance.area.default

이 세션에서의 기본 인스턴스 데이터 위치입니다. 플러그인에서는 이 위치를 사용하여 데이터를 저장합니다. 예를 들어 자원 플러그인에서는 이 위치를 프로젝트(작업공간이라고도 함)의 기본 위치로 사용합니다. 이 값, 즉 기본 설정은 osgi.instance.area에 설정된 값이 없는 경우에만 사용됩니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.manifest.cache

생성된 Manifest가 발견 및 생성된 위치입니다. 기본값은 구성 영역이지만 Manifest 캐시를 별도로 저장할 수 있습니다.

osgi.nl {-nl}

Eclipse 플랫폼을 실행할 로케일 이름입니다. NL 값은 표준 Java 로케일 이름 지정 규칙을 따라야 합니다.

osgi.os {-os}

운영 체제 값입니다. 이 값은 Eclipse에 알려진 Eclipse 프로세서 아키텍처 이름 중 하나여야 합니다(예: x86, sparc, ...).

osgi.splashLocation

Eclipse를 시작할 때 표시할 스플래시 화면(.bmp 파일)의 절대 URL 위치입니다. 이 특성은 osgi.splashPath에 설정된 값을 대체합니다.

osgi.splashPath

splash.bmp 파일을 검색하는 쉼표로 구분된 URL 목록입니다. 이 특성은 osgi.splashLocation에 설정된 값으로 대체됩니다.

osgi.user.area {-user}

사용자 영역의 위치입니다. 사용자 영역은 OS 사용자에게 특정한 데이터(예: 환경 설정)를 포함하고 Eclipse 설치, 구성 또는 인스턴스와는 독립되어 있습니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.user.area.default

사용자 영역의 기본 위치입니다. 사용자 영역은 OS 사용자에게 특정한 데이터(예: 환경 설정)를 포함하고 Eclipse 설치, 구성 또는 인스턴스와는 독립되어 있습니다. 이 값, 즉 기본 설정은 osgi.user.area에 설정된 값이 없는 경우에만 사용됩니다. 자세한 내용은 위치 섹션을 참조하십시오.

osgi.ws {-ws}

창 시스템 값입니다. 이 값은 Eclipse에 알려진 Eclipse 창 시스템 이름 중 하나여야 합니다(예: win32, motif, ...).

osgi.syspath

<xxx가 계속 사용됩니다. 이름을 고정합니다.>

위치

Eclipse 런타임에서는 플러그인 개발자에게 데이터를 읽거나 저장하는 컨텍스트를, Eclipse 사용자에게 데이터 공유 및 가시성의 범위에 대한 제어를 제공하는 위치 수를 정의합니다. Eclipse는 다음과 같이 위치 개념을 정의합니다.

User (-user) {osgi.user.area} [@none, @noDefault, @user.home, @user.dir, filepath, url]

사용자 위치는 사용자에게 특정된 위치입니다. 보통 사용자 위치는 Java user.home 시스템 특성의 값에 기초하지만 해당 위치를 대체할 수 있습니다. 사용자 범위의 환경 설정과 같은 정보 및 로그인 정보는 사용자 위치에서 찾을 수 있습니다.

Install (-install) {osgi.install.area} [@user.home, @user.dir, filepath, url]

설치 위치는 Eclipse 자체가 설치된 위치입니다. 실제로 이 위치는 실행 중인 startup.jar 또는 eclipse.exe의 상위 디렉토리(보통 "eclipse")입니다. 여러 사용자가 설치를 공유할 수 있으므로 이 위치는 일반 사용자에게 읽기 전용으로 간주됩니다. 설치 위치를 설정하고 나머지 Eclipse에서 startup.jar를 분리할 수 있습니다.

Configuration (-configuration) {osgi.configuration.area} [@none, @noDefault, @user.home, @user.dir, filepath, url]

구성 위치에는 실행할 설치 세트(또는 서브세트)를 식별 및 관리하는 파일이 들어 있습니다. 이와 같이 한 설치에 여러 구성이 있을 수 있습니다. 설치는 기본 구성 영역과 함께 제공될 수 있지만 일반 시작 시나리오는 쓰기 가능한 구성 위치를 더 찾으려는 런타임과 연관되어 있습니다.

Instance (-data) {osgi.instance.area} [@none, @noDefault, @user.home, @user.dir, filepath, url]

인스턴스 위치에는 사용자 정의 데이터 아티팩트가 들어 있습니다. 예를 들어 자원 플러그인에서는 인스턴스 영역을 작업공간 위치로 사용하므로 프로젝트의 기본 홈을 사용합니다. 기타 플러그인에서는 이 위치에서 필요한 모든 파일을 쓸 수 있습니다.

사용자는 이러한 모든 위치를 설정할 수 있지만 Eclipse에서는 값이 지정되지 않으면 올바른 기본값을 계산합니다. 위치를 설정하는 가장 일반적인 사용 케이스는 인스턴스 영역 또는 IDE 컨텍스트의 경우 작업공간입니다. 다음을 지정하여 특정 데이터 세트에서 기본 Eclipse 구성을 실행할 수 있습니다.

    eclipse -data c:\mydata

세부사항

위치는 URL입니다. 위치를 단순하게 표시하도록 파일 경로도 허용되고 자동으로 file: URL 형식으로 변환됩니다. 효율적인 제어 및 편의를 제공하는 사용 가능한 여러 사전 정의된 기호 위치도 있습니다. 위치 유형 및 기호 값을 조합한 모든 경우가 올바르지는 않음에 유의하십시오. 아래의 테이블에서는 가능한 조합을 자세히 표시합니다. 기본 케이스가 모든 위치에서 올바르고 쓰기 가능한 조합으로 설정되었으므로 일부 플러그인은 가능한 경우로 나열되었어도 다른 설정에서 실패할 수 있습니다. 예를 들어 인스턴스 영역을 정의하지 않으면 사용자 데이터에 초점을 맞춘 플러그인(예: Eclipse 자원 플러그인)에서 많은 작업을 수행할 수는 없습니다. 플러그인 개발자가 필요한 경우 지원한 설정을 선택하고 해당 기능을 설계해야 합니다.

@none

해당 위치를 명시적으로 설정하거나 기본값으로 설정할 수 없음을 표시합니다. 예를 들어 사용자 데이터가 없는 RCP 스타일 응용프로그램에서는 osgi.instance.area=@none을 사용하여 외부 파일이 디스크에 작성되지 않도록 할 수 있습니다. @none 뒤에 추가 경로 세그먼트가 올 수 없습니다.

@noDefault

정의되지 않거나 명시적으로 정의된 위치를 강제 실행합니다. 즉, Eclipse에서는 기본값을 자동으로 계산하지 않습니다. 이 방법은 해당 위치에 있는 데이터는 허용하려고 할 때 Eclipse 기본값이 적절하지 않은 경우 유용합니다. @noDefault 뒤에 추가 경로 세그먼트가 올 수 없습니다.

@user.home

Eclipse를 사용자 홈 디렉토리와 관련된 위치 값을 계산하도록 지정합니다. @user.home 뒤에 추가 경로 세그먼트가 올 수 없습니다. 모든 경우 "@user.home" 문자열이 Java "user.home" 시스템 특성 값으로 간단히 바뀝니다. 예를 들어 다음과 같이 설정합니다.
osgi.instance.area=@user.home/myWorkspace
다음은 이 때의 결과 값입니다.
file:/users/bob/myWorkspace

@user.dir

Eclipse를 현재 작업 디렉토리와 관련된 위치 값을 계산하도록 지정합니다. @user.dir 뒤에 추가 경로 세그먼트가 올 수 없습니다. 모든 경우 "@user.dir" 문자열이 Java "user.dir" 시스템 특성 값으로 간단히 바뀝니다. 예를 들어 다음과 같이 설정합니다.
osgi.instance.area=@user.dir/myWorkspace
다음은 이 때의 결과 값입니다.
file:/usr/share/eclipse/myWorkspace

*는 이 설정이 기술적으로는 가능하지만 실용적으로는 관리에 어려움이 있음을 표시합니다. 특히 구성 위치가 없는 경우 Eclipse 런타임은 OSGi 프레임워크를 시작하는 경우에만 가져올 수 있습니다.

작업을 하다 자바소스를 잃어버려 이전에 컴파일 해놓은 .class 파일을 역컴파일 해서 소스를

보고 싶을때가 있을것이다. 그리고 배포된 API 들을 열어 좋은 예가 되는 소스를 보고 공부해

볼수도 있다. 이럴때 eclipse 에서 볼수있는 방법이다.

환경은 Eclipse SDK 3.3 이며 jad 실행파일과 jadclipse 이클립스 플러그인이 필요하다.

Jad 다운로드 : http://www.kpdus.com/jad.html  jadnt158.zip

각종 OS 환경에 맞는 프로그램이 있는데 windows 용을 받는다.

Jadclipse다운로드: http://sourceforge.net/projects/jadclipse 에서

JadClipse (net.sf.jadclipse_3.3.0.jar) 를 다운 받는다. 다운받는 사이트에 보시면 eclipse 버전에 맞는 플러그인 버전이 표시 되어있으므로 맞는걸 다운받으면 된다.

먼저 jad.exe 를 사용해서 독립적으로 사용하는 방법과 eclipse 와 연동해서 사용하는 방법 두가지를

기술하도록 하겠다.

몇 개안되는 클래스파일들은 jad.exe 만으로 컴파일 하게 되면 더 편할수도 있는데 위에서 받은

jadnt158.zip 압축을 풀게 되면 jad.exe 가 나오게 되는데 이것을 java path 환경설정이 잡혀있는

bin 폴더에 넣는다. 도스창에서 실행을 바로 할수 있도록 하기 위함 이다.

아래 보는 바와 같이 programDlg.class 를 디컴파일 하게 되는데

명령어는 jad –s .java [컴파일된파일명]로 넣어서 실행하면되는데 output은[파일명].java가 될것이다.

하나의 컴파일된 클래스 파일이 아닌 폴더에 있는 모든 클래스 파일을 디컴파일하고 싶을 때

다음은 이클립스에서 실행하기 위한 환경설정과 방법이다.

위에서 다운받은 jadclipse -> net.sf.jadclipse_3.3.0.jar 를 eclipse plugin 폴더에 넣는다.

Windows > Preferences > java > Jadclipse 라는 메뉴가 생겼을 것이다.

다음 해야될것이 .class 파일클릭시 기본적으로 jadclipse 가 실행되도록 설정해줘야한다.

Windows> Preferences > General > Editors > File Associations 클릭하게 되면

모든 확장가가 기본적으로 취하게 되는 프로그램명들을 설정할수 있게 되어있는데 .class 파일을

이제 디컴파일이 되는지 확인하기 위해서 jar 파일을 열고 클래스 파일을 클릭하게 되면

기타 환경설정을 해야되는부분이다. 한글이 깨지는 문제는 Convert Unicode String into ANSI Strings

프로젝트 폴더에 넣었다고해서 디컴파일을 jadclipse 가 다 실행시켜주는 것은 아니다.

몇 개의 원하는 class 파일을 이클립스에서 디컴파일 할려고 할 때 Project build path 에 Libraries

등록 되어있어야 한다. 그림에서 와 같이 Add class folder 클릭하여 원하는 폴더를 체크하면 되는데

java.lang.OutOfMemoryError 

                     2005-05-31     송학렬    ㈜아이티플러스 기술지원부

이 문서는 기술지원 또는 개발 시 java.lang.OutOfMemoryError 를 만났을 때 원인 파악 및 해결방안 입니다.

java.lang.OutOfMemoryError 에는 크게 2가지 패턴이 있다고 볼 수 있습니다.(전적으로 개인적인 생각이지만..^^)

Java의 heap 메모리가 정말로 Full 되서 나는 종류가 있고 그렇지 않은데도 나는 종류가 있습니다.

그 둘 중에 어는 것 인지부터 가려내는 것이 가장 먼저 선행되어야 합니다.

Java 가상머신에는 메모리 구조가 여러단계로 나뉘어 져 있으므로 어느 영역에 의해 java.lang.OutOfMemoryError 가 나는지 알기 위해 JAVA OPTION으로 싸이트가 안정화 되기 전까진 –verbosegc 또는 -XX:+PrintGCDetails  옵션을 추가해 놓는 것이 java.lang.OutOfMemoryError 났을 때를 대비해 좋은 습관이라 할 수 있습니다.

-verbosegc 또는  -XX:+PrintGCDetails  옵션으로 로그에 남는 heap 메모리 정보를 본 후 java.lang.OutOfMemoryError 가 날 때 heap이 꽉 차서 나는 것인지 아닌지 부터 판단합니다.

1.     Heap Memory가 Full 차지 않았을 때 1)     Perm 영역이 full 되는 경우

Permanent generation is full…

increase MaxPermSize (current capacity is set to: 134217728 bytes)

[Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor31282]

 810207K->802132K(1013632K), 8.3480617 secs]

<GC: 2 4  2465625.831280 10348 0 31 113802808 105534632 286326784 0 0 35782656 715849728 715848840 715849728 134217720 134023296 134217728 8.348677 8.348677 >

Passwd Check =============

<2005. 5. 19. 오전 9시 32분 23초 KST> <Error> <HTTP> <BEA-101017> <[ServletContext(id=2536415,name=/,context-path=)] Root cause of ServletException.

java.lang.OutOfMemoryError

위와 같은 case 인 경우네는 Java 가상머신중에 Perm 영역이 full 차는 경우 입니다. 

Perm 영역에는 class object 및 관련된 meta data가 로드되는 곳인데 싸이트가 매우 많은 수의 class를 사용하는 경우 늘려줘야 하는 case도 있습니다.

얼마가 적정한 사이즈란 정답이 없는 것 같고 max가 계속 늘어나지 않고 일정한 사이즈를 유지 하면 됩니다.

             위 에러가 났을때는 -XX:MaxPermSize=256m  옵션으로 사이즈를 적당하게 늘려주는게 방

             법이며 늘려주었는데도 불구하고 Full 차는 시간만 늘어날 뿐 계속 사이즈가 늘어난다면 이 영역은 일반 비즈니스 프로그램으로 핸들링 할 수 없는 영역이므로 WAS 제품의 버그 및 jdk 버그로 보는 것이 일반적입니다.

2)     MAXDSIZ 사이즈 관련

  - Exception in thread “CompileThread0″ java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate

Possible causes:

         - not enough swap space left, or

         - kernel parameter MAXDSIZ is very small.

-          java.lang.OutOfMemoryError: unable to create new native thread

위 두 에러가 나는 이유는 Data 사이즈가 Full 차서 더 이상 메모리 할당을 할 수 없다는 java.lang.OutOfMemoryError 입니다.

Jdk도 내부적으로 c 라이브러리를 쓰고 jni를 통해서 c프로그램을 호출할 수 도 있는 환경에서 Data 영역이상으로 메모리 사용 시 위 에러를 만날 수 있습니다.

Heap 영역에는 java heap과 C heap이 있는데 C heap이 Data 메모리 영역에 영향을 미치는 것으로 보이며 보통 C의 전역 변수들이 잡히는 영역입니다.

위 현상을 만났을 때는 hp os의 MAXDSIZ가 너무 작게 잡혀있지 않은지 확인 후 적당한 크기로 늘려 줘야 합니다.

Glance 에서 shift+m 을 누른 후 jvm pid를 누르면 java가 사용하는 Data 사이즈를 모니터링 할 수 있습니다.

모니터링을 통해 적정한 사이즈로 MAXDSIZ를 늘려주어야 하며 만일 늘려 준게 에러 발생의 시간만 지연 시킬 뿐 계속 사용량이 늘어난다면 이는 사용하는 c라이브러리 쪽에 메모리 릭 버그가 있는 것이므로 c라이브러리를 체크 하셔야 합니다.

java.lang.OutOfMemoryError: unable to create new native thread

이 경우는 프로그램에서 Thread pool 프로그램 실수로 필요이상으로 쓰레드가 생성되는 경우도 과도하게 메모리를 사용할 수 있으므로 jvm 쓰레드 덤프를 통해 과도한 쓰레드가 생성되지 않았는지도 확인해 보셔야 합니다.

2.     Heap이 Full 찾을 때

이 경우는 java가 사용하는 heap 영역이 Full 되서 java.lang.OutOfMemoryError 가 나는 경우 인데 두 가지 패턴이 있습니다.

순간적으로 대량의 데이터를 메모리에 올리는 프로그램이 실행되어 문제를 야기 할수 있으며 다른 한 가지는 조금씩 메모리 릭이 발생하여 점차적으로 메모리가 쌓여 가는 경우 입니다.

두 가지 중에  어느 것인지 구별하는 것이 중요하며 이를 위해서도 마찬가지로 -verbosegc 또는  -XX:+PrintGCDetails  로그를 통해 순간적으로 메모리가 차는 것인지 조금씩 메모리가 차는 것인지를 확인하셔야 합니다.

1) 특정 프로그램의 특정시점의 과도한 메모리 사용에 의한 경우

                특정 프로그램이 과도하게 heap 메모리 이상 메모리를 사용하면서

java.lang.OutOfMemoryError가 발생하는 경우는 이 에러가 발생하는 시점의 쓰레드 덤프를 통해 어느 프로그램인지 쉽게 찾을 수 있습니다.

쓰레드 덤프에 메모리를 쓸만한 프로그램은 어느 정도의 자바프로그램 경험이 있으면 찾을 수 있습니다.

Ex)

“ExecuteThread: ‘36′ for queue: ‘default’” daemon prio=10 tid=0×0048e7b0 nid=48 lwp_id=4139729 runnable [0x23f32000..0x23f30500]

          at java.net.SocketInputStream.socketRead(Native Method)

          at java.net.SocketInputStream.read(Unknown Source)

          at oracle.net.ns.Packet.receive(Unknown Source)

          at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)

          at oracle.net.ns.NetInputStream.read(Unknown Source)

          at oracle.net.ns.NetInputStream.read(Unknown Source)

          at oracle.net.ns.NetInputStream.read(Unknown Source)

          at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:71

          at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:690)

          at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:373)

          at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)

          at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:889)

          - locked <0×35e8e3b0> (a oracle.jdbc.ttc7.TTC7Protocol)

          at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:242)

          - locked <0×36f66c98> (a oracle.jdbc.driver.OracleResultSetImpl)

          at weblogic.jdbc.pool.ResultSet.next(ResultSet.java:180)

          at Dcard.AAA.ejb.monitor.member.wbbb.WACBean.getInfoList(WACBean.java:5789)

java.lang.OutOfMemoryError 가 날 상황에 쓰레드 덤프를 두 세번 떠서 같은 쓰레드 번호로 위 같은 로직이 오래 결려있다면 이는 프로그램에서 while(rs.next()) 를 오랜 기간 돌면서 메모리에 DB로부터 읽어서 올리고 있다는 것을 의미 합니다… 대량 데이터 조회가 일어나는 경우인 것 입니다.

이런 식으로 특정 프로그램의 특정 시점에 과도한 메모리 사용으로 인한 java.lang.OutOfMemoryError 에러는 쓰레드 덤프를 통해 찾을 수 있습니다.

– 물론 2번에서 설명 할 heap dump를 통해서도 찾을 수 있습니다.

2) 메모리 릭에 의해 조금씩 메모리가 쌓인 경우

JVM위 에서 실행중인 프로그램중에 어떤 것이 GC 대상에서 제외되는 영역에 data를 조금씩 쌓고 있다는 얘기입니다.

GC 대상에서 제외되는 영역은 다음과 같은 곳이 있습니다.

- Http Session에 넣는 데이터..(세션 타임아웃 또는 invilidate 씨 까지 제외됨)

- Static 변수

- 서블릿 또는 jsp의 멤버변수 ( WAS 기동 후 최초 호출 시 인스턴스 화 되어 WAS가 내려 갈 때 까지 사라지지 않음 )

- EJB의 멤버변수( pool안에서 객체가 존재하는 한 GC대상에서 제외)

          위 같은 영역에 프로그램에서 data를 add 하는 구조를 메모리 릭 이라고 할 수 있습니다.

           IBM 또는 SUN JDK 인 경우에는 heapdump를 통해서 분석하여 어느 데이터가 메모리를 많이 잡고 있는지를 알 수 있습니다.

           Heapdump 사용법 및 분석 법은 다음을 참조 하시면 됩니다.

 http://www.alphaworks.ibm.com/aw.nsf/FAQs/heaproots

http://www-1.ibm.com/support/docview.wss?uid=swg21190476

http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q1=heapdump+solaris&uid=swg21190608&loc=en_US&cs=utf-8&lang=en

http://www.skywayradio.com/tech/WAS51/IBMHeapDump/

출처 : http://www.javaservice.net/~java/bbs/read.cgi?m=etc&b=jdk&c=r_p&n=1117521098&p=1&s=t#1117521098

var viewer_image_url = “http://blogimgs.naver.com/blog20/blog/layout_photo/viewer/”; var photo = new PhotoLayer(parent.parent.parent); photo.Initialized(); window.onunload = function() { photo.oPhotoFrame.doFrameMainClose(); }.bind(this);

두 정수의 합 구하기 Closure Literal.

{int x, int y => x+y}

두 정수의 합 구하기 Closure를 지역 변수 plus에 할당하기

{int,int=>int} plus = {int x, int y => x+y};

내부적으로는 위와 같은 literal들이 translation 됩니다. 예를들어,

{int,String=>Number throws IOException} xyzzy;

와 같은 변수 선언은

interface Closure1<R,A2,throws E> { // system-generated
    R invoke(int x1, A2 x2) throws E;
}
Closure1<? extends Number,? super String,null> xyzzy;

와 같이 변환됩니다.

Control Invocation Syntax의 예

withLock(lock) {
    System.out.println("hello");
}

file 처리의 예

Java 7 전망

Dolphin은 2007년에는 릴리스 되지 않을 것이다. 내년에 릴리스 될 가망성은 있다. 작업은 진행 중이고, 일부 기능들은 일찌감치 표준 확장으로서 데뷔를 마쳤고, 적어도 베타 버전으로 릴리스 되었다.

언어에 특성을 추가하는 것이 제거하는 것 보다 훨씬 더 쉽다는 것은 불행한 일이다. 시간이 흐를수록 언어가 점점 더 복잡해진다는 것은 피할 수 없는 일이다. 심지어 독립적인 상태로 좋은 기능들 조차도 서로서로 엮이면서 문제가 많은 기능이 되어버린다.

불행히도, 자바 커뮤니티는 아직 이러한 교훈을 터득하지 못한 것 같다. 이것은 매우 일반적인 사실인데도 말이다. 어떤 실질적 문제도 해결해주지 못하는데도 불구하고, 언어 디자이너들에겐 감당하기 힘들만큼 참신하고 흥분되는 신텍스들이 있을 수 있다. 따라서 클로저(closure), 다중 상속, 연산자 오버로딩(operator overloading)을 포함한 Java 7의 새로운 기능들에 대해 언급하고 있는 듯 하다.

실현 가능성이 반반 이겠지만, 올해 안에 Java 7 베타 버전에 클로저가 도입될 것이고, 연산자 오버로딩도 잘하면 볼 수 있을 것이다. 하지만 다중 상속은 불가능 할 것이다. 자바 대부분이 단일 상속 계층에 기반하고 있다. 다중 상속을 이 언어에 도입할 수 있는 그럴듯한 방법이 없다.

현재, 많은 신택스들이 있고, 이중 일부는 합당하지만, 어떤 것은 그렇지 못하다. 많은 제안들이 getFoo() 같은 메소드를 -> 연산자로 대체하는데 초점을 맞추고 있다.

List

집합체에 접근하는 첫 번째 가능한 방법은 배열관련 신텍스를 사용하는 것이다. 예를 들어, 다음과 같이 작성하는 대신,

List content = new LinkedList(10);
content.add(0, "Fred");
content.add(1, "Barney");
String name = content.get(0);

아래와 같이 작성한다:

List content = new LinkedList(10);
content[0] = "Fred";
content[1] = "Barney";
String name = content[0];

또 다른 방법으론 리스트에 대한 배열 초기화 문법을 사용할 수 있다:

LinkedList content = {"Fred", "Barney", "Wilma", "Betty"}

이 두 가지 제안 모두 가상 머신(VM)을 수정하지 않고 작은 컴파일러 조작으로도 구현될 수 있었다. 기존의 어떤 소스 코드도 무효로 하지 않았으며 재정의 하지 않았고, 심지어는 새로운 신택스에 보다 중요한 이슈가 되었다.

개발자의 생산성에서 차이를 만들어내는 한 가지 언어 특징은 XML과 SQL로 작업할 때 다루게 되는 테이블, 트리, 맵을 관리하는 내장된 원시타입이다. JavaScript의 E4X와 Microsoft의 Cω와 Linq 프로젝트는 내장된 원시타입을 이용한 개발 향상성에 기여하지만, 자바 플랫폼은 이러한 측면에 대구책이 아직은 없는 듯 하다.

프로퍼티

프로퍼티 액세스용 신택스를 보자. 한 가지 제안은 getFoo 와 setFoo 를 호출할 때 간단히 ->를 사용하는 것이다. 따라서, 다음과 같이 쓰는 대신,

Point p = new Point();
p.setX(56);
p.setY(87);
int z = p.getX();

아래와 같이 작성한다.

Point p = new Point();
p->X = 56;
p->Y = 87;
int z = p->X;

.과 #을 포함한 기타 심볼 역시 ->의 대안으로 제시되었다.

앞으로는, Point 클래스의 프로퍼티로서 관련 필드를 구분하거나, 구분하지 않을 수도 있다.

public class Point {

  public int property x;
  public int property y;

}

개인적으로, 전혀 흥미롭지 않다. 나는 자바 플랫폼이 보다 퍼블릭 필드를 실제로 사용할 때 Eiffel 계열의 방식을 채택하기를 바란다. 하지만, getter와 setter는 필드와 같은 이름으로 정의되면, 필드의 읽기와 쓰기는 자동으로 이 메소드로 보내진다. 더 적은 신택스를 사용하고 더 유연하다.

임의 정밀도 연산(Arbitrary precision arithmetic)

연산자 오버로딩 표준 수학 기호를 사용하는 것은 연산자 오버로딩과 같은 것이 아니다. 적어도 C++에서 문제를 일으키는 그러한 종류는 아닌 것이다. '+' 부호와 기타 연산자는 여전히 어떤 프로그램에서든 뚜렷한 의미를 갖고 있다. 이들은 의미를 프로그램마다 수정하지 않는다. 비슷한 연산에 같은 신택스를 사용한다면 코드는 더욱 읽기 쉬워진다. 따라서, 신택스 재정의는 다른 프로그램에서는 다른 것을 의미할 수 있기 때문에 코드 읽기가 더 어려워 질 수 있다.

메소드를 연산자로 대체하는 또 다른 제안은 BigDecimal과 BigInteger에도 해당된다. 예를 들어, 현재 무한 정밀도 연산(unlimited precision arithmetic)을 코딩 해야 한다면,

BigInteger low  = BigInteger.ONE;
BigInteger high = BigInteger.ONE;
for (int i = 0; i < 500; i++) {
  System.out.print(low);
  BigInteger temp = high;
  high = high.add(low);
  low = temp;
};

이것은 다음과 같이 명확히 작성될 수 있다.

BigInteger low  = 1;
BigInteger high = 1;
for (int i = 0; i < 500; i++) {
  System.out.print(low);
  BigInteger temp = high;
  high = high + low;
  low = temp;
};

클래스들의 남용과 이에 따른 퍼포먼스 저하가 있을 수 있지만 이 제안은 그렇게 거슬리지 않는다.

JAR에서 JAM 취하기

Java 7은 오랫동안 자바 개발자들을 짜증나게 했던 다양한 클래스 로더들(class loader)과 클래스 패스와 관련된 문제를 해결했다. Sun은 Java Module System을 사용하여 이러한 문제를 해결하고 있다. .jar 파일 대신, 데이터는 .jam 파일로 저장된다. 이것은 모든 코드와 메타데이터를 포함하고 있는 일종의 "superjar"라고 할 수 있다. 가장 중요한 것은, Java Module System은 처음으로 버전 관리를 지원하기 때문에, 해당 프로그램은 Xerces 2.6이 아니라 2.7.1버전을 필요로 한다고 지정할 수 있게 된다. 또한 종속 관계를 지정할 수 있다. 예를 들어, JAM의 프로그램은 JDOM을 필요로 한다고 지정할 수 있다. 모듈 전체를 로딩하지 않고 하나의 모듈을 로딩할 수도 있다. 마지막으로, 다수의 서로 다른 JAM들에 대한 다양한 버전들을 제공하는 중앙 집중화된 레파지토리로의 역할을 제공해 줄 것이고, 애플리케이션은 여기에서 제공하는 것들 중 필요한 것들을 선별할 수 있다. JMS가 작동하면 jre/lib/ext로의 지정 해야할 일련의 과정은 과거로 사라질 것이다.

패키지 액세스

Java 7은 아마도 액세스 제한을 조금 완화할 것이다. 이는 하위 패키지가 상위패키지에 있는 클래스들의 패키지상 보호되어있던 필드들과 메소드들에 접근할 수 있게 해줄 것이다. 또한, 하위 패키지가 상위 패키지의 페키지상 보호되었던 멤버들 중 명시적으로 접근 가능하도록 정의된 멤버들을 접근 할 수 있도록 해줄 것이다. 두 방법 모두, 애플리케이션을 여러 패키지들로 나누어서 보다 단순하고 테스트 성능도 향상시킨다. 단위 테스트가 하위 패키지에 있다면, 이들을 테스트 할 수 있도록 메소드를 공개할 필요도 없다.

파일시스템 액세스

파일시스템 액세스는 1995년부터 자바 플랫폼의 주요한 문제였다. 10년이 넘었지만, 파일을 복사하거나 이동하는 것 같은 기본적인 작동을 수행하는 신뢰성 있는 크로스 플랫폼 방식이 없다. 이러한 문제를 해결하는 것이 지난 세 개의 JDK 버전들(1.4, 5, 6)의 공공연한 이슈였다. 슬프게도 파일을 옮기거나 복사하는 지루하지만 필요한 API들이 메모리 매핑 I/O 같은 덜 일반적이지만 매력적인 연산에 밀려났다. 아마도 JSR 203은 이 문제를 해결할 것이고 우리에게 실현 가능한 크로스 플랫폼 파일 시스템 API를 제공할 것이다. 작업 그룹은 진정한 비동기식 I/O 문제에 대해 많은 관심을 쏟을 것이다. 내년 이맘때쯤 결과가 나올 것이다.

실험

어떤 변화가 일어나든 오픈 소스 세계에서 가장 먼저 구현된다면 더욱 좋을 것이다. 그래야지만 우리가 얼마나 많은 또는 얼마나 적은 차이를 만들어 냈는지를 볼 수 있기 때문이다. Sun의 Peter Ahe는 java.net에서 Kitchen Sink Project를 시작했다. 목표는 javac 컴파일러를 반복적으로 분기하여 다른 많은 아이디어를 테스트 하는 것이다.

위로

클라이언트 GUI

비록 많은 사람들이 알아채지는 못했지만, 자바 플랫폼은 4~5년 동안 데스크탑에 실제로 존재했다. RSSOwl, Limewire, Azureus, Eclipse, NetBeans, CyberDuck 등을 포함한 일부 양질의 데스크탑 애플리케이션들은 자바 코드로 작성되었다. 이러한 애플리케이션은 Swing, AWT, SWT 같은 거의 모든 GUI 툴킷과 심지어 Mac OS X의 Cocoa 같은 플랫폼 툴킷에 의해 작성된다. 이러한 툴킷 중에서 어떤 것이 더 낫다고 단정지을 수는 없지만, Swing은 원래의 느낌을 갖고 있는 애플리케이션을 생성하는데 다른 것 보다 더 나은 기능을 갖출 것이다.

Swing은 여전히 개발하기에는 도전이 되지만, Swing Application Framework의 출현으로 내년에는 상황이 더 나아질 것으로 보인다. 이 프레임웍은 현재 Java Community Process에서 JSR 296으로 개발 중이다. 다음은 JSR에 대한 설명이다.

잘 작성된 Swing 애플리케이션들은 시작시키고 종료시키는 작업과 리소스, 동작, 세션의 상태들을 관리하는데 있어 동일한 핵심요소들을 가지는 경향이 있다. 새로운 애플리케이션들은 이 모든 핵심 엘리먼트들을 처음부터 만들어낸다. Java SE는 어플리케이션들을 구성하는데 어떠한 지원도 제공해 주지 않고 있고, 바로 이것 때문에 개발자들은 SE 문서에서 설명하는 예제 그 이상으로 확장된 애플리케이션을 구현할 때 당황하게 된다.

Swing 애플리케이션의 기본 구조를 정의함으로써 그러한 허점을 채우기 위하여 정의된 사양서를 제공할 것이다. 이는 대부분의 데스크탑 애플리케이션의 일반적인 인프라스트럭처를 정의하는 확장성 있는 클래스 세트나 "프레임웍"을 정의할 것이다.

Swing Application Framework은 대부분의 전형적인 애플리케이션을 지원하면서, 개발자들로 하여금 시작과 종료와 같은 몇몇 커스터마이징 부분을 추가해 넣을 수 있도록 해줄 것이다. 이는 어플리케이션 시작과 종료 와중에 윈도우나 다른 부분들에 대한 저장과 복구를 다룰 수 있게 해줄 것이다. 마지막으로, 개발자들은 Swing 이벤트 디스패치 쓰레드 외부에서 실행되는 비동기식 액션을 작성할 수 있게 된다.

JavaBeans와 Swing을 향상시키고자 하는 노력이 진행 중이다. JSR 295는 빈들을 바인딩 하는 표준 방식을 정의하여, 하나의 빈이 업데이트 되면 이것이 자동으로 다른 빈에 반영될 수 있도록 한다. 예를 들어, GUI 그리드 빈은 연관된 데이터베이스 빈이 변경되면 자동으로 업데이트 된다.

마지막으로 JSR 303은 XML 기반 밸리데이션(validation) 언어 관련 작업을 진행하여 주어진 빈이 취할 값을 지정한다. int 프로퍼티는 1과 10 사이에 있어야 한다거나, String 프로퍼티에는 합법적인 이메일 주소가 포함되어야 한다는 등을 지정할 수 있다. 올해 말에는 베타 버전으로 이러한 기능을 사용할 수 있을 것이고 내년 이맘때쯤 Java 7에 대한 작업이 끝날 것이다.

위로

데스크탑 언어로서 자바 플랫폼

일부 프로그래머들은 자신들이 선호하는 언어이기 때문에 자바 코드로 데스크탑 애플리케이션을 작성하지만, 대부분은 멀티 플랫폼을 수용하기 위해서이다. 데스크탑 언어로서 자바 플랫폼에 대한 관심은 비 Microsoft 계열 데스크탑의 수와 연관되어있다. 세 가지 주요 데스크탑에서의 자바 프로그래밍에 대해 알아보자.

Windows

Swing은 특히 오픈 소스 개발로의 전향과 아울러 여전히 내년까지도 Windows 룩앤필을 향상시킬 것이다. 결국, LimeWire 같은 순수 자바 프로그램들은 Windows 보다 자연스러운 모습을 보이게 될 것이다. 하지만, 원래의 Windows 애플리케이션 개발 언어는 C#(일부 C 와 C++ 포함)이다. 그리고 프레임웍은 .NET이 될 것이다. 자바 코드는 Windows 생태계에 깊이 관여하지는 않을 것이다.

Macintosh

Microsoft와 마찬가지로 Apple Inc.도 자바 코드를 거의 포기했다. Apple은 Objective C 와Cocoa를 선호하지만 그의 결과 또한 같다. Mac 전용 개발자들은 Apple의 주력 언어와 환경에서 자바 코드를 제거하려는 시도를 계속해서 하고 있다.

긍정적인 측면은, Apple은 QuickTime과 Cocoa 같은 상용 API에 대해 자바 코드를 더 이상 지원하지 않지만 Apple VM은 그 어느 때보다도 훨씬 더 나아졌다. Apple의 Java 6 포트가 곧 릴리스 될 것이다. (Sun의 JDK와는 달리) 오픈 소스는 아니지만, 오픈 소스 프로그래머들이 버그를 픽스할 것이다.

Linux

GPL 라이센스로 자바 코드를 가장 순수한 오픈 소스 리눅스로 함께 묶을 수 있는데, 이로써 자바 플랫폼은 매력적인 리눅스 개발용 언어로서 한층 더 다가갈 수 있다. 이러한 상황이 5전 전에만 일어났다면, 리눅스 커뮤니티는 C 때문에 고생을 하지 않아도 되었을 것이고, Mono도 불필요했을 것이다.

Gnome과 KDE용 자바 바인딩은 내년에는 더욱 많은 관심을 끌 것이다. C, C++, 또는 C#이 아닌 자바 코드를 사용하여 리눅스 GUI 프로그램을 개발하는 적어도 한 개 이상의 주요 프로젝트가 시작될 것으로 보인다.

위로

Ruby가 경쟁에서 이기다!

Bloatware JavaScript는 이미 JDK 6에 번들되었다. 추가 언어는 JDK 7에 추가될 것이다. 너무 부풀려지는 느낌이다. Sun이를 멈출 수 있는 방법이 없다. BeanShell을 선택하면 Groovy쪽 사람들도 개입하고 싶어할 것이다. Groovy가 들어오면, Ruby 사용자들도 들어오려고 할 것이다. Ruby가 개입되면 Python은 가만히 있을까? 표준 JDK는 이미 너무 방대해졌다. 여러 스크립팅 언어를 지원하는 것도 큰 일인데, 번들링까지는 무리이다. 해결책으로 이들 모두를 지원은 하겠지만, 어떤 것도 번들하지는 않을 것이다. 긍정적인 측면은, Sun은 초기의 다운로드 사이즈와 애플리케이션 시작 시간을 줄이는 방안을 모색하고 있다. 특히 애플릿과 Java Web Start 애플리케이션에 대해 그렇게 하고 있다. 거대한 클래스 라이브러리가 서버에 남겨지고, 필요한 부분만 다운로드 될 것이다.

우리가 단 하나의 언어로만 대화한다면 이 세상은 매우 지루할 것이다. 자바 플랫폼은 애플리케이션 개발에 있어서 최상의 선택이지만, 작은 프로그램이나 매크로에는 절대로 맞지 않는다. Java 6은 이를 인식하고 BeanShell, Python, Perl, Ruby, ECMAScript, Groovy 같은 스크립팅 언어와 통합하기 위해 javax.script 패키지를 추가하고, invokedynamic 가상 머신 명령을 Java VM에 추가하여 Java VM이 직접 동적으로 기술된 언어들을 컴파일 할 수 있도록 했다.

비록 내가 개인적으로 선호하는 것이 아니지만, 2007년에 나는 Ruby에 돈을 투자할 것이다. Python 코드는 훨씬 더 깨끗해진 것 같고, Ruby 코드보다 이해하기가 더 쉽다. 아마도 이 부분에 대해서는 대부분의 자바 프로그래머들도 동의할 것이다. Python은 시기를 잘못 타고 태어났다. 많은 개발자들은 Python을 배우는 것과 자바 코드를 배우는 것 중 선택해야 했고, 대부분이 자바 코드를 선택했다. 그들이 자바 신택스를 다 이해하고 다른 언어를 받아들일 준비가 되었을 때는 과거의 언어가 아닌 미래의 언어를 택하기 마련이고, 그것이 Ruby일 듯 하다. 가장 중요한 것은 Ruby는 Ruby on Rails의 절대적인 킬러 애플리케이션을 갖고 있다. 이것의 단순함은 현실적인 Java Enterprise Edition (JEE) 개발자들에게는 매우 매력적으로 비춰진다.

Rails 이상으로, JRuby 프로젝트는 다른 스크립팅 언어들 보다 기존 자바 코드와 라이브러리와 더 나은 통합을 시도한다. 사실, JRuby는 표준 Ruby를 누르고 Ruby를 사용하는 자바 프로그래머들뿐만 아니라 Ruby 프로그래머들도 선호하는 플랫폼이 되었다. 좋은 일이다. Ruby는 막강하나 Python은 그렇지 못하다는 것은, 슬프지만 진실이다.

다른 스크립팅 언어들은 점점 더 쇠락해 갈 것이다. Perl은 너무 구식이고 현대적인 애플리케이션과 잘 맞지 않는다. Groovy는 뚜렷한 비전이 없이 유용성이나 친숙성을 떠나 컴퓨터-과학 분야의 전문언어로 채택되는 경향이 있다. BeanShell, Jelly, 그리고 일부 언어들도 관리가 되고 있지 않다. Ruby가 자바 프로그래머의 스크립팅 언어가 될 것인지는 내년까지 승부가 갈릴 것이다.

위로

IDE가 점점 나아지고 있다.

2006년은 IDE에게 있어서 최악이었다. 이클립스에 당황한 Sun은 그들의 에너지와 리소스를 NetBeans에 쏟아 부었고, 결국엔 막강한 경쟁자가 되었다. 어떤 면에서, NetBeans는 2006년 말에는 이클립스를 능가하는 것처럼 보였다. 훨씬 더 나은 룩앤필과 GUI를 디자인 하는 훨씬 더 나은 툴을 갖고 있었다. 반면, NetBeans가 갖지 못한 것은 이클립스와 같이 커뮤니티가 활성화 되지 못했다는 것이다. 훨씬 더 많은 플러그인과 서드 파티 제품들이 NetBeans 보다는 이클립스에 기반하고 있다. 이러한 추세는 점점 더 가속화 될 전망이다.

이클립스는 3.3 버전을 위해 힘들게 작업 중이고, 2007년에는 릴리스 될 것이다. Sun은 올해 NetBeans 6를 출시할 것이다. 두 개 모두 메이저 릴리스가 될 것 같지는 않다. 단순히 여기 저기에 작은 기능들을 추가하고, 버그를 픽스하고, 사용자 인터페이스를 정리한 정도이다.

NetBeans는 계속해서 Eclipse의 영역에서 시장 점유율을 높여갈 것이며, 그의 성장 가능성또한 아주 많다. Sun의 집요한 JDK 다운로드에 NetBeans 끼워 넣기는 무리 없어 보인다. 올해 말까지 두 개의 IDE는 시장을 양분할 것이다.

한편, IntelliJ IDEA 사용자들은 이러한 모든 상황에 개의치 않고 자신들이 최상의 Java IDE를 사용하고 있다고 자부하고 있다. 하지만, 대부분의 사용자들은 $500이 넘는 가격을 부담스러워 할 것이고 시장 점유율은 5%에 그칠 것이다.

위로

Java Enterprise Edition

자바 프로그래밍의 어떤 부분도 JEE 만큼 성공적이면서도 욕을 먹은 부분은 없다. 이것은 모든 사람들이 애증을 갖고 있는 기술이다. 복잡하고, 혼란스럽고, 무겁다. 자바 프로그래밍의 어떤 부분도 이를 대체하기 위해 그렇게 많은 노력을 들인 적이 없다. Spring, Hibernate, Restlet, aspects, Struts ...등 끝이 없다. 그럼에도 불구하고, 거의 모든 자바 프로그래머들은 JEE를 찾고 있기 때문에 Sun은 이 부분을 신경을 써야 할 것이다.

엔터프라이즈 세계에서 내가 목격한 경향 중 하나는 단순함에 대한 열망이다. 많은 프레임웍들이 나와 있으며, 그 안에서 작고 단순함을 선호하는 추세다. 점점 더 많은 고객들은 JEE 스택의 큰 부분을 거부하고 있고 이러한 추세는 지속될 전망이다. 대신 고객들은 Spring 같은 단순한 프레임웍으로 전향하거나 Ruby on Rails를 사용하는 추세이다. 더 단순하고, 보다 이해하기 쉬운 시스템에 대한 열망은 서비스 지향 아키텍처(SOA)와 Representational State Transfer (REST)에 대한 관심을 증폭시키고 있다.

2007년에도 단순함에 대한 추세는 지속될 것이다. Rails에 탄력을 받은 많은 사람들은 Python (Turbo Gears), Groovy (Grails), Java (Sails) 같은 다른 언어에서도 성공하기 바란다. 이들 중 하나는 성공하겠지만, 그렇지 않을 경우 더 이상의 새로운 것은 없다. 결국, 비즈니스는 그들이 이미 갖고 있는 SOA, REST, Rails를 계속 사용할 것이다.

위로

Java Micro Edition

단순하고 작은 것에 대한 열망이 임베디드 분야에도 적용될 수 있을까? 지난해 동안 자바 플랫폼은 작은 장치에 있어서 큰 성공을 거두었고 2007년에도 그러한 동력을 계속 이어갈 전망이다. 우선, Mobile Information Device Profile (MIDP)의 버전 3이 기대된다. 특히, 여러 MIDlet을 하나의 VM에서 실행할 수 있게 될 것이고, 백그라운드 에서는 한 개 이상을 실행할 수 있다. 또한 암호화된 레코드 관리 시스템(RMS) 스토어와 IPv6 지원도 기대된다.

현재 개발 중인 Java ME용 Scalable 2D Vector Graphics API 2.0은 많은 장치에서 사용할 수 있는 애니메이션 기능을 확대하고 있다. SVG 애니메이션 외에도 오디오 및 비디오 스트리밍도 실행한다. 모바일 네트워크가 열리면, 정말로 중요해진다. 셀폰의 YouTube를 생각해 보라. (물론, 네트워크가 연결되지 않으면, 이것은 어떤 누구도 보고 싶지 않은 2인치 짜리 기업 광고일 뿐이다. 미국에서 이것이 실현될지 의문이지만, 유럽에서는 가능하리라고 본다.)

모바일 개발자들은 Java ME용 XML API를 지원하는 원년이 될 것이다. 이 API는 전화기의 제한된 메모리 환경에 맞도록 설계된 SAX, DOM, StAX, JAXP의 하위 세트이다. 많은 사람들은 순수한 XML은 전화기에는 맞지 않는다고 생각한다. 올해에는 이것이 옳은지, 그른지 판가름 날 것이다.

모든 좋은 소식에도 불구하고 Apple의 iPhone은 여전히 모바일 폰 개발 플랫폼으로서 자바 플랫폼에 위협적인 존재가 될 것이다. iPhone은 출시된 지 여섯 달 만에 최고의 주목을 받고 있다. 문제는 폐쇄 플랫폼이라는 것이고, 셀폰 네트워크 표준에 의해서도 자바 코드를 실행할 것 같지 않다. 이는 모바일 폰, PDA, 개인용 커뮤니케이터용 서드 파티 애플리케이션을 판매하려는 사람들에게 끔찍한 소식이 아닐 수 없다.

위로

요약

JDK의 오픈 소스 전향 덕택에, 2007년은 자바 프로그래밍 역사 이래 최고로 흥미로운 한 해가 될 것이다. 지금까지, 자바 플랫폼은 Sun의 목표나 투자로만 제한되었지만, 이러한 현상도 곧 바뀔 전망이다. 개발자 커뮤니티의 막강한 힘으로 자바 프로그래밍은 어디든 항해할 수 있다. 개발자들은 전보다 더 자바 코드로 더 많은 일들을 할 수 있다. 데스크탑, 서버, 임베디드 이 모든 것들이 가속화 될 것이다. 하지만 이러한 엔진들도 일시적으로 멈출 때가 있을 것이다. 좋은 것은 살아남고, 그렇지 않은 것은 사장될 것이다. 자바 플랫폼에서 좋아하지 않는 부분이나 여러분을 괴롭혔던 것이 있다면 여러분의 IDE를 띄워 해킹을 시작해 보는 것도 좋다.

여러분이 갖고 있는 컴파일러를 지금 시작해 보기 바란다.

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

기사의 원문보기

• Java 2007: The year in preview

1. 클래스의 호출 순서

제목 : 자바에 대한 개념을 흔들어 놓는 소스다...

db책은 시간이 없어서 그냥 와우북에서 보고 영진껄루 사서 보았다....전체적인 개념잡기는 쉬운데...책 두께에 비해 깊은 내용이 없더군....하여간 엽기적인 소스를 만난 덕에 또 이렇게 글을 띠운다....

답변: 자바 버츄얼머신 스펙을 참조...
 
덕분에 썬 사이트에 가서 자바 버츄얼머신 스펙을 꼼꼼히 읽어보았다.
클래스를 초기화 할때 즉 생성하면 생성자가 제일 먼저
불리우는 것이 아니었다.
간단하게 말을 하겠다.

그래야 잊지 않고 나도 기억하기 쉬우니까.
비록 정확한 대답은 아니라고 해도 전혀 틀린 것도 아니니까.

이건 만은 기억하자.

1. static을 초기화한다.
2. field를 초기화한다.
3. 생성자를 호출한다.

그러니까 소스에서는 ClassInitTest를 생성하면
1. 이 클래스내의 static을 초기화한다.
출력: static int monthDays[];...

2. 다음은 필드를 초기화한다.
필드 A a; 가 있으므로 클래스 A를 생성할 것이다.
이 클래스에도 static이 있기 때문에 이를 초기화한다.
출력: A클래스 스태틱 로딩

3. 그리고, A() 생성자를 호출한다.
출력:A()

4. 다음행 실행
출력:A a

5. 다음은 ClassInitTest의 생성자를 호출.
생성자에서 this(0)이라는 인자 있는 생성자를 호출하므로
출력:ClassInitTest(int x)

6. 다음행 샐행
출력:ClassInitTest()

7. 다시 다음행 실행
출력:new ClassInitTest()

아휴~ 힘들다. 1000자 넘기지 않으려고 말을 짧게 썻다.
이해해라.

2. 텍스트 필드에 저장할 수 있는 문자열의 최대 길이

먼저 질문부터 하겠습니다.

Form의 method방식을 get으로 지정했을 경우에 전달할 수 있는 최대 문자열의 길이는 ?

HTTP 데이터 전송 방식에는 get과 post 방식이 있습니다. get방식은 URL에 "이름=값"의 형식으로 데이터를 전송합니다. 쉽게 설명하자면 우리가 많이 사용하고 있는 인터넷 익스플로러를 잘 관찰하시면 다음과 같은 주소를 보시게 될 겁니다.

folderselect=639096&rand=9935556036482

이름과 값을 위와 같은 형식으로 서버에 전달하는 것입니다. 이렇게 get 방식으로 전달할 수 있는 스트링의 길이는 도대체 얼마나 될까 알아보았습니다.

알파벳과 한글 모두 2047문자까지 들어가더군요. 하지만 엄밀히 따지면 앞에 주소도 있고 기다 경로를 제외하면 조금 작아지겠지요. 그런데 실제 데이터를 get 방식으로 전달해 보면 그 보다 훨씬 미치지 못하는 길이만이 넘아갔습니다. 한글로 대략 340문자까지만 전송이 되었습니다[필자가 해보니깐 정말 변수명을 어떻게 하느냐에 따라 틀리고 사파리는 한글이 안된다;;;; 머 어쩌라구]. (+- 오차는 10문자 정도) 이를 post 방식으로 다시 전송하였더니 2000자 이상이 거뜬이 전송되었습니다.

이로써 get 방식과 post 방식의 또 다른 차이점을 알았습니다. 님들도 많은 양의 데이터를 전송할 때는 post 방식을 사용하세요. 무심코 get방식을 사용한다면, 왜 데이터가 제대로 전송이 되지 않는지 그 이유를 찾는데 한참을 보내야 할 겁니다.

3. 각종 데이터 타입의 최대값

• MS Access의 MEMO 데이터 형 : Up to 65,535 characters
• 유닉스의 IPC중 메시지큐 : 메시지의 최개크기 (4096), 큐의 최대 크기(16384)

• 자바 자료형의 최소/최대값

4. 네트워크 바이트 순서

바이트 오더(byte order)에는 두 가지가 있다. little endian과 big endian이다.

• little endian : 작은 수를 끝에 놓는다.
• big endian : 큰 수를 끝에 놓는다.

little endian은 56이란 수를 56으로 표현하고, big endian은 56을 65로 나타낼 수 있다는 말이다.

네트워크 상의 byte order은 big endian이다. 가령 little endian 머신에서 little endian머신으로 데이터를 전송한다면 문제가 없다 거꾸로 big endian에서 big endian으로도 마찬가지다. 문제는 다른 방식의 두 머신이 통신을 할 때이다.

일단 네트워크로 데이터를 전송할 때는 네트워크 바이트 순서로 바꿔준 다음 데이터를 수신한 쪽에서 자신의 머신에 맞게 순서를 다시 조정하면 된다. 소켓에선 이런 일을 도와주는 함수가 있으며 htonl, htons, ntohl, ntohs와 같은 것들이 바로 이런 일들을 한다.

참고로 SUN, IBM들은 big endian형식이고 Intel은 little 엔디안 형식이라고 한다. 왜 이렇게 두 가지 방법이 있어서 번거롭게 하는지 모르겠다. 한가지밖에 없다면 아무 신경 쓰지 않고 통신을 하면 될텐데...

5. JAVA 기초 문법 중에서

• 같은 파일 안에 public class는 단 하나만 존재할 수 있으며 클래스는 파일이름과 같아야 한다.
• float 형의 유효 데이터는 소수점이 있는 숫자로 끝에 F 또는 f가 붙은 숫자이어야 한다.
  float f = 1.3 -> ( X )
  float f = 1.3f -> ( O )
  소수점만 있을 경우에는 double형으로 인식된다.

• 같은 클래스내에서 메소드를 overloading할 때
  리턴타입은 상관없이 메소드의 인자만 다르면 된다.

• 헷갈리는 overloading과 overriding 구분하기

I. 자바 웹스타트 소개
-------------------------------

  자바 웹스타트는 2001년 초에 소개된 기술로 한번 클릭으로 자바 애플리케이션을 쉽게
수행 시킬 수 있는 환경으로 자바가 추가하던 사상 즉 "언제 어디서나 같은 코드로서
쉽게 접근하고 강력한 기능을 발휘하는 언어" 라는 강점을 유감 없이 발휘할 수 있는 
기술이다.

  자바 웹스타트는 기존의 웹 환경의 한계점을 뛰어넘어 네트웍으로 자유롭게 풍부하고
강력한 응용프로그램을 실행 시킬 수 있으며, 버젼 및 배포 관리를 자동으로 수행하는 
JNLP(Java Network Lanunching Protocol)을 기반으로 하여 관리함으로서 기존의 클라이언트
윈도우즈 프로그램의 문제점을 극복하고 새로운 파라다임을 제시한다.

자바 웹스타트의 장점을 요약하면 다음과 같다.

1. 바탕화면이나 웹화면의 아이큰을 단 한번 클릭함으로서 자동 다운로드 및 캐쉬를 사용한
   응용 프로그램이 구동되어 빠르고 쉽게 자바 응용 프로그램을 실행할 수 있다.

2. Linux, Mac, Windows 등 다양한 플랫폼에서 동일한 User Interface로 실행됨으로 
   OS로 부터 독립적인 환경을 제공한다.

3. 웹 환경의 단순한 HTML 및 JavaScript로 구현되던 User Interface를 보다 강력한 자바
  UI 기술인 AWT/Swing을 이용하여 구현할 수 있다.

4. 응용프로그램이 자동적으로 캐쉬되고 업데이트 됨으로 첫번째 구동 이후에는 매우 
  빠른 속도록 응용프로그램이 시작된다.

5. Java 2의 보안 모델 Signed Application 및 "sand box" 모델이 적용됨으로
  사용자들은 보다 안전한 환경에서 강력한 UI를 사용할 수 있다.


자바 웹스타트를 좀더 잘 이해 하기 위하여는 Client/Server 아키텍쳐 맥락에서 Client를
크게 Thin Client (가벼운 클라이언트) 와 Rich Client(강력한 기능의 클라이언트)로 나누어 보고
이 둘의 장단점을 비교해보면 서로의 성격을 좀더 확실히 이해할 수 있다.

Thin Client란 Web Browser와 같이 이미 사용자 환경에 Client가 설치되어 있고, 서버로부터
가벼운 HTML과 같은 화면 정보를 받아 화면을 매번 그려주는 체계를 말한다.

- 가벼운 클라이언트 환경 (web browser) 장점

    . Browser 만 있으면 언제 어디서나 가볍게 화면을 접속하여 볼 수 있다.
    . 화면 자체를 간단히 HTML 로 구성할 수 있다.
    . Hyper link 를 이용하여 화면 Navigation을 할 수 있다.
    . SessionLess 처리를 이용하여 짧은 트렌젝션을 많이 처리하는데 적합하다.
    . 문서 등을 보여주는 (Browsing) 하는데 효과적이다.

- 가벼운 클라이언트 환경 (web browser) 단점

    . HTML의 한계 때문에 복잡한  UI 또는 기능성 있는 입출력 구조를 처리하기 어렵다.
    . JavaScript 나 Dynamic HTML은 Language 자체가 유동성이 많고
      환경 오류의 가능성이 높다.
    . JavaScript 또는 Dynamic HTML은 완전한 Language 또는 객체 지향적 Language가
      아니라 유지 보수성 및 생산성이 떨어진다.
    . 전송된 자료가 쉽게 Browser를 통하여 노출되기 때문에 보안성이 떨어진다.
    . HTML의 한계 때문에 다량의 자료 처리가 쉽지 않다.
    . 옵션 및 환경이 Browser에 의존적이기 때문에 사용자 환경마다 처리될 때도 있고
      처리가 않 될 수도 있다.
    . 트렌젝션 마다 Image + HTML + Data 가 함께 내려 옮으로써 처리 속도가 저하된다.


Rich Client(강력한 기능의 클라이언트) 란 기존의 C/S 시스템 또는 전용 Browser 나 
Windows 프로그램과 같이 특정 업무에 맞도록 화면을 개발하고, 메뉴, 아이콘, 테이블, 트리,
드래그드랍등 다양하고 강력한 사용자 화면과 인터페이스를 구성하는 것이다. 

Browser와 같이 이미지 디자인 같은 작업이 별도로 필요 없는 대신에 Excel 처럼 필드 위주의
강력한 기능을 구현할 수 있는 것이 특징이다.


- Rich Client의 장점

    . 강력하고 기능성 있는 GUI 를 제공한다. (Spread Sheet, DeskTop, Tree, Drag and Drop 등등)
    . Browser에 의존하지 않고 개인 PC의 화면에서 바로 실행 가능하다.
    . Remote 환경 뿐만 아니라 Local 환경, DB, Network 처리, File 처리 등이 자유롭다.
    . 서버와 데이타 만 주고 받기 때문에 속도가 빠르다.
    . 다량의 데이타를 local 과 서버 작업으로 분산 처리가 가능하기 때문에 다량 처리에 적합하다.
    . Browser 의존적이 아니기 때문에 PC 자체의 환경 문제가 적다.
    . 객체 지향적 모델로 GUI를 만들기 때문에 유지 보수성이 뛰어 나다.
    . 전송되는 자료가 쉽게 노출되지 않으므로 보안성이 우수하다.

- Rich 클라이언트의 단점
   
    . 프로그램 설치가 필요하여 초심자가 설치할 시에 오류가능성이 있다.
    . 설치된 프로그램이 다른 요인으로 손상될 수 있다.
    . 반드시 모듈이 설치된 PC에서만 작동한다.
    . 프로그램 변경 또는 Version Up이 발생하면 다시 배포해야 한다. (Version 문제 가능성)
    . 대부분 MicroSoft Windows 환경이기 때문에 Windows 버젼 및 환경 때문에 
      오류 발생 가능성이 있다.


Java Web Start는 Thin Client와 Rich Client의 장점을 동시에 수용하고 각각의 단점을 서로
보안할 수 있도록 통합시킨 기술이다.

  Java Web Start 기술을 채용하면 Thin Client 처럼 어디서나 쉽게 접근하여 가볍게 사용할 수
있을 뿐만 아니라 Rich Client와 같은 강력한 기능을 구현할 수 있어 웹 기술과 C/S 기술을
동시에 채용하여 비용 대비 성능이 가장 우수하다.

 - Java Web Start 는 Thin Client 의 장점과 Rich Client의 장점을 통합한 기술이다.

      . web 환경과 같이 언제 어디에서든 손쉽게 사용할 수 있다. (아이콘 클릭으로 시작)
      . plug-in 이 자동으로 설치되며 일단 설치되면 다시 설치할 필요 없다. (웹으로 시작 가능)
      . Application 모듈이 local 에 cache 되어 자동으로 버젼을 체크하여,
        download 시간이 대폭 축소된다.
      . C/S 환경이 갖고있는  강력하고 다양한 GUI 기술이 Swing을 통하여 구현되며, 
        독립 데스크 탑 환경으로 갈 수 있다.
      . Web Version 이나 Client Server 버전을 따로 개발할 필요가 없다. Web Start 가
        두개의 환경을 단일 코드로 지원한다.
      . JavaScript, DHTML 등에 의존하지 않고, 독립환경의 단일 기술로 이루어짐으로서
        오류 가능성이 적다.
      . 결국 손쉽게 접근할 수 있는 Thin Client 의 장점과 강력한 GUI 및 작업 기능의 
        Rich Client 의 장점을 동시에 구현하는 것이다.


Java Web Start 환경적 특징을 살펴보면 다음과 같다.

- Java Web Start 환경은 새로운 기술이라기 보다는 Java 기술의 최종 완성된 형태이다.

- Web Version 이나 Client Server 버전을 따로 개발할 필요가 없다.

- JVM Version 1.4는 자동으로 Install 된다.

- XML, Security, Messaging 등 최신 기술 Component 가 같이 포함되어 있다. (미래가 있다.)

- Web Start 는 자동으로 Caching 을 하여 빠르다.

- Web Browser 나 MS Windows 환경에 독립적이다.

- 따로 Desktop 환경을 구성할 수 있다.

II. 웹스타트 실행하기
-----------------------

  자바 웹스타트가 어떤것인가를 가장 직관적으로 알 수 있는 방법은 실제로
웹스타트로된 시스템을 실행해보는 것이다.  웹스타트는 앞에서도 설명했듯이
언제 어느 곳에서나 쉽게 실행해 볼 수 있다는 장점을 가지고 있다.  따라서
여러분들이 지금 일반적인 네트웍 환경과 PC 환경을 가지고 있다면 직접 
웹스타트 시스템을 실행해 보는 것이 자바 웹스타트를 가장 빨리 이해하는
지름길 이다.

  본 강좌에서는 자바 웹스타트로 된 시스템을 실행해보기 위하여 JComtech에서
개발한 "JDMS"를 예제로 하겠다.  JDMS는 통신 판매(Direct Marketing) 회사들을
위한 판매관리 ASP 시스템으로, 현재 몇개 회사가 JDMS를 공동으로 사용하고 있다.
상용 시스템임으로 테스트 사용시 무리한 트렌젝션을 발생시키지 않기를 바란다.

  JDMS에 접근하려면 우선 웹브라우져에서 http://jdms.jcomtech.co.kr로 가서
홈페이지를 방문한다.  홈페이지에는 JDMS에 관련된 소개 및 사용법, 사용자 게시판
으로 구성되어 있다. 이러한 내용들은 업무관련 내용임으로 간단히 읽고 참고하기
바란다.

  자바 웹스타트로 JDMS를 실행하려면 홈페이지 좌측 상단에서 "Application"이라는
메뉴를 찾아 클릭한다.  이 메뉴를 클릭하면 우선 사용자 브라우져에 JRE 1.4 버젼이
설치되어 있는가를 검사한다.  만일 설치가 되있지 않다면 자동으로 Plug-in을 설치
하도록 되어 있다.  만일 JRE 1.4를 설치하겠냐고 묻는 화면이 나오면 "예"를 눌러
설치하도록 한다. 설치하는데는 다소 시간이 걸린다. 하지면 처음 실행시 한번만
실행하면 된다.

  자바 웹스타트는 자바 1.2 버젼부터 소개되었지만  1.4 버젼에서는 설치 및 운용이 
자동으로 되기 때문에 더욱편리하다.  따라서 본 강좌는 자바 1.4 버젼을 전제로
진행 하겠다.

  JRE 1.4가 모두 설치되었다면 브라우져 화면에 자바 로고와 "JDMS Web start [시작]"
라는 메뉴가 나온다.  이를 클릭하면 자바 웹스타트 로고가 나오면서 프로그램이
설치되어 있는 웹서버로부터 자바 클레스 화일들을 다운로드 받는 화면들이 진행된다.
처음 실행할 때는 웹서버로부터 JDMS를 실행하기위하여 필요한 모든 화일들을 다운로드
받겠지만 다음번 부터는 버젼이 변경된 부분만 다운로드 받기 때문에 속도가 매우
빨라진다.

  자바 프로그램 다운로드가 성공적으로 이루어지면 즉시 프로그램이 실행되면서 JDMS
로그인 화면이 나오게 된다.  로그인 아이디와 암호는 jcom/jcom으로 한다.  아이디와
암호가 맞으면 스윙으로 구성되 단독 윈도우가 실행되며, 드디어 JDMS 시스템 화면이
나오게 된다.  화면에 있는 메뉴들을 한번씩 실행해보며 시스템이 어떻게 실행되는지
경험해보기 바란다. 구체적인 JDMS은 업무 구성이나 사용법은 본 강좌에서 생략하도록 
한다.  

  JDMS를 한번 둘러보았다면 화면을 종료하고 브라우져도 닫기 바란다.  그러한 후에
여러분 PC에서 윈도우 바탕화면에서 Java Web Start 아이콘을 찾아보기 바란다.
정상적인 경우라면 JRE 1.4를 설치하면서 바탕화면에 "Java Web Start" 아이콘을 만든다.
이 아이콘은 웹스타트 설치를 관리할 수 있는 "Java Web Start 응용프로그램 관리자"를
실행하는 아이콘이다.

  Java Web Start 응용프로그램 관리자에는 PC에서 실행된 적이 있는 응용프로그램과
SUN에서 제공하는 몇가지 예제 프로그램을 실행할 수 있는 아이콘이 있어 웹브라우져를
통하지 않고도 직접 자바 프로그램을 실행할 수 있다.  웹브라우져에서 실행한 적이 
있는 JDMS로 아이콘으로 직접 실행할 수 있을 것이다.  Java Web Start 응용프로그램
관리자를 이용하지 않고 직접 JDMS를 바탕화면에 등록하여 사용할 수도 있는데 이는
프로그램 실행시 등록 여부를 물어서 아이콘 등록을 하게된다.

  이렇게 JRE 1.4 Plug-in을 설치하고 JDMS를 실행하였다면, 여러분은 자바 응용프로그램
시스템인 JDMS를 웹페이지에서도 실행할 수 있고, 직접 바탕화면에서도 실행할 수 있게
된다.  그러고 처음 실행할 때문 프로그램 다운로드 시간이 걸리겠지만 두번째 부터는
프로그램이 빠르게 실행된다는 것을 느낄 수 있을 것이다.  프로그램 Caching 및 버젼
관리는 웝스타트 환경이 자동으로 해주기 때문이다.

  JDMS를 다시 웹에서 실행해보고 또 다시 바탕화면에서 번갈아 실행해봄으로서 사용자들이
어떠한 환경에서 사용하게되고 어떠한 장접이 있는지 직관적으로 알게될것이다.

  개발자 입장에서 이러한 환경을 잘 분석해보면 응용 프로그램은 자바가 제공하는 AWT 및
Swing으로 만든 윈도우 환경이라는 것을 알게될 것이다. 결국 웹스타트 환경에서 응용
프로그램을 잘 개발하려면 자바 순수 프로그램 및 자바 UI 프로그램(AWT/Swing)기술이 
기본적으로 있어야 하면 웹스타트의 서버 환경은 웹서버 설치후 자바 클레스를 묶은 jar
화일및 jnlp 프로토콜 mine 타입을 지정하면 된다. 이러한 서버 설정 방법은 이 후에 
다루도록 한다.

III. 간단한 프로그램 만들기 
------------------------------ 

자바 웹스타트 환경을 만들려면 우선 그 환경에서 실행될 응용 프로그램이 필요하다. 

비교적 간단한 프로그램으로 자바 웹스타트의 다양한 측면을 테스트 하기 위하여 자바 Swing으로 

간단한 편집기를 만들어 보겠다. 간단한 편집기의 클래스 명은 SimpleEditor로서 다음과 같은 

화면으로 구성되어 있다.

[소스보기 - 파일첨부 참조] 소스를 살펴보면 우선 buildGUI() 메소드에서 

메뉴와 화면을 만들며 그리고 이벤트 처리를 위한 리슨너 등을 추가하고 있다. 

주요 기능 및 메소드를 살펴보면 다음과 같다. 

- buildGUI() 화면의 필드와 메뉴를 만들며, 이벤트 처리가 가능하도록 각각의 컴퍼넌트에 

ActionListener 및 DocumentListener를 추가하고 있다. 

- checkUpdate() 테스트 필드에 변경이 있으면 이를 화일에 저장할지를 묻고, 

사용자가 "예"를 선택하면 이를 화일에 저장한다. 

그리고 "취소" 버튼을 누르면 취소를 true 값으로 리턴한다. 

- newFile() 화면을 clear하고 상태를 초기 상태로 바꾸어 새로운 화일을 편집할 수 있도록 한다. 

- open() FileChooser를 이용하여 기존의 테스트 화일을 열고 이를 테스트 필드에 보여주는 
         기능을 한다. 

- close() 편집하던 화일을 닫는 기능을 수행한다. 

- save() 편집하던 화일을 저장하는 기능을 수행한다. 만일 화일명이 없으면 FileChooser를 
         이용하여 화일명을 지정하도록 한다. 

- exit() 편집하던 화일이 있으면 저장하고 편집기 프로그램을 종료한다. 

 위의 메소드들은 각각의 메뉴 선택시에 actionPerformed 메소드에서 실행되면 

현재 화일 문서가 변경되었는가의 여부는 DocumentListener를 사용하여 이벤트 처리한다. 

이 프로그램을 실행하려면 SimpleEditor.class 화일을 JRE가 설치된 PC에 복사하고 

단지 "Java -classpath . SimpleEditor" 라는 명령어를 치면 실행되어 아무런 문제 없이

 Local Computing 환경에서 사용할 수 있다. 하지만 다음 문제는 이 프로그램을 여러사람이

 자바 웹스타트를 이용하여 네트웍 환경으로 여러사람이 사용할 수 있게하는 것이다. 

이러한 환경은 응용 프로그램에 추가적인 고려 사항이 필요하며 또 자동 배포를 수행할 수 있는

 웹 서버가 필요한데 자세한 내용은 본 SimpleEditor 프로그램을 예제로 다음 장에 계속하여

 설명하겠다. 

IV. 웹스타트 응용프로그램
-------------------------

기본적으로 웹스타트 응용프로그램은 SimpleEditor에서 보았듯이 Java2 개발 방법을 사용하며 public static void mina(String[] arg)의 메인 함수에 의하여 실행된다.  하지만 이러한 응용프로그램을 웹스타트와 같이 자동 다운로드 환경에서 사용하려면 보안 및 공유 환경때문에 다음과 같이 몇가지 고려해야 할 사항이 있다.

- 자바 class화일들은 다운로드가 용이할 수 있도록 모두 JAR 화일로 묶어야 한다.

- 그림 화일이나 추가적인 화일 및 자원을 사용한다면 이 모든 것을 JAR로 묶어야 한다.

- SandBox 보안 모델을 사용함으로 다음과 같이 Local 시스템 자원을 사용하지 못한다.

  . local disk 및 native libarary를 사용하지 못한다.
  . Network 자원은 자신이 download된 서버로부터 뿐이 사용하지 못한다.
  . Security Manager을 설치할 수 없으며, 시스테 프로퍼티를 제한적으로 사용한다.

- 이러한 보안상 제약점을 넘으려면 signed JAR 화일을 사용해야 한다.



그럼 SimpleEditor.class를 이러한 사항을 고려하여 배포 준비를 해보도록한다.

우선 SimpleEditor.class를 다음과 같은 JAR 커멘드를 이용하여 .jar 화일로 묶는다.

-----------------------------------
prompt> jar cvf editor.jar *.class
-----------------------------------

이렇게 하면 배포할 수 있는 editor.jar 화일이 생성된다. 만일 클레스 화일 또는 이미지,
리소스 등 화일이 여러개라면 jar 커멘드를 이용하여 같은 화일에 묶도록한다.

SimpleEditor 프로그램은 화일을 읽거나 저장하기 위하여 local 디스크를 접근한다.
하지만 일반 jar 화일로는 SandBox 보안 모델 때문에 local 디스크를 접근할 수 없다.
따라서 local disk에 접근할 수 있는 권한을 부여하기 위하여 다음과 같이 jar 화일에 keytool 및 jarsigner를 이용하여 인증서 sign을 할 필요가 있다. (keytool 및 jarsigner는 JDK1.2 이상 버젼에 포함되어있는 툴이다.)


1. 다음과 같이 keytool 커멘드를 이용하여 teststore 화일에 test 라는 별명으로 새로운 키를 만든다.

----------------------------------------------------------
prompt> keytool -genkey -keystore teststore -alias test

keystore 암호를 입력하십시오:  test12345
이름과 성을 입력하십시오.
  [Unknown]:  editor
조직 단위 이름을 입력하십시오.
  [Unknown]:  editor
조직 이름을 입력하십시오.
  [Unknown]:  editor
구/군/시 이름을 입력하십시오?
  [Unknown]:  editor
시/도 이름을 입력하십시오.
  [Unknown]:  editor
이 조직의 두 자리 국가 코드를 입력하십시오.
  [Unknown]:  editor
CN=editor, OU=editor, O=editor, L=editor, ST=editor, C=editor이(가) 맞습니까?
  [아니오]:  y

<test>에 대한 키 암호를 입력하십시오
        (keystore 암호와 같은 경우 RETURN을 누르십시오):  test
키 암호가 너무 짧습니다. 여섯 글자 이상이어야 합니다.
<test>에 대한 키 암호를 입력하십시오
        (keystore 암호와 같은 경우 RETURN을 누르십시오):  test12345
--------------------------------------------------------------------


2. 생성된 keystore 화일과 그 화일에 생성된 키를 이용하여 자체 signed 인증서를 생성한다

----------------------------------------------------------
prompt> keytool -selfcert -alias test -keystore teststore

keystore 암호를 입력하십시오: test12345
----------------------------------------------------------


3. keystore 화일 teststore에 저장된 키 정보를 보려면 다음과 같이 명령을 주고 암호를 입력한다.

------------------------------------------
prompt> keytool -list -keystore teststore
------------------------------------------


4. 최종적으로 만들어진 인증서를 이용하여 다음과 같이 jarsigner를 이용하여 jar 화일에 sign한다.
   암호를 물으면 teststore 생성시 사용된 암호를 입력한다.

------------------------------------------------------
prompt> jarsigner -keystore teststore editor.jar test
------------------------------------------------------


이렇게서 만들어진 signed-jar 화일인 editor.jar는 최종적으로 자바웹스타트를 통해서 배포할 수 있는 화일이다.  웹스타트를 통하여 배포되는 화일이 local 자원이나 network 자원을 이용하려면 모두 이렇게 signed-jar를 만들어야 한다.

이렇게 JAR화일을 준비하면 응용프로그램은 배포 준비가 완료된 것이다.  하지만 이렇게 응용 프로그램만 준비한다고 해서 모든 과정이 끝난 것은 아니다.  

우선 이 프로그램이 어떤 것이고 어떻게 배포될지를 기술하는 XML 문법으로 이루어진 jnlp 화일이 필요하고, jar와 jnlp을 적절이 설정된 웹서버에 올리는 과정이 필요한다.

이러한 내용은 다음 장에서 다루도록 한다.

V. JNLP 화일 및 웹서버 설정 
-----------------------------

JNLP(Java Network Launching Protocol) 화일은 자바 웹스타트에서 자동 배포될 모듈에대한
정보 및 어떻게 배포될 것인 가에 대한 정보를 기술해주는 화일로 웹서버에서는 우선 이
화일부터 호출 되고 이 화일에 기술된 대로 JAR 화일을 다운로드하여 프로그램이 실행되도록
되어 있다.

JNLP 화일은 기본적으로 XML 문법 체계를 가지고 있으며, 모든 테그에 대한 정보를 자세히 
보려면 SUN site에서 JNLP Spec v1.0을 참고하도록 한다.  여기서는 JNLP에대한 기본적인 사항을
예제 위주로 살펴보겠다.

다음은 SimpleEditor.jar를 배포할 수 있도록 만들어진 simple.jnlp 화일의 내용이다.


================================= 
file : simple.jnlp
================================= 

<?xml version="1.0" encoding="utf-8" ?>
<jnlp spec="1.0+" codebase="http://www.javanuri.com/jaws/apps" href="simple.jnlp">

  <information>
    <title>Simple Editor Demo</title>
    <vendor>JavaNuri</vendor>
    <description>Simple Editor Demo Program</description>
    <description kind="short"> Simple Editor</description>
    <icon href="images/editor.jpg" />
    <offline-allowed />
  </information>
  
  <security>
    <all-permissions />
  </security>

  <resources>
    <j2se version="1.4" />
    <jar href="editor.jar" />
  </resources>

  <application-desc main-class="SimpleEditor" />

</jnlp>


본 simple.jnlp 예제에서 첫라인은 본 문서가 XML이고 encoding이 utf8로 되어 있음을 
기술하는 것이고 다음부터 나오는 JNLP 주요 태그 내용은 다음과 같다. 

- jnlp tag : <jnlp spec="1.0+" codebase="http://www.javanuri.com/jaws/apps" href="simple.jnlp">
  본 내용이 jnlp에 관련된 내용임을 기술하며 문서의 끝에 </jnlp>로 닫힌다.

  . spec 속성은 jnlp 1.0 버젼 이상임을 정의한다.
  . codebase 속성은 본 문서의 모든 화일의 기본 URL을 정의한다.
  . href 는 본문서 화일 이름을 정의한다.

- information tag : <information> ... </information>
  각종 하위 태그로 본 프로그램에 관한 제목, 제작사, 설명, 아이콘 등을 기술하고 있으며, 
  이는 배포 및 실행될 때 사용자가 화면을 통해 볼 수 있는 아이콘 및 설명으로 사용된다.

- security tag : <security> ... </security>
  이 태그는 프로그램에 실행될때 주는 local 자원에 대한 권한을 기술한다.

- resource tag : <resource>... </resource>
  이 태그는 하위 태그를 이용하여 j2se 버젼 및 사용되는 jar 화일들을 기술하여
  실행환경에 대한 정보를 담고 있다.

- application-desc tag :   <application-desc main-class="SimpleEditor" />
  이 태그는 플로그램 실행시 필요한 사항을 기술하며 특히 main-class 는 반드시
  지정되어야할 속성으로 자바 프로그램의 main 메소드가 있는 클래스명을 써준다.



여러분이 여기까지해서 JAR 및 JNLP 화일을 만들었다면 이를 적절하게 배포해줄
웹서버 환경이 필요하다.  자바 웹스타트는 기본적으로 HTTP 프로토콜을 사용하며 클래스가
실려있는 JAR화일 및 이 내용을 기술하고 있는 JNLP화일은 결국 웹서버의 서비스 디렉토리에
복사되어야 한다.


웹서버는 다양한 종류가 있으며, 기본적인 환경설정은 해당 웹서버 제품의 메뉴얼에 
따라야할 것이다.  

본 강좌에서는 가장 많이 쓰이고 있는 Apache 웹서버를 예제로하여 환경을 설정할 것이다. 
다른 웹서버도 크게 차이는 없으리라 생각된다. 

따라서 www.apache.org 사이트를 방문하여 windows, linux, solaris 등 여러분의 환경에 맞는 
apache웹서버를 다운로드하여 메뉴얼이 지시하는데로 설치하도록 한다. 
본 강좌에서는 웹서버 설치에 관해서 다루지는 않겠다.


웹서버를 설치한 후에 가장 먼저 해주어야 할일은 jnlp 확장자 화일에 관한 mime type의
설정이다.  

mime type의 설정은 웹서버로 하여금 jnlp 확정자를 갖은 화일은 어떠한 컨테츠로 취급할 
것인지를 알려준다. 
아파치 웹서버의 경우는 설정 디렉토리에서 mime.types 화일에 다음과 같이 한 라인만 
추가해 주면 된다.

   application/x-java-jnlp-file JNLP


추가한 후에는 반드시 웹서버를 다시 시작해야 한다.

이렇게 웹서버 설정이 끝났다면 지금까지 만들었던 jar 화일과 jnlp 화일을 웹서버의 
document root 에 적절히 복사해놓는 것이다. 이것은 마치 웹서버에 html 화일을 복사해놓는
것과 마찬가지이다. jar 및 jnlp 화일과 함께 복사하여야 할 것은 simple.jnlp에서 
지정한 아이콘 화일인 images/editor.gif이다. (첨부 File 이용)

아래에 첨부된 file을 다운로드하여 images 디렉토리에 복사하기 바란다.

simple.jnlp 화일은 경우는 반드시 jnlp 테스의 codebase 속성에 기술되어 있는 주소를
반드시 여러분의 웹서버 설치 주소로 변경해야한다. 그렇지 않으면 다운로드시 오류가 발생할 것이다.

여기까지 하면 SimpleEditor를 자바 웹스타트를 이용하여 실행할 준비가 모두 끝난 것이다.
실제 실행 및 실행시 유의 사항등은 다음 장에서 다루도록 한다.

VI. 예제프로그램 웹스타트로 실행하기 
---------------------------------------

  웹스타트 응용프로그램 개발 과정을 다시한번 정리해보면 다음과 같다.

1. 실행될 응용프로그램을 AWT/Swing으로 개발한다.
2. 개발된 응용프로그램을 배포할 수 있도록 jar로 묶는다.
3. Local 자원을 사용할 수 있도록 jar에 sign을 하여 signed-jar를 만든다.
4. 배포 실행될 응용프로그램에 대한 내용을 jnlp 화일을 만들어 xml로 기술한다.
5. web 서버에 JNLP mime type을 설정한다.
6. web 서버의 적절한 디렉토리에 singed-jar, jnlp 화일 및 이미지 화일을 복사한다.

여기까지의 사항이 완료되었다면 일단 웹브라우져에서 웹스타트 응용프로그램을
실행할 수 있는 웹서버 환경이 갖추어진 것이다.

 실제 예제로 만들어진 editor.jar 와 simple.jnlp를 브라우져에서 실행하려면
웹서버를 실행하고 단순히 다음과 같이 simple.jnlp를 호출하는 URL을 치면 된다.

 http://www.javanuri.com/jaws/apps/simple.jnlp

  브라우져에 jre1.4가 정상적으로 설치되었으면 먼저 "Web Start Logo"화면이 뜨고
보안을 위해 jar에 sign된 내용이 나타나면서 승인 여부를 묻는 화면이 나온다.
여기에서 "예"를 선택하면 즉시 editor 프로그램이 실행될 것이다.
그리고 두번째로 웹에서 실행할 때는 바탕화면에 아이콘 생성 여부를 물을 것이다.
여기에서 "예"를 선택하면 바탕화면에 아이콘이 생성되면서 다음 부터는 웹브라우져를
통하지 않고 바탕에 있는 아이콘을 단순히 클릭함으로써 응용프로그램이 시작될 것이다.

  이제까지 만들어왔던 SimpleEditor 예제에 대한 관련 jar, jnlp, jpg 화일들은
example.zip에 묶어 첨부되어 있다. 이를 다운로드 받아 압축을 풀고 웹서버에 설치하고
실행시켜보기 바란다. 단 실행시 jnlp화일에 있는 codeBase 속성은 여러분의 웹서버 주소에
맞도록 수정해야 한다.

  서버 설정은 이제까지 설정한데로 하면 보통은 이상없이 환경이 설정된다. 하지만
클라이언트 즉 브라우져 환경은 사용자에 따라 웹스타트가 설정되어 있을 수도 있고, 아닐수
도 있다. 따라서 이러한 브라우져 환경을 통제하려면 html 및 javascript를 이용할 필요가
있다.
    
  사용자 브라우져를 체크해 웹스타트를 실행할 수 있는 방법은 여러가지가 있을 수 있지만
대체로 다음 세가지 방법이 있다.
    
1. 자바스크립트를 이용해 웹스타트 설치여부를 체크한 다음 설치돼지 않았을 경우
   설치하라는 메시지 링크를 주는 방법
   
2. 웹스타트 버젼1.2의 자동 설치 기능을 이용하는 방법
    
3. 간단한 JRE1.4를 이용한 Applet을 이용하는 방법
    

  첫번째 방법인 자바웹스타트 설치여부를 체크하는 방법은 우선 웹브라우져 종류를 파악해야 하는데,
이방법은 "Java Web Start Developers's Guide"에서 사용한 자바스크립트인 xbDetectBrowser()를 사용하여
할 수 있다. xbDetectBroser.js는 본 글에 첨부 하였다.
    
  다음 예제는 "Java Web Start Developers's Guide"에 나오는 예제를 응용하여 이해하기 쉽게 변경한
것으로서 스크립트를 실행시키면 Java Web Start 가 설치되었을 경우는 해당 프로그램을 실행할 수 있는
URL 링크가 나오고, 설치되어 있지 않을 경우는 Java Web Start를 설치하라는 메시지가 나오는 예제이다.

Simple1.html
=====================================================================================================
<HTML>
<HEAD><TITLE>Java Web Start Page</title>
<!----------------------------------------------------------------
  xbDetectBrowser() 함수를 이용하여 브라우져 환경에 관한 정보 생성
------------------------------------------------------------------>
<SCRIPT LANGUAGE="JavaScript" SRC="xbDetectBrowser.js"></SCRIPT>

<!----------------------------------------------------------------
  Web Start 설치 여부, 브라우져가 IE 인지 여부 설정 
------------------------------------------------------------------>
<SCRIPT LANGUAGE="JavaScript"> 

    var javawsInstalled = 0; 
    isIE = "false"; 

    if (navigator.mimeTypes && navigator.mimeTypes.length) { 
       x = navigator.mimeTypes['application/x-java-jnlp-file']; 
       if (x) javawsInstalled = 1; 
    } else { 
       isIE = "true"; 
    } 

</SCRIPT>

<!----------------------------------------------------------------
  브라우져가 IE일 경우 Web Start 설치 여부 결정하는 VBScript
------------------------------------------------------------------>

<SCRIPT LANGUAGE="VBScript"> 
    on error resume next 
    If isIE = "true" Then 
      If Not(IsObject(CreateObject("JavaWebStart.IsInstalled"))) Then 
            javawsInstalled = 0 
      Else 
            javawsInstalled = 1 
      End If 
    End If 
</SCRIPT>

<!----------------------------------------------------------------
 insertLink 함수 정의 :
   웹스타트가 설치되었을 경우는 응용 프로그램 실행 링크를 보여주고
   그렇지 않을 경우는 설치 필요 메시지 보여줌
  (설치 필요 메시지를 수정하여 download URL 링크로 만들 수 있음)
------------------------------------------------------------------>

<SCRIPT LANGUAGE="JavaScript"> 
    function insertLink(url, name) { 
    if (javawsInstalled || navigator.family == 'gecko') { 
          document.write("<a href=" + url + ">"  + name + "</a>"); 
       } else { 
          document.write("Java Web Start 설치가 필요합니다."); 
       } 
    } 
</SCRIPT>

<!----------------------------------------------------------------
  웹스타트 응용프로그램 실행 링크를 insertLink 함수를 통하여 만듬
------------------------------------------------------------------>

<SCRIPT LANGUAGE="Javascript"> 
    insertLink("http://www.javanuri.com/jaws/apps/simple.jnlp", "웹스타트 응용프로그램 시작"); 
</SCRIPT>

<BODY>    
</BODY>
</HTML>
    
=====================================================================================================
    
 두번째 방법인 자동 설치 기능을 이용하는 방법은 썬의 자바 사이트에서 제공하는 Web Start자동 설치
기능을 수행하는 ActiveX를 호출하는 것이다. Java Web Start만을 자동 설치하는 OBJECT 테그 및 URL은

<OBJECT CODEBASE="http://java.sun.com/products/javawebstart/autodl/jinstall_javaws-1_2-windows-i586.cab" 
CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" HEIGHT=0 WIDTH=0>
이며

자바 1.4 버전을 자동 설치할 수 있는 OBJECT 테그 및 URL은

<OBJECT CODEBASE="http://java.sun.com/products/plugin/autodl/jinstall-1_4_1-windows-i586.cab" 
CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" HEIGHT=0 WIDTH=0>

이다.

  이왕 자동 설치 기능을 사용하려면 web start만 설치하는 것 보다는 응용프로그램 환경이 더 좋은
자바 1.4버전을 설치하는 것이 좋다.

  다음 예제는 위의 예제와 같이 기존에 web start설치 여부를 체크하고 없으면 자동설치 되도록 자바 
스크립트 및 HTML을 작성 예를 보여주고 있다. ( Developer's Guide 참조 )

Simple2.html
=====================================================================================================

<!----------------------------------------------------------------
  브라우져가 Netscape일때 web start 설치 여부를 설정한다.
------------------------------------------------------------------>

<SCRIPT LANGUAGE="JavaScript">
var javawsInstalled = 0;
var javaws12Installed = 0;

isIE = "false";

if (navigator.mimeTypes && navigator.mimeTypes.length) {
  x = navigator.mimeTypes['application/x-java-jnlp-file'];
  if (x) {
     javawsInstalled = 1;
     javaws12Installed=1;
  }
} else { 
  isIE = "true";
}
</SCRIPT>

<!----------------------------------------------------------------
  브라우져가 IE일때 web start 설치 여부를 설정한다.
------------------------------------------------------------------>

<SCRIPT LANGUAGE="VBScript">
on error resume next
If isIE = "true" Then
  If Not(IsObject(CreateObject("JavaWebStart.isInstalled"))) Then
     javawsInstalled = 0
  Else
     javawsInstalled = 1
  End If
  If Not(IsObject(CreateObject("JavaWebStart.isInstalled.2"))) Then
     javaws12Installed = 0
  Else
     javaws12Installed = 1
  End If
End If
</SCRIPT>

<!----------------------------------------------------------------
  xbDetectBrowser.js를 이용하여 navigator.family를 설정한다.
------------------------------------------------------------------>
<SCRIPT LANGUAGE="JavaScript"
SRC="xbDetectBrowser.js">
</SCRIPT>

<!----------------------------------------------------------------
  gecko 방식이거나 이미 web start가 설치된 경우는 
  http://www.yyy.zzz/app.jnlp를 실행할 수있는 link를 보여준다.

  그렇지 않다면
  썬에서 제공하는 PluginBrowserCheck를 실행시킬수 있는 link를 제공한다.
  PluginBrowserCheck는 브라우져가 IE일 경우 "pass"파라미터에 있는
  자동 설치 URL인 http://www.yyy.zzz/download.html로 가고 아닐경우는
  플랫폼에 따라 설치 안내문이 나오도록 "fail"파라미터에 있는
  http://java.sun.com/cgi-bin/javawebstart-platform.sh로 간다.

------------------------------------------------------------------>

<SCRIPT LANGUAGE="JavaScript">
if (javawsInstalled ||  navigator.family == 'gecko') {
    document.write("<a href=http://www.yyy.zzz/app.jnlp>프로그램 실행</a>");
} else {

  document.write("<a href=http://dlres.java.sun.com/PluginBrowserCheck?");
  document.write("pass=http://www.yyy.zzz/download.html&");
  document.write("fail=http://java.sun.com/cgi-bin/javawebstart-platform.sh>");
  document.write("설치 및 응용프로그램 실행</a>");

}
</SCRIPT>

=====================================================================================================

download.html
=====================================================================================================
<!----------------------------------------------------------------
웹스타트 자동 설치 ActiveX프로그램을 호출하고 설치후에는 
http://www.yyy.zzz/app.jnlp로 링크되도록 한다.
만일 이미 설치돼었다면 곧바로 웹스타트가 실행된다.
------------------------------------------------------------------>

<HTML>
<BODY>
<OBJECT CODEBASE="http://java.sun.com/products/javawebstart/autodl/jinstall_javaws-1_2-windows-i586.cab" 
CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" HEIGHT=0 WIDTH=0>
<PARAM NAME="app" VALUE="http://www.yyy.zzz/app.jnlp">
<PARAM NAME="back" VALUE="true">
<!-- Alternate HTML for browsers which cannot instantiate the object -->
<A HREF="http://java.sun.com/cgi-bin/javawebstart-platform.sh?">
Download Java Web Start</A>
</OBJECT>
</BODY>
</HTML>
=====================================================================================================

이 방법은 결국 썬에서 제공하는 설치 ActiveX를 이용하는 것이고 그렇기 때문에 IE에서만 작동한다.
그리고 설치가 않될 경우는 플랫폼에 따라 설치 메뉴얼이 있는 페이지로 이동하게 된다. 이 방법을
잘 파악하려면 다음과 같이 썬에서 제공하는 각종 URL을 잘 이해하고 있어야 한다.

- http://dlres.java.sun.com/PluginBrowserCheck 
  pass와 fail파라미터가 있어 브라우져가 IE일 경우 pass에서 준 URL로 링크되고 아닐 경우는
  fail에서 준 URL로 링크된다.  파라미터가 없을 경우 플랫폼에 따라 JRE를 설치할 수 있는
  메뉴얼 페이지로 간다.

- http://java.sun.com/cgi-bin/javawebstart-platform.sh
  플렛폼에 따라 자바 웹스타트를 설치할 수 있는 메뉴얼 페이지로 이동한다.

- <OBJECT CODEBASE="http://java.sun.com/products/javawebstart/autodl/jinstall_javaws-1_2-windows-i586.cab" 
  CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" HEIGHT=0 WIDTH=0>
  자바 웹스타트를 자동 다운로드 및 설치하는 ActiveX를 구동한다. "app"파라미터는 설치후 자동 링크되는
  URL 값이다.


- <OBJECT CODEBASE="http://java.sun.com/products/plugin/autodl/jinstall-1_4_1-windows-i586.cab" 
  CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" HEIGHT=0 WIDTH=0>
  JRE1.4를 자동 다운로드 및 설치하는 ActiveX를 구동한다. 웹스타트는 자바 1.4버젼에 포함되어 있다.


  자동 설치 및 실행의 세번째 방법은 간단하게 시작 버튼을 가진 Applet을 만들고 Applet실행을 
JRE 1.4로 할 수 있도록 요구하는 것이다.  이렇게 하면 Applet이 실행되면서 JRE 설치 버젼을
체크해 자동으로 JRE1.4가 설치되며 자바웹스타트도 자동 설치된다.
 
  Applet을 조금더 응용하면 Applet에 실행버튼을 만들어 웹스타트 응용 프로그램을 바로 실행할 수 있도록
하는 것이다. 다음은 그러한 버튼을을 갖은 예제 Applet 및 실행 HTML이다.

StartApplet.java
=====================================================================================
import java.awt.*;
import java.awt.event.*;
import java.net.*;

/**
 * StartApplet
 *
 */
 
public class StartApplet extends java.applet.Applet implements ActionListener {

    // start button
    Button btStart        = new Button("응용프로그램 시작");
    
    // url
    String url;
    
    //--------------------------------
    // init
    //--------------------------------
    public void init() {
        
        btStart.addActionListener(this);
        add(btStart);
        
        url = getParameter("url");
        
    }
    
    //----------------------------------------
    // action performed
    //----------------------------------------
    public void actionPerformed(ActionEvent e) {
    
        try {
            getAppletContext().showDocument(new URL(url));
        }catch(Exception ex) {
            ex.printStackTrace();
        }
        
    }
    
}

==============================================================================

StartApplet.html
==============================================================================

<html>
<body>

<OBJECT    name="StartApplet"  classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"  WIDTH=150 HEIGHT=30
  codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_0-win.cab#Version=1,4,0,0">
  <PARAM NAME=CODE VALUE="StartApplet.class">
  <PARAM NAME="type" VALUE="application/x-java-applet;version=1.4">
  <PARAM NAME="url" VALUE="<a href=http://www.yyy.zzz/app.jnlp>">

  <COMMENT>
   <EMBED invokeURLs=false type="application/x-java-applet;jpi-version=1.4" CODE="StartApplet.class" WIDTH=150 HEIGHT=30
    pluginspage="http://java.sun.com/products/plugin/index.html#download">
    scriptable=false
     <NOEMBED invokeURLs=false></NOEMBED invokeURLs=false>
   </EMBED invokeURLs=false>
  </COMMENT>
</OBJECT>    

</body>
</html>

================================================================================

  StartApplet은 url 파라미터를 받아들이고 시작 버튼을 누르면 브라우져의 링크를 url 파라미터가
지정한데로 가도록 되어 있다. 따라서 실행하고 싶은 JNLP 파일을 url 파라미터에 주면 웹스타트가
자동 실행된다.

  StartApplet.html은 StartApplet 클레스를 자바 플러그인 형태로 실행 시키며, 자바 플러그인이
설치되어있지 않으면 자동 설치되도록 되어 있다. 위의 예제에서 <a href=http://www.yyy.zzz/app.jnlp> 부분만
원하는 URL로 바꾸어주면 자동 설치 및 웹스타트 시작페이지로 사용할 수 있을 것이다.

  이 방법은 간단한 Applet이 필요하기는 하지만 가장 간단하고 쉬운 방법이 아닌가 생각한다.

VII. Jar 자원 활용 및 JNLP API 이용
-----------------------------------

  자바웹스타트 응용 시스템을 만들다 보면 때로는 클레스와 함께 jar 화일에 묶여있는
이미지 화일이나 프로퍼티 화일, 자료 화일 등이 필요할 경우가 있다.  이러한 경우에는
java.lang.ClassLoader로 부터 해당 자원을 얻을 수 있다. 

다음은 jar화일에 묶여있는 이미지 화일로부터 Icon 객체를 생성해내는 예제이다.

ClassLoader loader = this.getClass().getClassLoader();
Icon myIcon = new ImageIcon(loader.getResource("imgs/myImg.gif"));

이 밖에도 java.lang.ClassLoader의 getResourceAsStream(String name) 메소드를 이용하면
다양한 자원을 InputStream을 통하여 얻을 수 있다.

  
  자바웹스타트 환경에서는 Java 2 SE API에서 제공하지 않는 추가적인 기능을 하는 API를
제공한다. 이것은 JNLP API라고 한다. JNLP API를 이용하여 개발할 경우는 jnlp.jar가
필요한데 이러한 파일은 JNLP Developer's Pack에 포함 되어 있다. 다음은 Developer's Pack을
다운로드 할 수 있는 URL이다.

http://java.sun.com/products/javawebstart/download-jnlp.html

  JNLP API가 추가적으로 제공하는 클레스는 javax.jnlp package로 묶여 있으며
BasicService, ClipboardService, DownloadService, FileOpenService, FileSaveService, 
PrintService, PersistenceService 등이 있는데 이들은 ServiceManager 클레스를 통하여
사용할 수 있다. 각각의 기능은 다음과 같다.

- javax.jnlp.BasicService

BasicService는 웹스타트의 환경적인 면이나 브라우져를 통제하기 위한 API를 제공하는데
자바 애플릿의 경우 AppletContext와 비슷한 역할을 한다. 다음 예제는 웹스타트 환경에서
웹브라우져로하여금 특정 URL로 가도록 하는 것이다.

import javax.jnlp.*;
.....

BasicService bs = (BasicService)ServiceManager.lookup("javax.jnlp.BasicService");
bs.showDocument(new URL("http://www.javanuri.com"));



- javax.jnlp.ClipboardService

ClipboardService는 시스템에서 사용하는 클립보드에서 복사 객체를 가져오거나 클립보드로
복사하는 서비스를 제공한다. 자바웹스타트는 이 기능을 사용할 때 보안을 위하여 경고창을
보여준다. 다음은 간단한 스트링을 클립보드에 복사하는 예제이다.

import javax.jnlp.*;
.............

ClipboardService cs = (ClipboardService)ServiceManager.lookup("javax.jnlp.ClipboardService");
StringSelection ss = new StringSelection("Hello Web Start");
cs.setContents(ss);


- javax.jnlp.DownloadService

DownloadService는 자신의 자원을 Cache에 저장, 삭제등 Cache를 통제할 수 있는 서비스 API를
제공하는 클레스이다. 다음은 myapp.jar를 Cache에서 확인하고 있으면 삭제한후 다시 Cache에
저장하는 예제이다.

import javax.jnlp.*;
...........

DownloadServicd ds = (DownloadService)ServiceManager.lookup("javax.jnlp.DownloadService");
URL url = new URL("http://www.javanuri.com/jws/myapp.jar");
boolean isCached = ds.isResourceCached(url, "1.0");
if(isCached) {
  ds.removeResource(url, "1.0");
}

DownloadServiceListener dsl = ds.getDefaultProgressWindow();
ds.loadResource(url, "1.0", dsl);


- javax.jnlp.FileOpenService

FileOpenService는 권한이 제약된 환경에서도 이를 사용자에게 알리고 화일을 열 수 있는
다이얼로그 윈도우를 열어주는 서비스이다.  다음 예제는 FileOpenService를 이용하여 화일을
여는 예제이다.

import javax.jnlp.*;
..............

FileOpenService fo = (FileOpenService)ServiceManager.lookup("javax.jnlp.FileOpenService");
FileContents fc = fo.openFileDialog(null, null);

- javax.jnlp.FileSaveService


FileSaveService는 권한이 제약된 환경에서도 local disk에 화일을 저장할 수 있는
기능을 제공하는 서비스 클레스이다. 이는 FileOpenService의 경우와 반대인 기능을 제공하는
클레스이다.  다음은 FileOpenService를 이용하여 화일을 연 후에 FileSaveService를
이용하여 화일을 저장하는 예제이다.

import javax.jnlp.*;
.....................

FileOpenService fo = (FileOpenService)ServiceManager.lookup("javax.jnlp.FileOpenService");
FileContents fc = fo.openFileDialog(null, null);
FileContents newfc = fss.saveFileDialog(null, null, fc.getInputStream(), "newfile.txt");

- javax.jnlp.PrintService

PrintService는 권한이 제약된 웹스타트 환경에서도 프린트를 가능하게 해주는 API 를 갖고 있는
서비스 클레스이다.  이 API를 이용하여 프린트를 요청하면 사용자에게 허가할 것인가를 묻는
다이얼로그가 나타난다. 다음은 PrintService를 이용한 프린트 요청 예제이다.

import javax.jnlp.*;
.....................

PrintService ps = (PrintService)ServiceManager.lookup("javax.jnlp.PrintService");

// default page format
PageFormat pf = ps.getDefaultPage();

// customizing page format
PageFormat npf = ps.showPageFormatDialog(pf);

// print
ps.print(new Doc());


// printable class
class Doc implements Printable {

 ....
 public int print(Graphics g, PageFormat fm, int idx) {
  ....
 }

}

}


- javax.jnlp.PersistenceService

PersistenceService는 브라우져의 쿠키와 마찬가지고 사용자의 클라이언트에 간단한 자료를 
저장할 때 사용된다. 저장되는 형태는 url형태로 자장된다.
다음은 간단한 url을 저장하고 내용을 읽어들이는 예제이다.


import javax.jnlp.*;
.....................

PersistenceService ps = (PersistenceService)ServiceManager.lookup("javax.jnlp.PersistenceService");

String addr = "www.javanuri.com/some.txt";
java.net.URL = new URL(addr);

// create
ps.create(url, 1024);
FileContents fc = ps.get(url);
OutputStream os = fc.getOutputStream(false);
os.write(...);

// read
fc = ps.get(url);
InputStream in = fc.getInputStream();

in.read(...);

.......


- javax.jnlp.FileContents

FileContents 는 FileOpenService, FileSaveService, PersistenceService와 같은 서비스에서 
input과 output을 처리할 수 있도록 만들어진 클레스이다. 일반적인 File 클레스와 비슷하게
생각하면 된다.  보안과 자료 저장 형태 등이 일반 File 클레스와는 다르다.

출처 : http://www.javanuri.co.kr, 유용근