spec

머리말

지난 4년 동안 Sun 및 주요 소비자용 장치 제조업체는 휴대 전화, 양방향 호출기, 개인 오거 나이저 같은 자원 제약형 소비자 장치용으로, 이식성이 우수하며 최소 풋프린트를 지니는 Java™ 응용 프로그램 개발 환경을 만들기 위해 협력해 왔습니다.

이 작업은 K Virtual Machine (KVM)이라는 풋프린트를 적게 지니는 새로운 Java 가상 머신 의 개발로 시작되었습니다. 그런 다음 다양한 소비자용 장치 간에 Java 라이브러리 및 관련 Java 언어와 가상 머신 기능을 표준화하기 위해 두 가지 Java Community Process (JCP)

표준화 노력, 즉 Connected Limited Device Configuration (CLDC)과 Mobile Information Device Profile (MIDP)을 수행했습니다. CLDC와 MIDP 표준은 Java™ 2 Platform, Micro Edition (J2ME™ )의 주요 부분입니다.

이 설명서 Connected Limited Device Configuration 규격은 J2ME Connected Limited Device Configuration (CLDC)의 1.1 버전을 정의합니다. 이 규격은 전 세계의 24개 회사로 구성된 Java Community Process 전문가 그룹 JSR-139가 만들었습니다.

J2ME 플랫폼의 컨피규레이션은 핵심 플랫폼 라이브러리를 비롯한 Java 프로그래밍 언어의 하위 집합, 컨피규레이션의 Java Virtual Machine 기능의 하위 집합, 보안 및 네트워킹 기능 등과 같이 다양한 소비자 제품을 지원하기 위한 모든 사항을 지정합니다.

Connected Limited Device Configuration은 하나 이상의 프로화일의 기본이 됩니다. J2ME 플랫폼의 프로화일은 특정 수직적 시장, 장치 범주 또는 산업을 위한 추가 API 및 기능 집합을 정의합니다. 컨피규레이션 및 프로화일은 J2ME™ Platform 규격 설명서에 보다 정확 하게 정의되어 있습니다.

이 규격의 사용 대상

이 설명서의 대상은 다음과 같습니다.

이 컨피규레이션을 정의하는 Java Community Process (JCP) 전문가 그룹 JSR-139
소형, 자원 제약형, 연결 장치용으로 Java 응용 프로그램을 작성하려는 응용 프로그 램 개발자 및 컨텐트 공급업체
CLDC 규격을 준수하는 소형 Java 사용 장치를 빌드하려는 장치 제조업체
CLDC 규격을 준수하는 구현을 빌드하려는 Java 플랫폼 공급업체

이 규격의 구성

이 규격의 내용은 다음과 같이 구성되어 있습니다.

1장‚ “소개 및 배경”은 CLDC 규격의 일부 배경 정보 및 컨텍스트를 제공하며 JSR-139 및 JSR-30 규격 작업에 참여한 회사 이름을 나열합니다. 또한 이 장에서는 CLDC 규격 버전 1.1 과 1.0의 주요 차이점을 요약합니다.

2장‚ “목표, 요구 사항 및 범위”는 이 규격의 목표, 요구 사항 및 범위를 정의합니다.

3장‚ “높은 수준의 구조 및 보안”은 CLDC의 높은 수준의 구조를 정의하고 해당 보안 기 능을 설명합니다.

4장‚ “Java 언어 규격 유지”는 CLDC 규격에서 정의한 표준 Java 프로그래밍 언어의 변형 을 설명합니다.

5장‚ “Java 가상 머신 규격 유지”는 CLDC 규격에서 정의한 표준 Java Virtual Machine의 변형을 설명합니다.

6장‚ “CLDC 라이브러리”는 CLDC 규격에서 지원하는 Java API를 정의합니다.

“부록”은 이 규격에 부속된 부록 번호에 대한 포인터입니다.

수정 사항 기록

표 1

날짜	버전	설명
2001년 10월 10일		CLDC NG (Next Generation) 규격에서 작업이 시작 되었습니다.
2001년 10월 22일	1.1 작업 드래프트 1	주석이 있는 첫 번째 “완전한” 작업 드래프트입니다.
2001년 11월 21일	1.1 작업 드래프트 2	전문가 그룹 구성원과 다른 검토자로부터의 피드백 을 기반으로 한, 두 번째 작업 드래프트입니다. 변경 사항을 추적하기 쉽도록 변경줄을 설정하였습니다.
2001년 12월 19일	1.1 작업 드래프트 3	세 번째 전문가 그룹 회의의 통합된 피드백입니다.
2002년 1월 17일	1.1 커뮤니티 검토	이 버전은 커뮤니티 검토를 위해 JCP에 제출되었습 니다. 변경줄이 제거되었습니다.
2002년 3월 11일	1.1 작업 드래프트 4	커뮤니티 검토와 네 번째 전문가 그룹 회의의 피드백 이 포함됩니다.
2002년 3월 20일	1.1 공개 검토	이 버전은 공개 검토를 위해 JCP에 제출되었습니다. 변경줄이 제거되었습니다. CLDC 1.0과 1.1의 차이점 을 업데이트했습니다.
2002년 5월 10일	1.1 공개 검토 - 내부 버전 1	공개 검토 중에 외부 및 내부 피드백을 받아 일부 라 이브러리 클래스와 javadocs를 개정했습니다.
2002년 5월 31일	1.1 공개 검토 - 내부 개정판 2	전문가 그룹의 결정에 따라 `Thread.interrupt()` 를 추가했습니다. 파악되지 않은 예외 및 오류와 관 련된 일부 텍스트를 추가했습니다. 기타 간단한 설명 몇 가지도 추가했습니다.
2002년 6월 7일	1.1 공개 검토 - 내부 개정판 3	`Date.toString()`의 ISO8601 호환 버전이 J2SE와 호환되지 않기 때문에 제거되었습니다. 부록 1의 버 그를 약간 수정했습니다.
2002년 7월 8일	1.1 공개 검토 - 내부 개정판 4	내부 피드백에 따라 라이브러리 문서가 약간 업데이 트되었습니다. 주 규격 문서는 변경하지 않았습니다.
2002년 7월 12일	1.1 공개 검토 - 공개 개정판 2	Motorola 및 내부 검토자의 최신 피드백을 통합했습 니다. 대부분의 변경 사항은 javadocs와만 관련되어 있습니다. `String.equalsIgnoreCase()` 메소드 를 추가했습니다.

표 1

날짜	버전	설명
2002년 11월 15일	1.1 제안된 최종 드래 프트	내부 검토자의 의견을 반영하여 약간 업데이트했습 니다. `Date.toString()`(J2SE 호환 버전)을 다시 추가했습니다.
2002년 12월 12일	1.1 제안된 최종 드래 프트	Nokia 및 기타 검토자의 피드백을 통합했습니다. `StackMap` 속성에 대한 중복되는 정의를 제거했습 니다.

주석

이 설명서에는 JSR-139 전문가 그룹의 의견 및 결정을 요약하기 위해 사용된 주석이 포함 되어 있습니다. 주석의 형식은 아래에 설명되어 있습니다.

주석 – 주석의 형태입니다. 이러한 주석은 실제 규격의 일부가 아닙니다. JSR-139 전문가 그룹의 의견과 결정을 요약하기 위해 사용되었습니다.

머리말

1장

소개 및 배경

이 설명서는 Java™ 2 Platform, Micro Edition (J2ME™)의 Connected, Limited Device Configuration (CLDC)을 지정합니다.

CLDC 규격의 주요 목표는 자원 제약형, 연결 장치용으로 이식성이 우수하며 최소 풋프린트 를 지니는 Java™ 응용 프로그램 개발 플랫폼을 표준화하는 것입니다.

휴대폰, 양방향 호출기, PDA (Personal Digital Assistant), 오거나이저, 가전 제품, 로우 엔드 TV 셋탑 박스 및 POS 단말기는 이 규격에서 지원할 수 있는 장치의 일부에 불과합니다.

이러한 J2ME 컨피규레이션 규격은 소형 연결 장치에 대한 Java 기술 구성 요소 및 라이브러 리의 최소 필수 보완을 정의합니다. Java 언어 및 가상 머신 기능, 핵심 라이브러리, 보안, 입 출력 및 네트워킹은 이 규격에서 다루는 주요 내용입니다.

CLDC는 하나 이상의 프로화일에 대해 기본으로 사용됩니다. J2ME 프로화일은 특정 수직 적 시장, 장치 범주 또는 산업의 기능인 추가 라이브러리를 정의합니다.

1.1 CLDC 전문가 그룹

JSR-139 전문가 그룹. 이 규격은 많은 산업 파트너로 구성된 Java Community Process 전문 가 그룹 JSR-139의 산물입니다. 다음 회사(알파벳순)는 JSR-139 전문가 그룹 작업의 정식 구성원입니다.

aJile Systems
Aplix Corporation
France Telecom
Fujitsu
Insignia Solutions
Liberate Technologies
Mitsubishi
Motorola ■ NEC
Nokia
NTT DoCoMo
OpenTV
Openwave Systems
Oracle
Panasonic
Research In Motion (RIM)
Samsung
Siemens
Sony
Sony Ericsson Mobile Communications
Sun Microsystems
Symbian
Vulcan Machines ■ Zucotto Wireless 그리고 11개 회사와 개인이 JSR-139 전문가 그룹 작업에 참관자로서 참여하였습니다. 참관 자는 드래프트 규격 버전, 중간 문서 및 회의 일정을 모두 받았지만 실제 전문가 그룹 회의 에는 참석하지 않았습니다.

JSR-30 전문가 그룹. 이 규격은 2000년 5월에 완료된 CLDC 규격 버전 1.0에서 파생되었습니 다. JSR-30 전문가 그룹은 다음 회사(알파벳순)의 대표로 구성되었습니다.

America Online
Bull
Ericsson
Fujitsu
Matsushita
Mitsubishi
Motorola
Nokia
NTT DoCoMo
Oracle
Palm Computing
Research In Motion (RIM)
Samsung
Sharp
Siemens
Sony
Sun Microsystems
Symbian

1.2 CLDC 규격 버전 1.1과 1.0의 주요 차이점

CLDC 1.1 (JSR-139) 전문가 그룹 구성원은 CLDC 규격 버전 1.0에 대체적으로 만족했기 때 문에 새 규격에서 많은 변화를 원하지 않았습니다. 그러므로 CLDC 규격 버전 1.1은 CLDC 규격 버전 1.0과 완전히 역호환되게 만든 추가 릴리스입니다. 부동 소수점 지원 같은 중요한 새 기능이 몇 가지 추가되었습니다.

아래의 목록에서는 CLDC 규격 버전 1.1 (JSR-139)과 1.0 (JSR-30)의 주요 차이점을 요약합 니다.

부동 소수점 지원이 추가되었습니다.
모든 부동 소수점 바이트 코드는 CLDC 1.1에 의해 지원됩니다.
클래스 Float과 Double이 추가되었습니다.
부동 소수점 값을 처리하기 위해 다양한 메소드가 다른 라이브러리 클래스에 추가되 었습니다.
약한 참조(Weak reference) 지원(J2SE 약한 참조 클래스의 일부분)이 추가되었습니다.
클래스 Calendar, Date 및 TimeZone은 좀 더 J2SE와 호환이 되도록 다시 설계되었습니 다.
오류 처리 요구 사항이 명확해졌으며 새 오류 클래스인 NoClassDefFoundError가 추가되었습니다.
CLDC 1.1에서 Thread 객체는 J2SE의 스레드와 유사한 이름을 갖습니다. Thread.getName() 메소드가 소개되었으며 Thread 클래스는 J2SE로부터 상속된 몇 개의 새 구성자를 갖습니다.
다음 필드 및 메소드 추가 같은, 여러 가지 사소한 라이브러리 변경 및 버그 수정이 포함 되었습니다.
Boolean.TRUE and Boolean.FALSE
Date.toString()
Random.nextInt(int n)
String.intern()
String.equalsIgnoreCase()
Thread.interrupt()
부동 소수점 기능이 추가되었기 때문에 최소 필수 메모리가 160KB에서 192KB로 늘어 났습니다.
규격 텍스트 내용이 많아졌기 때문에 이전의 하위 절은 제거되었습니다.
보다 자세한 검증자 규격(“CLDC 바이트 코드 유형 검사기 규격”)은 부록으로 제공됩니다. 1장 소개 및 배경

2장

목표, 요구 사항 및 범위

2.1 목표

목표 요약. CLDC 규격의 목표는 자원 제약형, 연결 장치를 위해 이식성이 우수하며 최소 풋프린트를 지니는 Java™ 응용 프로그램 개발 플랫폼을 표준화하는 것입니다.

CLDC 규격의 대상 장치는 다음과 같은 일반적 특성을 갖습니다.

Java 플랫폼에서 사용 가능한 전체 예상 메모리가 최소 192KB임(2.2.1절 “하드웨어 요구 사항“ 참조)
16비트 또는 32비트 프로세서
낮은 전력 소비, 배터리 전원으로도 작동함
일부 종류의 네트워크에 대한 연결성, 무선도 가능, 간헐적 연결 및 제한된 대역폭 휴대폰, 양방향 호출기, PDA (Personal Digital Assistant), 오거나이저, 가전 제품, 로우 엔드 TV 셋탑 박스 및 POS 단말기는 이 규격에서 지원할 수 있는 장치의 일부에 불과합니다.

구체적으로 말해서 CLDC 규격은 다음 특성과 목표를 갖는 Java 응용 프로그램 개발 플랫폼 을 정의합니다.

풋프린트를 작게 차지합니다. 휴대폰 같은 소비자 장치는 대량(매년 십만, 백만 또는 천만 개 정도) 제조되어 저렴한 가격으로, 때로는 보조금까지 지급되어 소비자에게 판매됩니 다. 이윤 폭을 유지하기 위해 장치 제조업체는 장치의 단가를 가능한 한 낮게 유지하려고 합니다. 소비자가 추가 기능에 대해 비용을 지불하지 않는 한 추가 전원이나 동적 메모리 는 추가되지 않습니다. 장치 제조업체의 요구를 충족시키기 위해 CLDC 규격은 다양한 소비자 장치에 대한 최소 Java 플랫폼 기능 및 API만 포함하는 “최소 공통” 표준을 정의 합니다.
시스템 프로그래밍이 아닌 응용 프로그램 프로그래밍에만 초점을 맞춥니다. CLDC는 시스템 프로그래밍 환경이라기보다 응용 프로그램 개발 플랫폼입니다. 따라서 Java 플랫 폼 기능과 API가 이 규격에 포함되었습니다. 먼저 CLDC 규격에는 응용 프로그램 개발자에게 충분한 프로그래밍 능력을 제공하는 높은 수준의 라이브러리만 포함합니다. 두 번째로 일반성 및 이식성의 중요성을 강조 합니다. CLDC 규격은 특정 장치 범주, 수직적 시장 또는 시스템 기능에 해당하는 API는 제공하지 않습니다.
응용 프로그램의 동적 다운로드를 가능하게 하고 타사 응용 프로그램 개발을 장려합니다. 과거와 달리 휴대폰과 호출기 같은 소형 장치는 대개 공장에서 하드 코드된 기능 집합과 함께 제공되므로 장치 제조업체는 컨텐트 공급자와 타사 개발자로부터 대화식 컨텐트의 동적 다운로드를 지원하는 확장 가능 장치를 빌드할 수 있는 솔루션을 찾아가고 있습니 다. 인터넷이 가능한 휴대폰, 통신기 및 호출기가 최근 소개되면서 이러한 추이는 이미 진행 중입니다. CLDC 규격의 기본 목표 중 하나는 Java 응용 프로그램을 다양한 종류의 네트워크를 통해 소형 클라이언트 장치로 동적으로 안전하게 다운로드하기에 적합한 환경을 정의하는 것입니다.

동적으로 배달된 Java 응용 프로그램에 초점을 맞춘다는 것은 이 규격이 하드웨어 제조업체 와 관련 시스템 프로그래머뿐만 아니라 타사 응용 프로그램 개발자도 위한 것이라는 의미입 니다. 사실 소형 Java 사용 장치가 많아지면서 이러한 장치의 응용 프로그램 개발자 대다수 는 장치 제조업체가 아닌 타사 개발자가 된다고 가정합니다.

2.2 요구 사항

2.2.1 하드웨어 요구 사항

CLDC는 다양한 소형 장치에서의 실행을 목적으로 합니다. 이러한 장치의 기본 하드웨어 기능은 상당히 다양하므로 CLDC 규격에서는 메모리 요구 사항 이외의 특정 하드웨어 요구 사항에 대해 설명하지 않습니다. 메모리 제한 때문에라도 CLDC 규격은 최소 제한만 정의 하므로 실제 CLDC 대상 장치는 최소 제한보다 상당히 더 큰 메모리를 가지게 됩니다.

CLDC 규격은 다음 내용을 가정합니다.

최소 16KB의 비휘발성1 메모리를 가상 머신과 CLDC 라이브러리에서 사용할 수 있습 니다.
최소 32KB 휘발성2 메모리는 가상 머신 런타임(예: 객체 힙)에 사용할 수 있습니다.
비휘발성이란 용어는 사용자가 장치를 “켰다” “껏다”하는 동안에도 메모리의 내용이 그대로 유지됨을 나타 내는 데 사용됩니다. CLDC 규격의 용도에 맞게 비휘발성 메모리는 대개 읽기 모드에서 액세스되며 메모리에 기록하기 위해서 특수 설정 작업이 필요하다고 가정합니다. 비휘발성 메모리의 예에는 ROM, Flash 및 배터리 내장 SDRAM이 포함됩니다. CLDC 규격은 장치에 있어야 할 메모리 기술은 정의하지 않으며 전원 소모 시나 리오에서 이러한 메모리의 동작에 대해서도 정의하지 않습니다.
휘발성이란 용어는 사용자가 장치를 “켰다” “껏다”하는 동안 메모리의 내용이 유지되지 않음을 나타내는 데 사용됩니다. CLDC 규격의 용도에 맞게 특수 설치 없이 휘발성 메모리를 직접 읽고 쓸 수 있다고 가정합니다. 가장 일반적인 유형(type)의 휘발성 메모리는 DRAM입니다. 전체 예상 메모리에서 휘발성 메모리 대 비휘발성 메모리의 비율은 대상 장치 및 장치의 Java 플랫폼 역할에 따라 상당히 달라질 수 있습니다. 장치에 빌드된 시스템 응용 프로그램 을 실행하기 위해 Java 플랫폼이 엄격하게 사용된 경우 응용 프로그램을 미리 링크하고 로 드할 수 있으므로 제한된 양의 휘발성 메모리만 필요합니다. 동적으로 다운로드된 컨텐트를 실행하기 위해 Java 플랫폼이 사용된 경우 장치에는 더 많은 휘발성 메모리가 필요합니다.

2.2.2 소프트웨어 요구 사항

하드웨어 기능과 마찬가지로 CLDC 대상 장치의 시스템 소프트웨어도 상당히 다양합니다. 예를 들어, 어떤 장치는 여러 개의 동시 운영 체제 프로세스 및 계층 파일 시스템을 지원하는 다양한 기능의 운영 체제를 기자고 있을 수 있습니다. 다른 대부분의 장치에는 파일 시스템 이란 개념이 없는 상당히 제한된 시스템 소프트웨어가 있습니다. 이러한 다양성으로 인해 CLDC는 기본 시스템 소프트웨어에 대해 최소로 가정합니다.

일반적으로 CLDC 규격은 기본 하드웨어를 관리하기 위해 최소 호스트 운영 체제나 커널을 사용할 수 있다고 가정합니다. 이 호스트 운영 체제는 Java 가상 머신을 실행하기 위해 예약 가능한 엔티티를 최소한 한 개 이상 제공해야 합니다. 호스트 운영 체제는 별도의 주소 공간 이나 프로세스를 지원할 필요가 없으며 실시간 스케줄링이나 대기 시간 동작을 보장할 필요 가 없습니다.

2.2.3 J2ME 요구 사항

CLDC는 Java 2 Micro Edition (J2ME)컨피규레이션으로 정의되어 있습니다. 이는 CLDC 규격에 대해 다음과 같은 중요한 의미를 갖습니다.

J2ME 컨피규레이션은 Java 기술의 최소 보완이나 “최소 공통 사항”만 정의합니다. 컨피 규레이션에 포함된 모든 기능은 일반적으로 다양한 장치에 적용 가능해야 하므로 Connected Limited Device Configuration의 범위는 실제 대상 장치에서 제한되며, 불완전할 수 있다는 의미입니다. 특정 수직적 시장, 장치 범주 또는 산업의 추가 기능은 J2ME 프 로화일 규격에 정의되어 있어야 합니다.
컨피규레이션 목표는 다양한 종류의 자원 제약형 장치 사이의 이식성 및 상호 운용성을 보장하는 것이므로 컨피규레이션은 선택적 기능을 정의하지 않을 것입니다. 이러한 제 한은 컨피규레이션에 포함되어야 할 내용과 포함되지 말아야 할 내용에 대해 중요한 영 향을 미칩니다. 도메인 특정 기능은 CLDC가 아닌 J2ME 프로화일 또는 선택적 패키지 에 정의되어야 합니다.
J2ME 컨피규레이션 사용은 일반적으로 Java 2 Platform, Standard Edition (J2SE)에 의해 제공된 Java 기술 기능 및 라이브러리의 일부를 정의합니다. 따라서 CLDC 규격은 지원 되는 모든 기능에 대한 전체 설명을 제공하기보다는 전체 JLS (Java Language Specification) 및 JVMS (Java Virtual Machine Specification)와 비교하여 변경된 내용이

나 차이점만 정의합니다. CLDC 규격에 명시적으로 지정된 내용이 없으면 CLDC 규격은 JLS와 JVMS를 준수합니다.

2장 목표, 요구 사항 및 범위

J2ME 컨피규레이션 및 프로화일 정의 규칙과 지침에 대한 자세한 내용은 J2ME™ 플랫폼 규격을 참조하십시오.

CLDC의 선택적 기능 부재가 다양한 구현 최적화를 제한하는 것은 아닙니다. 예를 들어, 구현의 관찰 가능한 사용자 수준 의미(semantics)가 CLDC 규격에서 정의한 내용과 같다면 구현 수준에서 대체 바이트 코드 실행 기술(예: Just-In-Time 컴파일)이나 클래스 표현 기술

(Class representation techniques)을 사용할 수 있습니다.

2.3 범위

JSR-30과 JSR-139 전문가 그룹의 결정에 따라 CLDC 규격은 다음 영역에 대해 언급합니다.

Java 언어 및 가상 머신 기능
핵심 Java 라이브러리(java.lang.*, java.util.*)
입출력(java.io.*)
보안
네트워킹
국제화 이 CLDC 규격은 다음 영역은 언급하지 않습니다.
응용 프로그램 설치 및 라이프 사이클 관리
사용자 인터페이스 기능
이벤트 처리
높은 수준의 응용 프로그램 모델(사용자와 응용 프로그램 간 상호 작용) 이러한 기능은 CLDC의 맨 위에 구현된 프로화일에서 언급할 수 있습니다. CLDC 전문가 그룹은 의도적으로 CLDC에서 주소를 지정하는 영역의 수를 적게 갖기로 결정 하였습니다. 엄격한 메모리 제한을 초과하지 않거나 특정 장치 범주를 제외하려면 CLDC의 범위를 제한하는 것이 좋다고 판단했습니다. 추가 기능 영역은 J2ME 프로화일 규격에 더 잘 언급되어 있습니다.

이 규격의 나머지는 다음과 같이 구성됩니다. 일반 CLDC 환경의 높은 수준 구조에 대한 설명 부터 시작합니다. 그런 다음 CLDC를 준수하는 가상 머신의 Java 언어와 가상 머신 기능을 전체 Java™ 언어 규격과 Java Virtual Machine 규격을 따르는 전형적인 Java 환경과 비교합 니다. 마지막으로 이 규격은 CLDC에 포함된 Java 라이브러리를 설명합니다.

3장

높은 수준의 구조 및 보안

이 장에서는 일반적인 CLDC 환경의 높은 수준 구조를 설명합니다. 이러한 설명은 뒤에 나오는 장의 좀 더 자세한 규격에 대한 시작 지점 역할을 합니다.

3.1 CLDC 높은 수준의 구조

일반적인 J2ME 장치의 높은 수준의 구조는 그림 1에 설명되어 있습니다. CLDC 구현(“컨피 규레이션”)의 중심은 Java Virtual Machine (JVM)으로 이 규격의 뒷 부분에서 정의할 특정 차 이점과 상관없이 Java™ Virtual Machine 규격 및 Java™ 언어 규격과 호환됩니다. 가상 머신 은 CLDC 범위를 벗어난 호스트 운영 체제의 맨 위에서 일반적으로 실행됩니다.

Java 라이브러리는 가상 머신의 맨 위에 있습니다. 이러한 라이브러리 중 일부는 그림 1에 표시 된 대로 Connected Limited Device Configuration 자체에 정의되어 있습니다. 그리고 J2ME 프 로화일은 컨피규레이션 계층의 맨 위에 있는 추가 라이브러리 및 기능을 정의합니다.

그림 1 높은 수준의 구조

3.2 Java 응용 프로그램의 개념

CLDC (Connected Limited Device Configuration)는 특정 장치 범주를 대상으로 하지 않습니 다. 많은 대상 장치에는 고급 그래픽 사용자 인터페이스가 있습니다. 일부 대상 장치는 텍스 트, 문자 기반 사용자 인터페이스에서 작동하지만 일부 다른 대상 장치는 시각적 사용자 인터 페이스가 없거나 전혀 표시하지 않습니다. 이렇게 다양한 장치에 대응하기 위해 CLDC 규격 에 정의된 응용 프로그램 모델은 아주 간단합니다.

CLDC 규격에서 Java 응용 프로그램이란 용어는 응용 프로그램의 시작 지점을 식별하는 단일의 고유한 메소드 main이 포함된 Java 클래스 파일 모음을 참조하는 데 사용됩니다.

Java™ Virtual Machine 규격, §5.2 및 §2.17.1에 지정된 대로 메소드 main은 아래와 같이 public, static 및 void로 선언되어야 합니다.

public static void main(String[] args)

CLDC 규격을 준수하는 가상 머신은 메소드 main을 호출하여 Java 응용 프로그램을 실행 합니다.

MIDP 같은 J2ME 프로화일은 CLDC 규격에 정의된 기본 응용 프로그램 모델을 확장하거나 대체하는(override) 응용 프로그램 모델을 정의할 수 있습니다.

3.3 응용 프로그램 관리

많은 소형, 자원 제약형 장치에는 동적으로 다운로드된 정보를 장치에 저장하기 위한 파일 시스템이나 기타 표준 기법이 없습니다. 그러므로 CLDC 구현 시 외부 소스로부터 다운로드 한 Java 응용 프로그램을 장치에 영구적으로 저장할 것을 요구하지 않습니다. 대신 구현 시 응용 프로그램만 로드하고 실행 후 바로 삭제합니다.

하지만 많은 해당 CLDC 장치에서 응용 프로그램을 반복해서 다운로드할 필요 없이 같은 Java 응용 프로그램을 여러 번 실행하는 것이 좋습니다. 이는 무선 네트워크를 통해 응용 프 로그램을 다운로드 받음으로써 사용자가 높은 다운로드 비용을 부담해야 하는 경우 특히 중 요합니다. CLDC를 구현하는 장치에 응용 프로그램을 영구적으로 저장할 수 있는 경우 장치 에 저장된 응용 프로그램을 관리할 기능이 구현 중인 장치에 있다고 가정합니다. 높은 수준 의 응용 프로그램 관리는 다음과 같은 기능을 포함합니다.

Java 응용 프로그램 다운로드 및 설치
장치에 저장된 기존 Java 응용 프로그램 검사
Java 응용 프로그램 선택 및 시작 ■ 기존 Java 응용 프로그램 삭제(해당하는 경우) 장치에서 사용할 수 있는 자원에 따라 CLDC 시스템은 여러 Java 응용 프로그램이 동시에 실행되게 할 수 있거나 한 번에 한 Java 응용 프로그램만 실행되도록 시스템을 제한할 수 있 습니다. 기본 호스트 운영 체제의 멀티캐스팅 기능(존재할 경우)을 활용하거나 동시에 Java 응용 프로그램을 실행하는 여러 논리 가상 머신을 인스턴스화하여 여러 Java 응용 프로그램 실행이 지원되는지 여부를 확인하는 작업은 특정 CLDC 구현에 따라 달라집니다.

해당 CLDC 장치 간 중요한 변형 및 기능 차이로 인해 응용 프로그램 관리의 세부 사항은 장치 및 구현에 따라 많이 달라집니다. 응용 프로그램 관리에 관한 실제 세부 사항은 CLDC 규격에서 다루지 않습니다.

3.4 보안

기업 및 개인은 컴퓨터 시스템과 네트워크에 저장된 중요한 정보에 점점 더 의존하므로 보 안 문제는 더욱 중요해지며 모바일 컴퓨팅과 무선 네트워크 컨텍스트에서 더 중요합니다. 고유한 보안 구조로 인해 Java 개발 플랫폼은 특히 보안이 중요한 환경에 특히 적합합니다.

Java 2 Platform, Standard Edition (J2SE)에서 제공하는 보안 모델은 Java 플랫폼에 빌드된 강력하고 유연성 있는 보안 프레임워크를 개발자에게 제공합니다. 개발자는 최종 사용자 에게 모두 투명하게 표시되도록 세부적인 보안 정책을 만들고 개별 응용 프로그램의 독립 사용 권한을 명백하게 할 수 있습니다.

3장 높은 수준의 구조 및 보안

안타깝게도 Java 2 Platform, Standard Edition에서 보안을 담당하는 전체 코드는 CLDC에서 사용 가능한 전체 예상 메모리를 훨씬 초과합니다. 따라서 CLDC 보안 모델을 정의할 때는 단순화해야 합니다. CLDC의 보안 모델은 다음 세 가지 수준으로 정의됩니다.

낮은 수준의 보안. 가상 머신 보안으로도 알려져 있는 낮은 수준의 보안은 가상 머신에서 실행 중인 응용 프로그램이 Java 프로그래밍 언어의 의미를 따르도록 하며 부적합하거나 악의적으로 인코딩된 클래스 파일이 대상 장치와 충돌하거나 손상시킬 수 없도록 합니다.
응용 프로그램 수준의 보안. 응용 프로그램 수준의 보안은 장치에서 실행 중인 Java 응용 프로그램이 장치 및 Java 응용 프로그램 환경에서 액세스를 허용한 라이브러리, 시스템 자 원 및 기타 구성 요소에만 액세스할 수 있음을 의미합니다.
종단간 보안. 종단간 보안은 특정 장치에서 시작된 트랜잭션이 해당 트랜잭션(예: 인터넷 에 위치한 서버)에 대한 서비스를 제공하는 장치에서 엔티티 이르는 전체 경로를 따라 보 호되도록 보증하는 모델을 참조합니다. 그러기 위해 암호화나 다른 방법이 필요할 수도 있 습니다. 종단간 보안은 CLDC 규격의 범위를 벗어나며 종단간 소프트웨어 개발을 위한 기 능을 제공하는 해당 J2ME 프로화일에 의해 정의된다고 가정합니다. 아래에서는 이러한 수준 각각에 대해 좀 더 자세하게 살펴봅니다.

3.4.1 낮은 수준(가상 머신) 보안

모바일 정보 장치에서 Java 가상 머신의 주요 요구 사항은 낮은 수준 가상 머신 보안입니다. 가상 머신에서 실행 중인 응용 프로그램이 가상 머신이 실행 중인 장치를 손상시키나 이 장 치에 충돌해서는 안 됩니다. 표준 Java 가상 머신 구현 시 이러한 제약 조건은 클래스 파일에 저장된 바이트 코드 및 기타 항목은 유효하지 않은 명령을 포함할 수 없고 유효하지 않은 순서로 실행될 수 없으며 Java 객체 메모리(객체 힙)를 벗어난 잘못된 메모리 위치나 메모리 영역에 대한 참조를 포함할 수 없게 해주는 클래스 파일 검증자(Class file verifier)에 의해 보 증됩니다. 일반적으로 클래스 파일 검증자(Class file verifier)의 역할은 가상 머신에 로드된 클래스 파일이 Java™ Virtual Machine 규격에서 허용하지 않은 방식으로 실행되지 않게 하 는 것입니다.

5.2절 “클래스 파일 확인“에 좀 더 자세하게 설명하겠지만 CLDC 규격에서는 CLDC를 준수 하는 Java 가상 머신이 잘못된 클래스 파일을 거부할 것을 요구합니다. 5.2절 “클래스 파일 확인“에 제시된 클래스 파일 확인 기술을 통해 이 작업을 보증할 수 있습니다.

3.4.2 응용 프로그램 수준 보안

클래스 파일 확인은 Java 플랫폼의 보안을 보증하는 데 있어 중요한 역할을 하지만 클래스 파일 검증자(Class file verifier)가 제공하는 보안은 그 자체로는 불충분합니다. 클래스 파일 검증자(Class file verifier)는 주어진 프로그램이 유효한 Java 응용 프로그램이라는 것만 보증 할 수 있습니다. 검증자에 의해 확인되지 않은 몇 가지 다른 잠재적 보안 위협이 여전히 있을 수 있습니다. 예를 들어, 파일 시스템, 프린터, 적외선 장치, 원시 라이브러리, 네트워크 같은 외부 자원에 대한 액세스는 클래스 파일 검증자(Class file verifier)의 범위를 벗어납니다. 응 용 프로그램 수준 보안을 사용하면 Java 응용 프로그램은 Java 응용 프로그램 환경에서 액세 스를 허용한 라이브러리, 시스템 자원 및 기타 구성 요소에만 액세스할 수 있다는 의미입니 다. 응용 프로그램 수준 보안의 세부 사항은 아래에서 설명합니다.

3.4.2.1 샌드 박스 모델

CLDC에서 응용 프로그램 수준 보안은 폐쇄된 “샌드 박스”의 은유를 사용하여 수행됩니다. 컨피규레이션, 프로화일 및 장치에서 지원하는 다른 클래스에서 정의했던 라이브러리만 응용 프로그램이 액세스할 수 있는 폐쇄된 환경에서 응용 프로그램이 실행되어야 합니다. Java 응용 프로그램은 이 샌드 박스를 벗어날 수 없거나 미리 정의된 기능의 부분이 아닌 라 이브러리나 자원에 액세스할 수 없습니다. 샌드 박스는 악의적이거나 오류를 일으킬 수 있 는 응용 프로그램에 대해서는 시스템 자원에 대한 액세스 권한을 얻지 못하게 합니다. 좀 더 구체적으로 CLDC 샌드 박스 모델에는 다음 내용이 필요합니다.

클래스 파일은 유효한 Java 응용 프로그램이 되도록 제대로 확인되고 보증되어야 합니 다. 클래스 파일 확인에 대한 자세한 내용은 5.2절 “클래스 파일 확인“을 참조하십시오.
Java 응용 프로그램의 다운로드, 설치 및 관리는 응용 프로그램 프로그래머가 가상 머신 의 표준 클래스 로딩 기법을 수정하거나 생략할 수 없게 만드는 방식으로 이루어집니다.
폐쇄된, 미리 정의된 Java API 집합은 CLDC, 프로화일(예: MIDP) 및 제조업체별 클래 스에서 정의한 대로 응용 프로그램 프로그래머가 사용할 수 있습니다.
가상 머신에 액세스 가능한 원시 함수의 집합이 닫혔다는 것은 응용 프로그램 프로그래 머가 원시 함수가 포함된 새 라이브러리를 다운로드할 수 없거나 CLDC, 프로화일 또는 특정 제조업체 클래스에서 제공한 Java 라이브러리의 일부가 아닌 원시 함수에 액세스 할 수 없음을 의미합니다. J2ME 프로화일은 추가 보안 솔루션을 제공합니다. 또한 프로화일에서는 응용 프로그램 프로 그래머가 사용할 수 있는 추가 API를 정의합니다.

3.4.2.2 시스템 클래스 보호

CLDC의 주요 요구 사항은 Java 응용 프로그램을 가상 머신으로 동적 다운로드하는 것을 지원하는 기능입니다. 다운로드한 응용 프로그램이 패키지 java.*, javax.microedition.* 또는 기타 프로화일별 패키지 또는 제조업체별 패키지에서 제 공한 일련의 시스템 클래스를 무시하거나 확장할 수 있는 경우 Java 가상 머신에서 응용 프 로그램 수준 보안 허점이 노출될 수 있습니다. CLDC 구현은 응용 프로그램 프로그래머가 클래스를 이렇게 보호된 시스템 패키지에서 무시하거나 수정하거나 추가할 수 없게 합니다.

보안상의 이유로 응용 프로그램 프로그래머는 클래스 파일 조회 순서를 어떤 식으로든 조작 할 수 없어야 합니다. 클래스 파일 조회 순서에 대한 자세한 내용은 5.3.3절 “클래스 파일 조 회 순서“를 참조하십시오.

3장 높은 수준의 구조 및 보안

3.4.2.3 동적 클래스 로딩에 대한 추가 제한

Java 응용 프로그램의 동적 로딩은 CLDC의 주요 특징입니다. 하지만 CLDC 규격은 CLDC 를 준수하는 가상 머신의 클래스 로딩 기법이 구현 종속이 되게 다음 한 가지 중요한 제한과 함께 정의합니다. 기본적으로 Java 응용 프로그램은 고유 Java Archive (JAR) 파일에서만 응 용 프로그램 클래스를 로드할 수 있습니다. 이러한 제한은 특정 장치의 Java 응용 프로그램 이 서로 방해하거나 서로 데이터를 훔칠 수 없게 합니다. 그리고 이러한 제한은 장치 제조업 체나 서비스 공급자가 시스템 응용 프로그램의 일부로 제공한 Java 클래스의 개인 구성 요 소나 보호된 구성 요소에 대한 액세스 권한을 타사 응용 프로그램이 얻을 수 없게 만듭니다. JAR 파일 및 응용 프로그램 표시 형식에 대한 자세한 내용은 5.3절 “클래스 파일 형식 및 클 래스 로딩“을 참조하십시오.

3.4.3 종단간 보안

CLDC 규격을 준수하는 장치는 일반적으로 무선 네트워크나 지불 단말기 네트워크 같은 종 단간 솔루션의 일부입니다. 이러한 네트워크는 서버 시스템과 클라이언트 장치 사이에서 데 이터와 코드를 안전하게 배달할 수 있도록 많은 고급 보안 솔루션(예: 암호화)이 많이 필요합 니다. 전세계의 네트워크 인프라가 다양하다는 가정 하에 CLDC 전문가 그룹은 단일의 종단 간 보안 기법을 요구하지 않기로 결정하였습니다. 그러므로 모든 종단간 보안 솔루션은 구현 종속되며 CLDC 규격의 범위를 벗어난다고 가정합니다.

4장

Java 언어 규격 유지

CLDC를 준수하는 가상 머신의 일반 목표는 CLDC 대상 장치의 엄격한 메모리 제한 내에서 가능한 만큼 Java™ 언어 규격과 호환되는 것입니다. 이 장에서는 CLDC를 준수하는 가상 머신과 Java 2 Standard Edition (J2SE)의 Java Virtual Machine 사이의 차이점을 요약합니다. 여기에서 제시한 차이점을 제외하면 CLDC를 준수하는 가상 머신은 Java Language

Specification (Java Series), Second Edition by James Gosling, Bill Joy, Guy L. Steele, Gilad Bracha, Addison-Wesley, 2000, ISBN 0-201-31008-2와 호환됩니다.

주 – 이 규격의 나머지 부분에서 Java™ 언어 규격은 JLS로 언급됩니다. Java™ 언어 규격 내의 절은 § 기호를 사용하여 언급됩니다. 예를 들면 (JLS §4.2.4)입니다.

4.1 클래스 인스턴스 finalization 지원 안함

CLDC 라이브러리에는 Object.finalize() 메소드가 포함되어 있지 않습니다. 그러므로 CLDC를 준수하는 가상 머신은 클래스 인스턴스의 finalization (JLS §12.6)을 지원하지 않습 니다. Connected Limited Device Configuration과 일치하도록 빌드된 어떠한 응용 프로그 램도 finalization이 사용 가능하지 않더라도 무방합니다.

4.2 예외 및 오류 처리 제한

CLDC를 준수하는 가상 머신은 비동기 예외(JLS §11.3.2)를 지원하지 않는다는 것을 제외 하면 JLS 11장에 정의된 예외 처리를 일반적으로 지원합니다.

이와 반대로, CLDC 라이브러리에 포함된 일련의 오류 클래스는 제한되므로 CLDC의 오류 처리 기능은 훨씬 더 제한됩니다. 이 이유는 다음 두 가지입니다.

임베디드 시스템의 경우 오류 상태에서의 복구는 대개 장치에 상당히 의존적입니다. 응용 프로그램 프로그래머가 장치별 오류 처리 기법과 규칙을 관리할 여력이 없습니다.
JLS §11.5에서 지정한 대로 클래스 java.lang.Error 및 그 서브 클래스는 프로그램이 정상적으로 복구될 수 없는 예외입니다. Java™ 언어 규격을 완전히 따르는 오류 처리 기능 의 구현은 비용이 많이 들며, 존재를 위임하고 모든 오류 클래스를 처리하면 가상 머신 구현 에 오버헤드가 생깁니다. CLDC를 준수하는 가상 머신은 6.2절 “Java 2 Standard Edition에서 파생된 클래스“에 정의 되어 있는 일련의 Error 클래스를 지원합니다. 다른 오류가 발생하면 구현은 다음과 같이 작동합니다.
구현에 따라 다른 방식으로 가상 머신이 중단됩니다.
가상 머신은 Java™ 언어 규격에 따라 발생될 Error 클래스의 가장 가까운 CLDC 지원 수퍼 클래스인 Error를 발생시킵니다. CLDC를 준수하는 가상 머신이 Java™ 언어 규격의 일부이지만 CLDC 규격에서 필요하지 않은 추가 오류 검사를 구현하는 경우 Java™ 언어 규격에 의해 정의된 Error 클래스의 가 장 가까운 CDLD 지원 수퍼클래스를 구현 시 발생시킵니다.

5장

Java 가상 머신 규격 유지

CLDC를 준수하는 가상 머신의 일반적인 목표는 CLDC 대상 장치의 엄격한 메모리 제한 내에서 가능한 한 Java™ Virtual Machine 규격과 호환되는 것입니다. 이 장에서는 CLDC를

준수하는 가상 머신과 Java 2 Standard Edition (J2SE)의 Java 가상 머신 사이의 차이점을

요약합니다. 여기에서 제시한 차이점을 제외하면 CLDC를 준수하는 가상 머신은 Java™

Virtual Machine Specification (Java Series), Second Edition by Tim Lindholm and Frank Yellin

(Addison-Wesley, 1999), ISBN 0-201-43294-3에 지정된 대로 Java 가상 머신과 호환됩니다.

주 – 이 규격의 나머지 부분에서 Java™ Virtual Machine 규격은 JVMS로 언급됩니다. Java™ Virtual Machine 규격 내의 절은 § 기호를 사용하여 언급됩니다. 예를 들면 (JVMS §2.4.3)입 니다.

5.1 가상 머신에서 제거된 기능

CLDC에 포함된 Java 라이브러리는 실제로 Java 2 Standard Edition의 라이브러리보다 훨씬 제한적이며, 완전한 J2SE 보안 모델이 없는 경우 보안 문제를 일으키는 기능 등의 이유로 CLDC를 준수하는 가상 머신에서 많은 기능이 제거되었습니다. 제거된 기능에는 다음 내용 이 포함됩니다.

사용자 정의된 클래스 로더(JVMS §5.3.2)
스레드 그룹 및 데몬 스레드(JVMS §2.19, §8.12)
클래스 인스턴스의 finalization (JVMS §2.17.7)
비동기 예외(JVMS §2.16.1) 또한 CLDC를 준수하는 가상 머신은 전체 J2SE 가상 머신보다 훨씬 더 제한된 오류 클래스 집합을 갖습니다.

CLDC용으로 작성된 응용 프로그램은 위의 기능 중 어떤 것도 의존하지 않습니다. 이 목록의 기능 각각은 아래에서 좀 더 자세하게 설명합니다.

5.1.1 사용자 정의된 클래스 로더

CLDC를 준수하는 가상 머신은 사용자 정의된 Java 수준 클래스 로더(JVMS §5.3, §2.17.2)를 지원하지 않습니다. CLDC를 준수하는 가상 머신은 대체하거나 바꾸거나 재구성할 수 없는 기본 제공 “부트스트랩” 클래스 로더를 가지게 됩니다. 사용자 정의된 클래스 로더의 제거 는 3.4.2.1절 “샌드 박스 모델“에 제시된 보안 제한의 일부입니다.

5.1.2 스레드 그룹 및 데몬 스레드

CLDC를 준수하는 가상 머신은 다중 스레드를 구현하지만 스레드 그룹이나 데몬 스레드 (JVMS §2.19, §8.12)에 대한 지원은 하지 않습니다. 스레드 시작 같은 스레드 작업은 개별 스 레드 객체에만 적용될 수 있습니다. 응용 프로그램 프로그래머가 스레드 그룹에 대해 스레 드 작업을 수행하려는 경우 스레드 객체를 저장하기 위해 명시 모음 객체가 응용 프로그램 수준에서 사용되어야 합니다.

5.1.3 클래스 인스턴스 finalization

CLDC 라이브러리에는 메소드 Object.finalize()가 포함되지 않습니다. 그러므로

CLDC를 준수하는 가상 머신은 클래스 인스턴스 finalization을 지원하지 않습니다(JVMS §2.17.7). CLDC를 준수하는 가상 머신의 맨 위에서 실행되는 응용 프로그램은 finalization 기능 사용을 요구하지 않습니다.

5.1.4 오류 및 비동기 예외

이전에 4.2절 “예외 및 오류 처리 제한“에서 설명했던 대로 CLDC를 준수하는 가상 머신의 오류 처리 기능은 제한됩니다.

CLDC를 준수하는 가상 머신은 6.2절 “Java 2 Standard Edition에서 파생된 클래스“에 정의 되어 있는 Error 클래스 집합을 지원합니다. 다른 문제가 발생하면 구현은 다음과 같이 작동 합니다.

구현 종속 방식에서 가상 머신이 중지됩니다.
가상 머신은 Java™ Virtual Machine 규격에 따라 발생될 Error 클래스의 가장 가까운 CLDC 지원 수퍼 클래스인 Error를 발생시킵니다. CLDC를 준수하는 가상 머신이 Java™ Virtual Machine 규격의 일부이지만 CLDC 규격에서 요구하지 않는 추가 오류 검사를 구현하는 경우 Java™ Virtual Machine 규격에 의해 정의된 Error 클래스의 가장 가까운 CLDC 지원 수퍼 클래스를 발생시킵니다.

CLDC를 준수하는 가상 머신은 Java™ Virtual Machine 규격에 의해 정의된 예외 처리를 일 반적으로 지원합니다. 하지만 CLDC를 준수하는 가상 머신은 비동기 예외(JVMS §2.16.1)를 지원하지 않습니다.

5.2 클래스 파일 확인

Java 2 Standard Edition의 Java 가상 머신과 마찬가지로 CLDC를 준수하는 가상 머신은 잘 못된 클래스 파일을 거부할 수 있어야 합니다. 이는 CLDC구현이 클래스 파일 확인을 지원 해야 한다는 의미입니다.

CLDC의 클래스 파일 확인은 다음 두 가지 방법으로 수행할 수 있습니다1 .

Java™ Virtual Machine 규격 (JVMS §4.9)에 정의된 표준 클래스 파일 확인 방법을 사용합 니다.
이 규격에 정의된 다른 좀 더 효율적인 확인 방법을 사용합니다. 이 방법은 아래의 부록 1 에서 설명합니다.

5.2.1 장치 분리 사전 확인(Off-device preverification) 및 스택 맵을 사용하여 런타임 확인

Java™ Virtual Machine 규격(JVMS §4.9)에 정의된 종래의 J2SE 클래스 파일 검증자는 소형, 자원 제약형 장치가 아닙니다. 종래의 검증자는 최소 50KB 이진 코드 공간과 일반적으로 최소 30-100KB의 동적 RAM을 런타임에 사용합니다. 또한 종래의 검증자에서는 복잡한 반복적 데이터 흐름 알고리즘을 수행하는 데 필요한 CPU 전원이 많이 필요할 수 있습니다.

이 세부절에 설명된 확인 방법은 기존 J2SE 검증자보다 자원 제약형 장치에서 훨씬 더 규모가 작고 효율적입니다. Sun KVM에서 새 검증자의 구현 시 일반 클래스 파일에 대해 약 10KB 의 Intel x86 이진 코드와 100바이트 미만의 동적 RAM이 런타임에 필요합니다. 검증자는 비용이 많이 드는 반복적 데이터 흐름 알고리즘을 사용하지 않고 바이트 코드에 대한 선형 스캔만 수행합니다. 새 클래스 파일 검증자는 그림 2에서 설명한 두 단계에서 작동합니다.

중요: 사용된 클래스 파일 확인 솔루션에 상관없이 클래스 파일은 미리 확인되어야 하며 StackMap 속성을 가져 야 합니다. 자세한 내용은 5.3.2절 “Java 응용 프로그램 및 자원의 공개 표현“을 참조하십시오.

먼저 클래스 파일은 런타임 확인 속도를 개선하기 위해 특정 바이트 코드를 제거하고 추가 StackMap 속성을 사용하여 클래스 파일을 증식하려면 사전 검증자 도구를 통해 실행되어야 합니다. 사전 확인 단계는 응용 프로그램을 작성하여 컴파일하기 위해 응용 프로그램 개발자가 사용하는 개발 워크스테이션에서 일반적으로 수행됩니다.
런타임 시 가상 머신의 런타임 검증자 구성 요소는 실제 클래스 파일 확인을 효율적으로 수행하기 위해 사전 검증자가 생성한 추가 StackMap 속성을 사용합니다. 클래스 파일의 바이트 코드 실행은 클래스 파일이 런타임 검증자를 성공적으로 통과했을 때 만 시작할 수 있습니다.

그림 2 CLDC의 두 단계 클래스 파일 확인

런타임 클래스 파일 확인은 유형(type)의 안전을 보장합니다. 예를 들어 런타임 검증자를 통 과한 클래스는 Java 가상 머신의 유형(type) 시스템을 위반하거나 메모리를 손상시킬 수 없습 니다. 코드 서명(Code signing)을 기준으로 하는 방법과 달리 이러한 보증은 인증되거나 신 뢰할 수 있는 확인 속성에 의존하지 않습니다. 누락되거나 잘못된 또는 손상된 확인 속성이 있으면 런타임 검증자에 의해 해당 클래스가 거부됩니다.

새 검증자는 특수 StackMap 속성을 포함하기 위해 클래스 파일에서 메소드를 요구합니다. 사전 검증자 도구는 이러한 속성을 일반 클래스 파일에 삽입합니다. 런타임 시 확인 작업이 수행될 수 있는 추가 StackMap 속성이 있는 경우 변환된 클래스 파일은 계속 유효한 Java 클래스 파일입니다. 이러한 속성은 Java 2 Standard Edition에 사용된 종래의 클래스 파일

검증자에 의해 자동으로 무시되므로 이 솔루션은 Java 2 Standard Edition의 Java 가상 머신 과 완전히 호환됩니다. 별도의 속성이 포함된 사전 처리된 클래스 파일은 원래 수정되지 않 은 클래스 파일보다 약 5-15% 더 큽니다.

또한 새 검증자는 클래스 파일의 바이트 코드에 있는 모든 서브루틴이 인라인될 것을 요구 합니다. Java 클래스 파일에서 서브루틴은 바이트 코드 jsr, jsr_w, ret 또는 wide ret를 포함하는 특수 바이트 코드 시퀀스입니다. 인라인 프로세스는 클래스 파일의 모든 메소드로 부터 모든 jsr, jsr_w, ret 및 wide ret 바이트 코드를 제거하고 이러한 명령을 의미상 동 등한 바이트 코드로 바꿉니다. 인라인 프로세스는 런타임 확인을 상당히 쉽고 빠르게 만듭 니다.

5.2.1.1 확인 과정

2단계 확인 과정에 대한 좀 더 자세한 설명은 아래에 나와 있습니다. 자세한 내용은 부록 1을 참조하십시오.

1단계: 사전 확인(장치 분리) 새 검증자와 함께 제공되는 사전 확인 도구는 다음 두 가지 작업을 수행합니다.

모든 서브루틴을 인라인하고 모든 jsr (JVMS p. 304, jsr_w (JVMS p. 305), ret (JVMS p. 352) 및 wide ret (JVMS p. 360) 바이트 코드를 클래스 파일에서 제거합니다. 이러한 명령이 포함된 각 메소드는 jsr, jsr_w, ret 및 wide ret 바이트 코드를 포함하지 않는 의미상으로 동등한 바이트 코드로 바뀝니다.
런타임 확인을 수행할 수 있도록 StackMap 속성을 클래스 파일에 추가합니다. StackMap 속성의 형식과 의미는 부록 1에 정의되어 있습니다. 또한 사전 확인 도구는 런타임 유형(type) 계층이 사전 확인 중에 제시된 유형(type) 계층과 동일하다는 가정 하에 JVMS에 의해 정의된 유효한 Java 클래스나 인터페이스를 통과한 경우 결과 코드가 장치 내 확인을 통과할 것임을 보장하기 위해 다른 비의미 코드 변환을 수행할 수 있습니다. 사전 확인 도구가 Java 클래스나 인터페이스를 통과하는 경우 사전 확인 도구는 장치 내 확인을 통과할 수 있는 클래스나 인터페이스를 생성하지 않습니다.

2단계: 장치내 확인 장치내 확인 알고리즘은 다음 단계로 구성됩니다.

먼저 검증자는 모든 지역 변수 유형(type)과 주어진 메소드의 피연산자 스택 항목을 저장 하기에 충분한 메모리를 할당합니다. 메모리 크기는 최대 지역 변수 개수 및 Code 속성 에 지정된 최대 스택 깊이에 의해 결정됩니다. 이 메모리 영역은 검증자가 바이트 코드를 통해 선형 통과할 때 파생된 유형(type)을 저장하기 위해 사용되며 검증자가 할당하는 유일한 메모리 조각입니다.
두 번째로 검증자는 인스턴스 메소드, 인자 유형(type) 및 한 개의 빈 피연산자 스택에 대해 파생된 유형(type)이 이 포인터의 유형(type)이 되게 초기화합니다.
세 번째로 검증자는 각 명령을 거쳐 선형으로 반복됩니다. 각 명령에 대해 다음 내용이 발생합니다.
이전 명령이 무조건 이동(예: goto), 반환(예: ireturn), athrow, tableswitch, lookupswitch이거나 현재 명령이 예외 처리기의 시작 바이트 코드 오프셋에 있는 경우 이전 명령으로부터의 직접 제어 흐름은 없습니다. 검증자는 현재 파생된 유형 (type)을 무시하고 현재 명령에 대해 기록된 스택 맵 항목에 따라 파생된 유형(type)을 설정합니다. 현재 명령에 스택 맵 항목이 없는 경우 검증자는 오류를 보고합니다.
이전 명령이 무조건 이동(예: goto), 반환(예: ireturn), athrow, tableswitch, lookupswitch가 아닌 경우 이전 명령으로부터의 직접 제어 흐름이 있습니다. 검증 자는 현재 명령에 대해 기록된 스택 맵 항목이 있는지 검사하여 있으면 검증자는 파생 된 유형(type)을 기록된 스택 맵 항목과 일치시키려고 시도합니다. 기록된 유형(type) 이 파생된 유형(type)과 같거나 좀 더 일반적인 유형(type)인 경우 파생된 유형(type)은 기록된 유형(type)으로 설정됩니다. 그렇지 않은 경우 검증자는 오류를 보고합니다.
현재 명령이 오류 처리기(try 블록)의 범위 안에 있으면 파생된 유형(type)은 예외 처 리기의 시작 바이트 코드 오프셋에 해당하는 스택 맵 항목과 비교하여 일치됩니다. 예 외 처리기의 시작 바이트 코드 오프셋에 해당하는 스택 맵 항목이 없는 경우 검증자는 오류를 보고합니다.
그런 다음 검증자는 파생된 유형(type)을 명령에서 기대하는 내용과 일치시키려고 합 니다. 예를 들어, iadd 명령은 맨 위에 있는 두 개의 피연산자 스택 항목이 정수이길 기대합니다. 그런 다음 파생된 유형(type)은 명령의 내용에 따라 수정됩니다. 예를 들 어 iadd 명령은 피연산자 스택에서 두 개의 정수를 떼어내어 정수 결과를 피연산자 스택에 넣습니다.
마지막으로 검증자는 현재 명령을 직접 따르지 않는 파생된 유형(type)을 후속 명령에 대해 기록된 스택 맵 항목과 일치시키려고 합니다.
마지막으로 검증자는 메소드의 마지막 명령이 무조건 이동(예: goto), 반환(예: ireturn), athrow, tableswitch 또는 lookupswitch인지 확인하여 그렇지 않은 경우 확인 오류를 보고합니다. 제어 흐름은 메소드의 끝으로 떨어집니다.

위에서 설명한 단계 이외에 장치내 검증자는 추가 검사를 수행해야 합니다. 검증자는 새로 할당된 객체와 구성자가 호출했던 객체를 구분해야 합니다. 주어진 바이트 코드 오프셋에서 new 명령에 의해 할당된 객체에서 구성자가 정확히 한 번 호출되었는지, 새로 할당된 객체 에서 적법한 작업만 구성자를 호출하려고 하는지 그리고 지역 변수나 역방향 분기가 일어날 때 피연산자 스택에 새로 할당된 객체가 없는지 확인해야 합니다.

5.2.1.2 스택 맵 속성 정의

새 런타임 검증자는 Java 클래스 파일이 특수 속성을 포함할 것을 요구합니다. 이러한 속성은 지역 변수 유형(type)과 피연산자 스택 항목, 즉 인터프리터 스택에 상주하는 모든 것을 설명 하기 때문에 이 속성은 “스택 맵”으로 알려져 있습니다.

각 StackMap 속성은 여러 항목으로 구성되며 각 항목은 주어진 바이트 코드 오프셋에서 지역 변수 유형(type)과 피연산자 스택 항목을 기록합니다.

StackMap 속성은 JVMS §4.7.3에 의해 정의된 Code 속성의 하위 속성입니다. Code 속성 및 어떻게 스택 맵 속성이 Code 속성의 일부로 적합한지에 대한 자세한 내용은 Java™

Virtual Machine Specification (Java Series), Second Edition by Tim Lindholm and Frank Yellin (Addison-Wesley, 1999)의 120페이지를 참조하십시오.

StackMap 속성의 형식 정의에 대해서는 부록 1을 참조하십시오.

5.3 클래스 파일 형식 및 클래스 로딩

Connected Limited Device Configuration의 필수 요구 사항은 Java 응용 프로그램 및 타사

컨텐트를 동적으로 다운로드하는 것을 지원하는 기능입니다. Java 플랫폼의 동적 클래스 로딩 기법은 이러한 기능에서 중요한 역할을 합니다. 이 절에서는 CLDC를 준수하는 가상 머신에 필요한 응용 프로그램 표현 형식 및 클래스 로딩 예를 설명합니다.

5.3.1 지원되는 파일 형식

CLDC 구현은 5.3.2절 “Java 응용 프로그램 및 자원의 공개 표현“에 정의된 사전 확인 변경 과 함께 표준 Java 클래스 파일(JVMS 4장에 정의)을 읽을 수 있어야 합니다. 그리고 CLDC 구현은 압축된 Java Archive (JAR) 파일을 지원해야 합니다. JAR 형식에 대한 자세한 내용은 http://java.sun.com/products/jdk/1.3/docs/guide/jar을 참조하십시오.

네트워크 대역폭 유지는 낮은 대역폭의 무선 네트워크에서 매우 중요합니다. 압축된 JAR 형 식은 심볼릭 정보가 손실되거나 기존 Java 시스템과의 호환성 문제없이 일반 클래스 파일을 통해 30-50% 압축을 제공합니다.

CLDC 구현은 Java 2 Platform Standard Edition, JDK 버전 1.1, 1.2, 1.3 및 1.4에 의해 지원 되는 모든 형식의 Java 클래스 파일을 읽을 수 있어야 합니다.

주 – 다양한 JDK 버전에서 사용한 클래스 파일 형식 번호는 다음과 같습니다1 .

45.*(대개 45.3) 버전 번호는 JDK 1.1 클래스 파일을 식별합니다.
46.* 버전 번호는 JDK 1.2 클래스 파일을 식별합니다.
47.* 버전 번호는 JDK 1.3 클래스 파일을 식별합니다.
48.* 버전 번호는 JDK 1.4 클래스 파일을 식별합니다. CLDC를 준수하는 가상 머신은 위에 나열된 모든 형식의 Java 클래스 파일을 읽을 수 있어야 합니다. 하지만 가상 머신은 CLDC 구현시 필요하지 않은 특정 클래스 파일 속성은 무시할 수 있습니다. 좀 더 구체적으로 다음 속성은 CLDC 구현 시 무시할 수 있습니다.

실제로는 내용이 약간 더 복잡합니다. JDK1.4 이전 릴리스에서 javac 컴파일러는 기본적으로 이전 VM과 호환 이 가능한 45.3 클래스 파일을 생성합니다. JDK 1.4에서 javac은 기본적으로 46.0 (JDK1.2) 클래스 파일을 생성 합니다. 하지만 JDK 1.4 javac에 대해서는 “-target” 옵션을 사용하여 다른 클래스 파일 형식을 생성하도록 지시할 수 있습니다. 예를 들어 “javac -target 1.1”은 45.3 클래스 파일을 생성합니다.

Synthetic 속성(JVMS §4.7.6)
SourceFile 속성(JVMS §4.7.7)
LineNumberTable 속성(JVMS §4.7.8)
LocalVariableTable 속성(JVMS §4.7.9) ■ Deprecated 속성(JVMS §4.7.10) 기록상의 이유로(JVMS p. 127), CLDC를 준수하는 가상 머신은 InnerClasses 속성(JVMS §4.7.5)이 잘 구성되었는지 검사할 필요가 없습니다.

5.3.2 Java 응용 프로그램 및 자원의 공개 표현

Java 응용 프로그램이 저장되어 있는 시스템이 일반에게 열려 있고 액세스할 수 있는 전송 계층 및 프로토콜이 공개형 표준인 경우 “공개적으로 표현“되거나 “공개적으로 분산“된다 고 간주합니다. 반대로 특정 장치는 공급업체(예: 무선 네트워크 운영자)가 모든 통신을 제 어하는 폐쇄된 네트워크 환경의 일부가 될 수 있습니다. 이러한 경우 응용 프로그램이 들어 와서 폐쇄된 네트워크 시스템을 통해 분산되면 더 이상 공개적으로 표현되지 않습니다.

CLDC 장치용 Java 응용 프로그램이 공개적으로 표현될 때마다 압축된 JAR 파일 표현 형식 이 사용되어야 합니다. JAR 파일에는 이 규격의 5.2.1절 “장치 분리 사전 확인(Off-device preverification) 및 스택 맵을 사용하여 런타임 확인“에서 설명한 대로 사전 확인된 Java 클래스 파일이 포함되어야 합니다.

Sun CLDC 참조 구현에는 클래스 파일에 이러한 수정을 하는 사전 확인 도구가 포함됩니다. 앞에서 설명한 대로, 사전 확인 도구에 의해 생성된 StackMap 속성은 JVMS §4.9에서 설명 한 종래의 J2SE 클래스 파일 검증자에 의해 자동으로 무시됩니다. 즉, 수정된 클래스 파일 형 식은 J2SE나 J2EE 같은 더 큰 Java 환경과 완전히 호환됩니다.

일반적으로 CLDC를 준수하는 가상 머신이 Java™ Virtual Machine 규격 (JVMS §4.9)에 정

의되어 있는 종래의 확인 방법을 사용하여 클래스 파일 확인을 구현하는 경우 가상 머신은

StackMap 속성을 무시할 수 있습니다. 또한 이러한 구현은 jsr, jsr_w, ret 및 wide ret 바이트 코드를 지원할 수 있습니다.

또한 JAR 파일에는 Class.getResourceAsStream(String name) 메소드를 호출하여 가상 머신에 로드할 수 있는 응용 프로그램별 자원 파일이 포함될 수 있습니다.

5.3.3 클래스 파일 조회 순서

Java™ 언어 규격과 Java™ Virtual Machine 규격은 새 클래스 파일이 가상 머신에 로드되었 을 때 클래스 파일을 검색할 순서를 지정하지 않습니다. 구현 수준에서 일반 Java 가상 머신 구현은 조회 순서를 정의하기 위해 특수 환경 변수 classpath를 활용합니다.

이 CLDC 규격은 클래스 파일 조회 순서가 구현 종속되며 다음 단락에 설명된 제한이 따른 다고 가정합니다. 조회 전략은 일반적으로 응용 프로그램 관리 구현(3.3절 “응용 프로그램 관리“ 참조)의 일부로 정의됩니다. CLDC를 준수하는 가상 머신은 classpath의 개념을 지원할 필요가 없지만 구현 수준에서 정의될 수 있습니다.

다음은 클래스 파일 조회 순서에 적용된 두 가지 제한을 보여줍니다. 이러한 두 가지 제한은 모두 보안상의 이유로 중요합니다.

3.4.2.2절 “시스템 클래스 보호“에서 설명한 것처럼 CLDC를 준수하는 가상 머신은 응용 프로그램 프로그래머가 새 시스템 클래스(CLDC에 속하는 클래스, 지원되는 프로화일 또 는 제조업체별 클래스)를 무시하거나 수정 또는 추가할 수 없게 보장해야 합니다.
응용 프로그램 프래그래머는 클래스 파일 조회 순서를 어떤 식으로든 조작할 수 없어야 합니다.

5.3.4 구현 최적화 및 대체 응용 프로그램 표현 형식

사전 로딩/사전 연결(“ROMizing”). CLDC를 준수하는 가상 머신은 일부 클래스의 사전 로 드/사전 연결을 선택할 수 있습니다. 이러한 기술을 약식으로 ROMizing이라고 합니다1. 일 반적으로 소형 가상 머신 구현 시 모든 시스템 클래스(예: 특정 컨피규레이션이나 프로화일 에 속하는 클래스)를 사전 로드할 것인지와 응용 프로그램 로딩을 동적으로 수행할 것인지 선택합니다.

사전 로드를 위한 실제 기법은 구현 종속되며 CLDC 규격의 범위를 벗어납니다. 모든 경우, 런타임 효과와 사전 로드/사전 연결의 의미는 해당 시점에 실제 클래스가 로드된 것과 같아 야 합니다. 응용 프로그램 시작시 속도를 높일 수 있다는 것 이외에 사전 로드가 갖는 가시적 인 효과는 없습니다. 특히 사용자 가시적 효과를 갖는 클래스 초기화는 시스템에 사전 로드 된 경우가 아니라면 클래스가 처음으로 로드되었을 때 수행되어야 합니다.

다른 구현 최적화. Java 클래스 파일은 대역폭 제한 환경에서 네트워크 전송에 대해서는 최 적화되지 않습니다. 각 Java 클래스 파일은 고유 상수 풀(기호 테이블), 메소드, 필드 및 예외 테이블, 바이트 코드, 예외 처리기 및 기타 다른 정보를 포함하는 독립 단위입니다. 클래스 파일의 자체 포함된 특성은 Java 기술의 장점 중 하나이며, 같은 위치에 반드시 상주할 필요 가 없는 여러 조각으로 응용 프로그램이 구성되게 하며 런타임에 응용 프로그램을 동적으로 확장할 수 있게 합니다. 하지만 이러한 융통성에는 대가가 따릅니다. Java 응용 프로그램이 봉인된 단위로 처리되는 경우 특히 전체 심볼릭 정보를 고려하지 않는다면 여러 상수 풀과 다른 구조에서 중복을 제거하여 많은 공간을 절약할 수 있습니다. 또한 제한된 전원 컴퓨팅 환경에서 응용 프로그램 전송 형식의 바람직한 기능 중 하나는 정적 표현과 런타임 표현 사 이에 특수 로딩이나 변환 과정없이 “그대로” 응용 프로그램을 실행할 수 있는 기능입니다. 표준 Java 클래스 파일은 그러한 실행을 위해 설계되지 않았습니다.

CLDC 규격은 공개적으로 표현되고 분산된 Java 응용 프로그램에 압축된 JAR 파일을 사용 할 것을 요구합니다. 하지만 폐쇄된 네트워크 환경(5.3.2절 “Java 응용 프로그램 및 자원의 공개 표현“의 설명 참조)에서 그리고 런타임 시 가상 머신의 내부에서 대체 형식을 사용할 수 있습니다. 예를 들어, 낮은 대역폭 무선 네트워크에서 네트워크 대역폭을 유지하기 위해 네트워크 전송 수준에서 좀 더 압축된 다른 전송 형식을 사용하는 것이 합리적인 경우도 있 습니다. 마찬가지로 응용 프로그램의 관찰 가능한 사용자 수준 의미(semantics)가 원래 표현

이 기술은 특정 메모리 기술과 독립적으로 사용할 수 있으므로 ROMizing이란 용어는 약간 잘못되었습니다.

ROMized 클래스 파일이 반드시 ROM에 저장되어야 하는 것은 아닙니다.

과 같은 한, 다운로드된 응용 프로그램을 CLDC 장치에 저장할 때 보다 압축 가능한 표현을 사용할 수 있습니다. CLDC Java 응용 프로그램을 공개적으로 표현하거나 분배하기 위해 대 체 형식은 사용할 수 없습니다. 즉, CLDC Java 응용 프로그램의 공개 표현은 5.3.2절 “Java 응용 프로그램 및 자원의 공개 표현“에 정의된 내용과 항상 같아야 합니다.

대체 응용 프로그램 표현에 대한 정의는 구현 종속되며 CLDC 규격의 범위를 벗어난다고 가정합니다.

6장

CLDC 라이브러리

6.1 개요

Java 2 Platform, Standard Edition (J2SE)과 Java 2 Platform, Enterprise Edition (J2EE)은 데 스크탑 컴퓨터와 서버 시스템의 응용 프로그램 개발을 위한 아주 많은 라이브러리를 제공합 니다. 안타깝게도 이러한 라이브러리에는 실행해야 할 메모리(MB)가 많이 필요하므로 제한 된 자원을 갖는 소형 장치에는 적합하지 않습니다.

CLDC의 라이브러리를 설계하기 위한 일반 목표는 다양한 소형 장치에 맞는 실용적 응용 프 로그램 개발과 프로화일 정의용으로 유용한 일련의 라이브러리를 최소한으로 제공하는 것 입니다. 2.1절 “목표“에 설명된 대로 CLDC는 다양한 소비자 장치용 최소 Java 플랫폼 기능 및 API만 포함하는 “최소 공통” 표준입니다. 메모리 제한이 엄격하고 오늘날의 소형 장치 기능이 다양하다고 가정하면 모든 사람에게 이상적인 일련의 라이브러리를 제공하는 것은 사실상 불가능합니다. 이 기능의 표준이 일부 장치 및 사용자에게는 너무 낮고 또 다른 장치 및 사용자에게는 높을 수 있습니다.

Java 2 Platform의 최신 버전과 호환되게 하려면 CLDC에 포함된 대부분의 라이브러리가

Java 2 Standard Edition 및 Java 2 Enterprise Edition의 일부여야 합니다. 상위 버전과의 호환은 아주 이상적인 목표이지만 J2SE 및 J2EE 라이브러리에는 보안, 입출력, 사용자 인터 페이스 정의, 네트워킹 및 저장소 같은 중요한 영역에서의 세분화를 어렵게 하는 강한 내부 종속성이 있습니다. 이러한 종속성은 Java 라이브러리가 여러 번 개발되면서 이루어진 설계 진화 및 재사용의 자연스런 결과입니다. 안타깝게도 이러한 종속성은 다른 것을 여러 개 포 함하지 않고 라이브러리의 한 부분만 취하는 것을 어렵게 만듭니다. 이러한 이유로 라이브 러리 중 일부, 특히 네트워킹 영역에서 다시 설계했습니다.

CLDC 규격에 의해 정의된 CLDC 라이브러리는 다음 두 가지 범주로 나눌 수 있습니다.

표준 J2SE 라이브러리의 일부인 클래스
CLDC 에 해당하는 클래스(J2SE에서 매핑 가능) 전자의 범주에 속하는 클래스는 패키지 java.lang.*, java.util 및 java.io에 있습니 다. 이러한 클래스의 자세한 목록은 6.2절 “Java 2 Standard Edition에서 파생된 클래스“에 있습니다.

후자의 범주에 속하는 클래스는 패키지 javax.microedition.io에 있습니다. 이러한 클래스는 6.3절 “CLDC 관련 클래스“에서 설명합니다.

6.2 Java 2 Standard Edition에서 파생된 클래스

CLDC는 Java 2 Standard Edition 버전 1.3.1에서 파생된 많은 클래스를 지원합니다. J2ME 컨피규레이션 규칙은 J2SE 클래스와 같은 이름과 패키지 이름을 갖는 각 클래스가 해당 J2SE 클래스와 같거나 그 일부와 같을 것을 요구합니다. 하위 집합에 포함된 클래스 및 메소 드의 의미는 변경되지 않습니다. 클래스는 해당 J2SE 클래스에서 사용할 수 없는 공용 또는 보호되는 메소드나 필드는 추가하지 않습니다.

이 절에 나열된 클래스에 대한 정의를 참조하려면 Javadoc 형식의 CLDC 라이브러리에 대해 자세하게 요약한 부록 2를 참조하십시오.

6.2.1 시스템 클래스

J2SE 클래스 라이브러리는 Java 가상 머신과 긴밀하게 연결되어 있는 몇 가지 클래스를 포 함합니다. 마찬가지로 일부 표준 Java 도구는 시스템에 특정 클래스가 있다고 가정합니다. 예를 들어, 표준 Java 컴파일러(javac)는 클래스 String 및 StringBuffer의 특정 기능 을 사용할 수 있게 해주는 코드를 생성합니다. CLDC 규격 에 포함된 시스템 클래스는 아래 에 나열되어 있습니다. 이러한 각 클래스는 J2SE에 있는 해당 클래스의 일부입니다.

java.lang.Object java.lang.Class java.lang.Runtime java.lang.System java.lang.Thread java.lang.Runnable (인터페이스) java.lang.String java.lang.StringBuffer java.lang.Throwable

6.2.2 데이터 유형 클래스

java.lang 패키지의 다음 기본 데이터 유형 클래스가 지원됩니다. 이러한 각 클래스는 J2SE에서 해당 클래스의 일부입니다.

java.lang.Boolean java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long java.lang.Float java.lang.Double java.lang.Character

6.2.3 모음 클래스

java.util 패키지의 다음 모음 클래스가 지원됩니다.

java.util.Vector java.util.Stack java.util.Hashtable java.util.Enumeration (인터페이스)

6.2.4 입출력 클래스

java.io 패키지의 다음 클래스가 지원됩니다.

java.io.InputStream java.io.OutputStream java.io.ByteArrayInputStream java.io.ByteArrayOutputStream java.io.DataInput (인터페이스) java.io.DataOutput (인터페이스) java.io.DataInputStream java.io.DataOutputStream java.io.Reader java.io.Writer java.io.InputStreamReader java.io.OutputStreamWriter java.io.PrintStream

6.2.5 달력 및 시간 클래스

CLDC에는 표준 J2SE 클래스 java.util.Calendar, java.util.Date 및 java.util.TimeZone의 아주 일부분만 포함됩니다. 공간을 확보하기 위해 CLDC 규격은 한 표준 시간대만 지원할 것을 요구합니다. 기본적으로 이 표준 시간대는 GMT입니다. 표준 시간대가 Java 2 Standard Edition에서 제공한 표준 시간대와 호환 가능하다면 CLDC의 제 조업체별 구현에 의해 추가 표준 시간대가 제공될 수 있습니다.

java.util.Calendar java.util.Date java.util.TimeZone

6.2.6 추가 유틸리티 클래스

두 가지 추가 유틸리티 클래스가 제공됩니다. java.util.Random 클래스는 게임 같은 응용 프로그램을 구현할 때 유용한 간단한 의사 난수 생성기를 제공합니다. java.lang.Math 클래스는 다른 Java 라이브러리 클래스에서 주로 사용하는 min, max 및 abs 메소드를 제공 합니다. CLDC 1.1부터 클래스 java.lang.Math에도 ceil 및 floor 같은 몇 가지 추가 유틸리티 기능을 비롯하여 삼각 함수 및 제곤급 계산에 대한 지원이 포함됩니다.

java.util.Random java.lang.Math

6.2.7 예외 및 오류 클래스

CLDC에 포함된 라이브러리는 일반적으로 J2SE 라이브러리와 잘 호환되는 것이 목적이므로 CLDC에 포함된 라이브러리 클래스는 정규 J2SE 클래스와 마찬가지로 예외를 정확하게 발생시킵니다. 따라서 상당히 포괄적인 예외 클래스 집합이 포함되었습니다.

반대로 4.2절 “예외 및 오류 처리 제한“에 설명된 대로 CLDC의 오류 처리 기능은 제한됩니 다. 기본적으로 CLDC를 준수하는 가상 머신은 6.2.7.2절 “오류 클래스“의 아래에 나열된 오 류 클래스만 지원할 것을 요구합니다.

6.2.7.1 예외 클래스

java.lang.Exception java.lang.ArithmeticException java.lang.ArrayIndexOutOfBoundsException java.lang.ArrayStoreException java.lang.ClassCastException java.lang.ClassNotFoundException java.lang.IllegalAccessException java.lang.IllegalArgumentException java.lang.IllegalMonitorStateException java.lang.IllegalThreadStateException java.lang.IndexOutOfBoundsException java.lang.InstantiationException java.lang.InterruptedException java.lang.NegativeArraySizeException java.lang.NullPointerException java.lang.NumberFormatException java.lang.RuntimeException java.lang.SecurityException java.lang.StringIndexOutOfBoundsException

java.util.EmptyStackException java.util.NoSuchElementException

java.io.EOFException java.io.InterruptedIOException java.io.IOException java.io.UnsupportedEncodingException java.io.UTFDataFormatException

6.2.7.2 오류 클래스

java.lang.Error java.lang.NoClassDefFoundError java.lang.OutOfMemoryError java.lang.VirtualMachineError

6.2.8 약한 참조(Weak reference)

CLDC 규격 버전 1.1부터 다음 약한 참조(Weak reference) 클래스가 지원됩니다.

java.lang.ref.Reference java.lang.ref.WeakReference

6.2.9 국제화

문자 세트 및 대소문자 구분 변환 지원. 유니코드 문자를 지원하기 위해 CLDC 구현이 필요 합니다. 문자 정보는 Unicode Standard 버전 3.0을 기본으로 합니다. 하지만 유니코드 지원에 필요한 전체 문자 테이블은 예상 메모리가 아주 작은 장치에는 지나치게 클 수 있으므로 기 본적으로 CLDC의 문자 특성 및 대소문자 변환 기능에서는 ISO Latin-1 문자 범위만 있다고 가정합니다. 좀 더 구체적으로 구현 시 Unicode 3.0의 “Basic Latin” 및 “Latin-1 Supplement” 블록에서 문자 속성 및 대소문자 변환 지원을 제공해야 합니다. 다른 유니코드 문자 블록도 필요에 따라 지원될 수 있습니다1 .

문자 코드화. CLDC에는 바이트 시퀀스 간 유니코드 문자 변환에 대한 제한된 기능이 포함 됩니다. J2SE에서 이 작업은 Readers와 Writers라는 객체를 사용하여 이루어지며 동일한 구 성자를 갖는 InputStreamReader 및 OutputStreamWriter 클래스를 사용하여 CLDC 에서 이와 같은 기법이 활용됩니다.

new InputStreamReader(InputStream is); new InputStreamReader(InputStream is, String enc); new OutputStreamWriter(OutputStream os); new OutputStreamWriter(OutputStream os, String enc);

enc 매개 변수가 있는 경우 사용할 인코딩의 이름입니다. 이 매개 변수가 없는 경우 기본 인코딩(시스템 속성 microedition.encoding에 의해 정의됨)이 사용됩니다. 특정 구현 에 의해 추가 변환기가 제공될 수 있습니다. 특정 인코딩의 변환기를 사용할 수 없는 경우 UnsupportedEncodingException이 발생됩니다. J2SE에서의 문자 코드화에 대한 공식 정보에 대해서는 http://java.sun.com/products/jdk/1.3/docs/guide/intl/ encoding.doc.html을 참조하십시오.

현지화 지원 없음. CLDC는 현지화 기능을 제공하지 않습니다. 날짜, 시간, 통화 등과 관련된 모든 솔루션은 CLDC 규격의 범위를 벗어난다는 의미입니다.

CLDC 참조 구현 시 구현 클래스 com.sun.cldc.i18n.uclc.DefaultCaseConverter를 무시하여 이 작 업을 완료할 수 있습니다.

6.2.10 등록 정보 지원

CLDC를 준수하는 가상 머신에는 Java 2 Standard Edition에서 많이 사용되던 java.util.Properties 클래스가 포함되어 있지 않습니다. J2SE에서 해당 클래스는 호 스트 운영 체제의 이름, 가상 머신의 버전 번호 같은 시스템 등록 정보를 저장하는 데 사용됩 니다.

CLDC에서는 표 1에 설명되어 있는 제한된 등록 정보 집합을 사용할 수 있습니다. 이러한 등록 정보는 System.getProperty(String key) 메소드를 호출하여 액세스할 수 있습 니다. 표 1 CLDC 시스템 등록 정보

키 설명	값
`microedition.platform`호스트 플랫폼이나 장치의 이름	(구현 종속)
`microedition.encoding`	기본 문자 코드화	기본값: `“`ISO-8859-1`”`
`microedition. configuration`	지원되는 컨피규레이션의 이름 및 버전	`“`CLDC-1.1”
`microedition.profiles`지원되는 프로화일의 이름	(구현 종속)

등록 정보 microedition.encoding은 기본 문자 코드화 이름을 설명합니다. 이 정보는 국제화 지원 시 기본 문자 코드화의 올바른 클래스를 찾기 위해 시스템에서 사용합니다. 등록 정보 microedition.platform은 호스트 플랫폼이나 장치의 특색을 이룹니다. 등록 정보 microedition.configuration은 현재 J2ME 컨피규레이션 및 버전을 설명하고 등록 정보 microedition.profiles는 공백으로 구분된 지원되는 프로화일의 이름이 포함된 문자열을 정의합니다.

위에 정의된 등록 정보 집합은 J2ME 프로화일 규격이나 장치 제조업체에 의해 확장될 수 있 습니다. 예를 들어 MIDP 규격은 위의 표 1에 포함되지 않은 추가 등록 정보를 정의합니다.

제조업체별 등록 정보 정의는 제조업체별 클래스가 사용하는, 같은 패키지 이름(예:

“com.companyname.propertyname”)으로 접두어를 붙여야 합니다. “java” 및 “javax” 이름 공간을 비롯한 “microedition” 이름 공간은 예약되며 공식 J2ME 컨피규 레이션 및 프로화일에 의해서만 확장될 수 있습니다.

6.3 CLDC 관련 클래스

이 절에는 입출력 지원 및 일반화된 확장 가능 방식의 네트워킹을 위한 일반 연결 프레임워 크에 대한 설명이 포함되어 있습니다. 일반 연결 프레임워크는 자원 제약형 환경에서 다양 한 네트워크 유형을 액세스하기 위한 일관된 방식을 제공합니다.

6.3.1 배경 및 동기 부여

Java 2 Standard Edition 및 Java 2 Enterprise Edition에 포함된 클래스 라이브러리는 저장 소 및 네트워크 시스템에 대한 입출력 액세스를 처리하기 위한 풍부한 일련의 기능을 제공 합니다. 예를 들어, JDK 1.3.1에서 패키지 java.io.*는 59개의 정규 클래스와 인터페이스 및 16개의 예외 클래스를 포함합니다. JDK 1.3.1의 패키지 java.net.*의 31개의 정규 클래 스와 인터페이스 및 8개의 예외 클래스로 구성됩니다. 전체 예상 메모리가 몇 백 KB 밖에 안 되는 소형 장치에 모든 기능을 끼워 넣기는 어렵습니다. 또한 표준 I/O 및 네트워킹 기능의 중요한 부분은 TCP/IP 지원을 제공하지 않기도 하고 IrDA (infrared) 또는 Bluetooth 같은 특정 연결 유형을 지원할 필요가 없기도 한, 오늘날의 소형 장치에 직접 적용할 수 없습니다.

일반적으로 네트워킹 및 저장소 라이브러리의 요구 사항은 한 개의 자원 제약형 장치에서 다른 장치에 이르기까지 매우 다양합니다. 예를 들어, 패킷 교환 네트워크를 사용하는 장치 제조업체는 일반적으로 데이터그램 기반 통신 기법을 원하는 반면 회선 교환 네트워크를 사 용하는 장치 제조업체는 스트림 기반 연결을 일반적으로 선호합니다. 일부 장치는 전통적 파일 시스템을 갖지만 많은 다른 장치는 장치에 많이 의존하는 기법을 갖습니다. 엄격한 메 모리 제한으로 인해 특정 종류의 입출력, 네트워킹 및 저장소 기능을 지원하는 제조업체는 다른 기법을 지원하려고 하지 않습니다. 따라서 CLDC를 위한 이러한 기능의 설계는 매우 힘이 듭니다. 특히 J2ME 컨피규레이션은 선택적 기능의 정의를 허용하지 않기 때문에 특히 그렇습니다. 또한 여러 네트워킹 기법과 도구가 있으면 응용 프로그램 프로그래머에게 잠재 적으로 혼동을 줄 수 있으며 프로그래머가 낮은 수준의 프로토콜 문제를 다루어야 하는 경 우 특히 그렇습니다.

6.3.2 일반 연결 프레임워크

위에 제시된 어려움으로 인해 J2SE 네트워크 및 I/O 클래스의 일반화에 이르렀습니다. 이러 한 일반화된 설계의 목표는 J2SE 클래스의 기능상 일부가 되어 일반 낮은 수준의 하드웨어 나 J2SE 구현에 쉽게 매핑하면서 새 장치 및 프로토콜을 지원할 때 더 나은 확장성, 융통성 및 일관성을 제공하는 것입니다.

일반 개념은 아래에 설명되어 있습니다. 다양한 통신 형식에 대해 다양한 추출 모음을 사용 하는 대신 일련의 관련 추출이 응용 프로그램 프로그래밍 수준에서 사용됩니다.

일반 형식

Connector.open("<protocol>:<address>;<parameters>");

주 – 이러한 예는 설명을 위해서만 제공됩니다. CLDC 자체는 프로토콜 구현을 정의하지 않습니다(6.3.3절 “CLDC에 정의되어 있는 네트워크 프로토콜 구현이 없음“ 참조”). 특정 J2ME 프로화일이 이러한 모든 연결 종류에 대한 지원을 제공할 것이라고 기대하지는 않습 니다. J2ME 프로화일은 아래에 표시되지 않은 프로토콜을 지원할 수도 있습니다.

HTTP

Connector.open("http://www.sun.com");

소켓

Connector.open("socket://129.144.111.222:2800");

통신 포트

Connector.open("comm:0;baudrate=9600");

데이터그램

Connector.open("datagram://129.144.111.222:2800");

모든 연결은 클래스 javax.microedition.io.Connector의 정적 메소드 open을 호출 하여 만들어집니다. 연결에 성공하면 이 메소드는 그림 3에 표시된 javax.microedition.io.Connection 인터페이스 중 하나를 구현하는 객체를 반환합 니다. Connector.open 메소드는 String 매개 변수를 다음과 같은 일반 형식으로 사용합 니다.

Connector.open("<protocol>:<address>;<parameters>");

그림 3 연결 인터페이스 계층

Connector.open 매개 변수 문자열의 구문은 IETF 표준 RFC2396 (http://

www.ietf.org/rfc/rfc2396.txt)에 정의된 대로 Uniform Resource Indicator (URI) 구문을 따르는 것이 일반적입니다.

이 설계의 주요 목표는 프로토콜을 사용할 때의 차이점을 연결 유형을 특성있는 문자열로 가능한 한 많이 분리하는 것입니다. 이 문자열은 메소드 Connector.open의 매개 변수입 니다. 이 방법의 주요 장점은 사용된 연결 종류에 상관없이 응용 프로그램 코드의 크기가 같다는 것입니다. 한 통신 형식에서 다른 통신 형식으로 변경할 때 응용 프로그램에 사용된 추출 및 데이터 유형이 많이 달라지곤 하는 전통적 구현과는 다릅니다.

J2ME 프로그램에 프로토콜을 바인딩하는 작업은 런타임에 이루어집니다. 구현 수준에서 메

소드 Connector.open의 매개 변수로서 제공되는 문자열(‘:’의 첫 번째 발생까지)은 모든 프로토콜 구현에서 저장된 위치로부터 원하는 프로토콜 구현을 얻을 것을 시스템에 지시합 니다. 이것이 바로 프로그램이 동적으로 다양한 프로토콜을 런타임에 사용할 수 있게 해주는 늦은 바인딩 기법입니다. 따라서 이 작업은 개인 컴퓨터나 워크스테이션에서 응용 프로그램 과 장치 드라이버 사이의 관계와 동일합니다.

6.3.3 CLDC에 정의되어 있는 네트워크 프로토콜 구현이 없음

CLDC 규격에 정의된 일반 연결 프레임워크는 실제 지원된 네트워크 프로토콜을 지정하거나 특정 네트워킹 프로토콜의 구현을 명령하지 않습니다. CLDC 규격이 제공하는 내용은 특정 장치 범주에 필요할 수 있는 프로토콜을 지원하는 MIDP 같은 J2ME 프로화일에서 사용자 정의 가능한 확장 가능 프레임워크입니다. 지원되는 프로토콜에 관한 실제 구현 및 결정은 프로화일 수준에서 이루어져야 합니다.

6.3.4 일반 연결 프레임워크의 설계

다양한 장치 유형에 대한 연결 시 다양한 동작 형식을 나타내야 합니다. 예를 들어 파일 이름 은 바꿀 수 있지만 TCP/IP 소켓에 대해 유사한 작업은 없습니다. 일반 연결 프레임워크는 이러한 다양한 기능을 반영하므로 논리적으로 같은 작업이 같은 API를 공유하게 합니다.

일반 연결 프레임워크는 같은 의미를 갖는 프로토콜 클래스를 함께 묶는 Connection 인터 페이스(javax.microedition.io 패키지에 위치)의 계층을 사용하여 구현됩니다. 이 계 층은 위의 그림 3에 표시된 7개의 인터페이스로 구성됩니다. 또한 Connector 클래스, 한 개의 예외 클래스(ConnectionNotFoundException), 한 개의 다른 인터페이스 및 데이 터를 읽고 쓰기 위한 많은 데이터 스트림 클래스가 있습니다. 지원되는 프로토콜 각각을 구 현하려면 구현 수준에서 최소한 한 개의 클래스가 필요합니다. 가끔 각 프로토콜 구현 클래 스에는 기본 호스트 운영 체제의 원시 함수를 호출하는 많은 래퍼 기능이 포함되어 있을 뿐 입니다.

일반 연결 프레임워크가 지정하는 여섯 개의 기본 인터페이스 유형이 있습니다.

기본 순차 입력 연결
기본 순차 출력 연결
데이터그램 지향 연결
회선 지향 연결
클라이언트 서버 연결의 서버를 알려주기 위한 알림 기법
기본 웹 서버 연결 Connection 인터페이스의 모음은 루트 Connection 인터페이스에서 계층이 진행되어 감에 따라 점진적으로 사용할 수 있는 계층을 형성합니다. 이 배열을 사용하면 J2ME 프로화 일 설계자나 응용 프로그램 프로그래머가 설계 중인 라이브러리와 응용 프로그램에 대해 크 로스 프로토콜 이식성의 최적 수준을 선택할 수 있습니다.

일반 연결 프레임워크는 J2ME 프로화일이 새 연결 유형을 요구하는 경우 추가 인터페이스 를 나중에 추가할 수 있도록 확장 가능하게 합니다.

Connection 인터페이스 계층은 그림 3에 설명되어 있습니다. 각 인터페이스 클래스의 간단한 요약은 아래에 나와 있습니다. Connection 인터페이스에 대한 정의 참조는 CLDC 참조 구현의 일부로 제공되는 설명서를 참조하십시오.

6.3.4.1 인터페이스 `Connection`

열고 닫을 수만 있는 가장 기본적인 연결 유형입니다. 연결은 Connector 클래스의 정적 open 메소드를 사용하여 항상 열리므로 open 메소드는 인터페이스에 포함되어 있지 않습 니다.

메소드:

public void close() throws IOException;

6.3.4.2 인터페이스 InputConnection

이 연결 유형은 데이터를 읽어 들일 수 있는 장치를 나타냅니다. 이 인터페이스의 openInputStream 메소드는 연결할 InputStream을 반환합니다. 이 인터페이스의 openDataInputStream 메소드는 연결할 DataInputStream을 반환합니다.

메소드:

public InputStream openInputStream() throws IOException; public DataInputStream openDataInputStream() throws IOException;

6.3.4.3 인터페이스 OutputConnection

이 연결 유형은 데이터를 기록할 장치를 나타냅니다. 이 인터페이스의 openOutputStream 메소드는 연결할 OutputStream을 반환합니다. 이 인터페이스의 openDataOutputStream 메소드는 연결할 DataOutputStream을 반환합니다.

메소드:

public OutputStream openOutputStream() throws IOException; public DataOutputStream openDataOutputStream() throws IOException;

6.3.4.4 인터페이스 StreamConnection

이 연결 유형은 InputConnection과 OutputConnection 인터페이스를 결합하여 양방 향 인터페이스를 구현하는 클래스의 논리적 시작 위치를 형성합니다.

6.3.4.5 인터페이스 ContentConnection

이 연결 유형은 StreamConnection의 하위 인터페이스로 HTTP 연결에서 제공하는 가장 기본적인 메타데이터 정보 중 일부에 대한 액세스를 제공합니다. 메소드:

public String getType(); public String getEncoding(); public long getLength();

6.3.4.6 인터페이스 StreamConnectionNotifier

연결이 설정되길 기다릴 때 이 연결 유형이 사용됩니다. 클라이언트 프로그램이 연결될 때 까지 이 인터페이스의 acceptAndOpen 메소드는 차단될 것이며 통신 링크가 설정된 StreamConnection을 반환합니다. 다른 모든 연결처럼 더 이상 필요하지 않으면 StreamConnection을 닫아야 합니다.

메소드:

public StreamConnection acceptAndOpen() throws IOException;

6.3.4.7 인터페이스 DatagramConnection

이 연결 유형은 데이터그램 종점을 나타냅니다. J2SE 데이터그램 인터페이스와 마찬가지로 연결을 열기 위해 사용된 주소는 데이터그램을 수신한 종점입니다. 전송된 데이터그램의 대상은 데이터그램 자체에 놓여 있습니다. 이 API에는 주소 객체가 없습니다. 대신 Connection 인터페이스 설계에서와 유사한 방식으로 주소 지정을 추출할 수 있는 문자열 이 사용됩니다. 메소드:

public int getMaximumLength() throws IOException; public int getNominalLength() throws IOException; public void send(Datagram datagram) throws IOException; public void receive(Datagram datagram) throws IOException; public Datagram newDatagram(int size) throws IOException; public Datagram newDatagram(int size, String addr) throws IOException; public Datagram newDatagram(byte[] buf, int size) throws IOException; public Datagram newDatagram(byte[] buf, int size, String addr) throws IOException;

이 DatagramConnection 인터페이스에는 이와 관련된 데이터 버퍼와 주소를 포함하기 위해 사용된 Datagram이라는 데이터 유형이 필요합니다. Datagram 인터페이스에는 데이 터를 데이터그램 버퍼에 두거나 여기서 데이터를 추출할 때 사용할 수 있는 일련의 유용한

액세스 메소드가 포함됩니다. 이러한 액세스 메소드는 DataInput 및 DataOutput 인터페 이스를 준수하므로 데이터그램 객체도 스트림처럼 작동한다는 의미입니다. 현재 위치는 다이어그램에서 유지되고 읽기 작업이 수행된 다음 데이터그램 버퍼의 시작 부분으로 자동 재설정됩니다.

6.3.5 추가 주의

일반 연결로부터 데이터를 읽고 쓸 수 있으려면 많은 입출력 스트림 클래스가 필요합니다.

CLDC에서 지원하는 스트림 클래스는 절 6.2.4, “입출력 클래스”에 나열되어 있습니다. J2ME 프로화일은 필요에 따라 추가 스트림 클래스를 제공합니다.

부록 A

부록

부록 1: CLDC 바이트 코드 유형 검사기 규격 부록 2: Javadoc 형식의 CLDC 라이브러리 설명서

spec

머리말

이 규격의 사용 대상

이 규격의 구성

관련 문서

관련 웹 페이지

수정 사항 기록

주석

소개 및 배경

1.1 CLDC 전문가 그룹

1.2 CLDC 규격 버전 1.1과 1.0의 주요 차이점

목표, 요구 사항 및 범위

2.1 목표

2.2 요구 사항

2.2.1 하드웨어 요구 사항

2.2.2 소프트웨어 요구 사항

2.2.3 J2ME 요구 사항

2.3 범위

높은 수준의 구조 및 보안

3.1 CLDC 높은 수준의 구조

3.2 Java 응용 프로그램의 개념

3.3 응용 프로그램 관리

3.4 보안

3.4.1 낮은 수준(가상 머신) 보안

3.4.2 응용 프로그램 수준 보안

3.4.2.1 샌드 박스 모델

3.4.2.2 시스템 클래스 보호

3.4.2.3 동적 클래스 로딩에 대한 추가 제한

3.4.3 종단간 보안

Java 언어 규격 유지

4.1 클래스 인스턴스 finalization 지원 안함

4.2 예외 및 오류 처리 제한

Java 가상 머신 규격 유지

5.1 가상 머신에서 제거된 기능

5.1.1 사용자 정의된 클래스 로더

5.1.2 스레드 그룹 및 데몬 스레드

5.1.3 클래스 인스턴스 finalization

5.1.4 오류 및 비동기 예외

5.2 클래스 파일 확인

5.2.1 장치 분리 사전 확인(Off-device preverification) 및 스택 맵을 사용하여 런타임 확인

5.2.1.1 확인 과정

5.2.1.2 스택 맵 속성 정의

5.3 클래스 파일 형식 및 클래스 로딩

5.3.1 지원되는 파일 형식

5.3.2 Java 응용 프로그램 및 자원의 공개 표현

5.3.3 클래스 파일 조회 순서

5.3.4 구현 최적화 및 대체 응용 프로그램 표현 형식

CLDC 라이브러리

6.1 개요

6.2 Java 2 Standard Edition에서 파생된 클래스

6.2.1 시스템 클래스

6.2.2 데이터 유형 클래스

6.2.3 모음 클래스

6.2.4 입출력 클래스

6.2.5 달력 및 시간 클래스

6.2.6 추가 유틸리티 클래스

6.2.7 예외 및 오류 클래스

6.2.7.1 예외 클래스

6.2.7.2 오류 클래스

6.2.8 약한 참조(Weak reference)

6.2.9 국제화

6.2.10 등록 정보 지원

6.3 CLDC 관련 클래스

6.3.1 배경 및 동기 부여

6.3.2 일반 연결 프레임워크

HTTP

6.3.3 CLDC에 정의되어 있는 네트워크 프로토콜 구현이 없음

6.3.4 일반 연결 프레임워크의 설계

6.3.4.1 인터페이스 Connection

6.3.4.2 인터페이스 InputConnection

6.3.4.3 인터페이스 OutputConnection

6.3.4.4 인터페이스 StreamConnection

6.3.4.5 인터페이스 ContentConnection

6.3.4.6 인터페이스 StreamConnectionNotifier

6.3.4.7 인터페이스 DatagramConnection

6.3.5 추가 주의

부록

6.3.4.1 인터페이스 `Connection`