基本介紹
- 中文名：有限連線設備配置
- 外文名：CLDC (Connected Limited Device Configuration)
- 版本： 1.0和1.1兩個版本
- 支持：profile
發展,目標,整體需求,功能範圍,新特性,安全機制,類庫,
發展
商完成的。
CLDC
CLDC2000年5月，Java Community Process（JCP）公布了CLDC1.0規範（即JSR30）。CLDC是J2ME核心配置中的一個，可以支持一個或多個profile。其目標主要面向小型的、網路連線速度慢、能源有限（主要是電池供電）且資源有限的設備，如手機、機頂盒、PDA等。CLDC1.0的規範可以在jcp的網站上下載。
目標
1) 為小型的、資源受限的連線設備定義一個Java 平台標準
2) 允許向上述設備動態的傳遞Java 套用和內容
3) 使Java 開發人員能夠輕鬆的在這些設備上進行套用開發
整體需求
1) 能運行在絕大多數的小型的、資源受限的連線設備上
2) 用CLDC 為上述設備開發的套用儘可能的不使用設備的本地系統軟體（做到與平台、設備無關）
3) 定義能套用在絕大多數上述設備上的最小子集的規範
1. CLDC 的硬體需求
由於CLDC 要面向儘可能多的設備，而這些設備所使用的硬體又各不相同。因此CLDC 規範中並沒有指明需要某種硬體支持，只是對設備的最小記憶體進行了限制。CLDC 規範中要求硬體必須達到以下要求：
1) 至少160KB 的固定記憶體以供虛擬機和CLDC 核心類庫使用。
2. CLDC 的軟體需求
和硬體類似，CLDC 上運行的軟體也是多種多樣的。例如，有些設備支持多進程作業系統或者支持檔案系統；而有些功能極其有限的設備並不需要檔案系統。對於這些不確定性，CLDC只定義了軟體所必須的最小集合。CLDC 規範中要求作業系統不需要支持多進程或是分址空間定址，也不用考慮運行時的協調和延遲；但是必須提供至少一個可控制的實體來運行虛擬機。
功能範圍
4.1 CLDC包含的功能在CLDC1.0版本中定義了以下功能：
2）核心Java類庫
3）輸入/輸出
4）對網路的支持
5）對安全性的支持
6）對國際化的支持
4.2 CLDC不包含的功能1）對應用程式生命周期的管理
2）用戶界面
3）事件處理
4）高級應用程式模式（這裡指用戶與應用程式的互動）
4.3 CLDC與J2SE的關係
CLDC包含了一個基本的J2ME運行環境，其中包括虛擬機和核心的java類庫。作為專門針對於小型設備的配置，CLDC對J2SE類庫進行了大量的簡化，其類庫只保留了java 規範中定義的最核心的3個包，即java.iojava.lang和java.util，並重新定義了一個新的包javax.microedition。這裡你可以通過前綴來區別：java.表示核心的java包，javax.表示標準java擴展包。
這裡要注意的是在CLDC中定義的javax.microedition包為javax.microedition. io，用來支持通用連線框架（GCF，Generic connection framework）。CLDC中的包和所對應的功能如下所示：
1) CLDC包
2) 對應的功能
1) java.io
2) 標準的輸入/輸出功能，J2SE java.io包的子集
3) java.lang
4) 核心語言包，J2SE的子集
5) java.util
6) 實用類
7) javax.microedition. io
8) 通用連線框架類及接口
CLDC中的包和所對應的功能
javax.microedition中其他的包定義了CLDC中沒有定義的功能，如對應用程式生命周期的管理、用戶界面（UI）、事件處理模式、永久性存儲和用戶與應用程式的互動等。這些功能的定義是由Profile （即MIDP）來完成的。
4.4 CLDC核心類庫與J2SE的主要區別
由於CLDC主要針對16位、32位主頻在16MHz以上的處理器，設備記憶體只有512KB，甚至更少，而目前Windows平台下運行的JVM需要的最小記憶體為16M。因此CLDC所使用的虛擬機和核心類庫與J2SE的並不相同。
1．不支持浮點數據類型（沒有float和double）
因為很多使用CLDC的設備硬體都不支持浮點運算，而且處理浮點運算需要較大的記憶體。因此在CLDC1.0中，並沒有要求虛擬機支持浮點數據類型。
9) dadd
10) dmul
11) fadd
12) fmul
13) i2d
14) dalaod
15) dneg
16) faload
17) fneg
18) i2f
19) dastore
20) drem
21) fastore
22) frem
23) l2d
24) dcmpg
25) dreturn
26) fcmpg
27) freturn
28) l2f
29) dcmpl
30) dstore
31) fcmpl
32) fstore
33) newarray(double)
34) dconst_0
35) dstore_x
36) fconst_0
37) fstore_x
38) newarray(float)
39) dconst_1
40) dsub
41) fconst_1
42) fsub
43)
44) ddiv
45) d2f
46) fdiv
47) f2f
48)
49) dload
50) d2i
51) fload
52) f2i
53)
54) dload_x
55) d2l
56) fload_x
57) f2l
58)
CLDC不支持的浮點數據類型
2．不支持JNI (the Java Native Interface )
CLDC不提供native code的支持，除了因為設備記憶體有限外，還出於安全性的考慮。因為CLDC中缺少完整的安全性模型，禁用了這些J2SE的特性可以使潛在的安全風險降到最低。
CLDC不允許用戶自定義類載入器。按照CLDC規範的要求，類的載入是不能被覆蓋、替換和修改的。和JNI類似，這些是出於安全方面的一些考慮。
4．不支持反射(reflection)
不支持java.lang.reflect包以及java.lang.Class中和reflection有關的函式。其目的主要是節省記憶體占用。
CLDC提供了對執行緒的支持，也支持多執行緒，但是執行緒組和守護執行緒是不被允許的。每個執行緒都要生成獨立??程的操作，則必須在應用程式的級別上自行實現多個Thread對象的控制，如使用Hashtable和Vector來存取多個Thread對象。
6．不支持類實例（class instance）的終結（finalization）
CLDC類庫不包含java.lang.Object.finalize()方法，因此類對象的終結是不支持的。對於套用CLDC的設備來說，對象終結相對於它所起的作用來說實現起來過於複雜，並不被需要。
7．不支持弱引用（weak references）
8．有限的錯誤處理（error handling）
在J2SE中定義了大量的類用來描述各種錯誤和異常，而CLDC僅僅包含有限的幾個J2SE的核心類庫，因此大部分java.lang.Error的子類都未被支持，這包括異步異常。這是因為在嵌入式系統中，應用程式並不期望獲得設備的出錯處理機制；定義和運行出錯處理需要較大的虛擬機的開銷，而這些出錯的代碼信息對於連用戶界面都沒有的有限連線設備來說是沒有用處的。
新特性
CLDC1.1即JSR139相對於1.0版本並沒有本質上的變化。隨著硬體水平的不斷提高，CLDC1.1在兼容性和可用性上作了一些改進，並增加了一些1.0版本沒有的新特性：
1. 增加對浮點數據的支持
2. 核心類庫中增加java.lang.Float類和java.lang.Double類
3. 部分支持弱參考（weak references）
4. Calendar、Date和TimeZone類被重新設計
5. 與J2SE中的類更加類似
6. 對錯誤處理有了更加明確的定義
7. 並增加了 NoClassDefFoundError 類
8. 對於Thread類
9. CLDC1.1允許為執行緒命名
10. 並通過getName() 方法得知執行緒的名字
11. 增加interrupt()方法
12. 允許中斷執行緒；增加了新的構造方法。
13. 對一些類庫進行了小的修改
14. 以下的方法被添加或是修正： Boolean.TRUE and Boolean.FALSE Date.toString() Random.nextInt(int n) String.intern() String.equalsIgnoreCase()
15. 由於允許使用浮點運算
16. 設備的最小記憶體被提高到160 至 192 KB
下面列出CLDC1.1增加的類和方法：
l 增加java.lang.Float和java.lang.Double類
l 增加以下和浮點數據相關的方法
java.lang.Integer.doubleValue()
java.lang.Integer.floatValue()
java.lang.Long.doubleValue()
java.lang.Long.floatValue()
java.lang.Math.abs(double a)
java.lang.Math.abs(float a)
java.lang.Math.max(double a, double b)
java.lang.Math.max(float a, float b)
java.lang.Math.min(double a, double b)
java.lang.Math.min(float a, float b)
java.lang.Math.ceil(double a)
java.lang.Math.floor(double a)
java.lang.Math.sin(double a)
java.lang.Math.cos(double a)
java.lang.Math.tan(double a)
java.lang.Math.sqrt(double a)
java.lang.Math.toDegrees(double angrad)
java.lang.Math.toRadians(double angrad)
java.lang.String.valueOf(double d)
java.lang.String.valueOf(float f)
java.lang.StringBuffer.append(double d)
java.lang.StringBuffer.append(float f)
java.lang.StringBuffer.insert(int offset, double d)
java.lang.StringBuffer.insert(int offset, float f)
java.io.DataInput.readDouble()
java.io.DataInput.readFloat()
java.io.DataInputStream.readDouble()
java.io.DataInputStream.readFloat()
java.io.DataOutput.writeDouble(double v)
java.io.DataOutput.writeFloat(float v)
java.io.DataOutputStream.writeDouble(double v)
java.io.DataOutputStream.writeFloat(float f)
java.io.PrintStream.print(double d)
java.io.PrintStream.print(float f)
java.io.PrintStream.println(double d)
java.io.PrintStream.println(float f)
java.util.Random.nextDouble()
java.util.Random.nextFloat()
l 增加浮點計算常量е和圓周率π:
java.lang.Math.E
java.lang.Math.PI
l 增加弱參考類java.lang.ref.Reference和java.lang.ref.WeakReference。
l 新增錯誤類NoClassDefFoundError。
l 增加Thread類的構造函式及方法:
Thread.getName()
Thread.interrupt()
Thread(Runnable Target, String name)
Thread(String name)
l 新增的一些常數及方法:
java.lang.Boolean.TRUE and java.lang.Boolean.FALSE
java.lang.String.intern()
java.lang.String.equalsIgnoreCase()
java.util.Date.toString()
java.util.Random.nextInt(int n)
要查看CLDC1.1更詳細的變化可以去Sun的網站下載CLDC1.1的規範
安全機制
5.1 CLDC的安全級別
1，底層安全機制（low-level security）
底層安全就是通常說的虛擬機的安全，是虛擬機運行在CLDC設備上的最關鍵的安全機制。它要求運行在虛擬機上的應用程式必須遵循Java語言的標準語法，且能夠檢查出並組織惡意代碼（類）以各種方式對設備進行破壞。對於標準的Java虛擬機的實現，虛擬機使用類審核的方式來保證虛擬機安全。類審核機制能夠確保類檔案中的位元組碼以及其他對象不包含非法指令，不會以非法的順序被執行，也不會訪問虛擬機以外的非法記憶體地址或是地址段。
在CLDC中，類的審核機制不同於J2SE，它增加了預審核（pre-verification）機制。2.3.1節將對CLDC的預審核機製做詳細的說明。
2，套用級別安全機制（application-level security）
僅用類審核機制來保證Java平台的安全運行是不夠的。因為它僅僅能夠確保應用程式的代碼是可用的，還有很多潛在的安全威脅沒有被涉及到，如對檔案系統、列印設備、紅外、本地類庫以及網路等安全管理。在套用級別安全機制中，CLDC規定，Java應用程式只能訪問系統類庫、系統資源、額外的設備元件（如即插即用的設備等）和Java運行環境。
具體的實現是：應用程式運行在一個封閉的沙箱（sandbox）環境中以得到保護。在沙箱中，只有系統已定義的配置（configuration）、簡表（profile）、可選包以及設備支持的一些類可以被應用程式訪問。任何沒有預先定義類庫和資源都不允許訪問，以防程式中的惡意代碼對沙箱外的資源（如作業系統、硬碟等）非法訪問或者破壞。
沙箱的需求主要有：
l 應用程式的下載、安裝和管理等操作都不能修改、覆蓋或著繞過類虛擬機實現的標準的載入機制。
l 只有預先定義好的，封閉的Java API和類可以被應用程式調用。這包括配置、簡表、可選包以及該套用自定義的類。
l 任何沒有被CLDC定義的native code都不允許調用。這意味著應用程式不能下載一個新的含有native code的類庫並使用。
l CLDC規範額外規定了系統類和應用程式類的命名規則。也就是說，為了滿足上面說的沙箱的要求，所有java.*和java.microedition.*都屬於系統類，不能被覆蓋，修改；也不能任意增減。應用程式類不能使用上述包名來實現自己的類。
l 而且，除了調用系統類之外，應用程式只能調用自身JAR包中的類。這樣保證了應用程式不能從其他的應用程式中“偷”數據(或類的實現)來達到自身的目的。
註：在最新的JSR246（Device Management）中，通過設備管理框架（Device Management Framework），滿足一定條件的應用程式有可能訪問其他應用程式的數據，但是對絕大多數應用程式來說，別人的數據仍然是不可以訪問的。（想用楷體，但是機器上沒有除宋體以外的其他字型……哭）
3，端對端的安全機制（end-to-end security）
5.2 CLDC中類的預審核模式
3）每個對象的構造方法都必須調用父類的構造方法（要求最先調用java.lang.Object的構造方法）
類的審核機制僅僅針對於外來的類檔案（比如從網路上下載的），而對本地檔案系統中的類的載入是不用審核的。
在CLDC的預審核機制中，要下載的Java類檔案的每一個方法都包含了一個堆疊映射屬性，這個屬性是CLDC獨有的，J2SE規範中沒有定義。堆疊映射的屬性會通過虛擬機的預審核器添加到標準的類檔案中，該預審核器會分析類中的每一個方法。堆疊映射屬性通常會增加約5%的類的大小。
如圖所示，當程式的源程式被編譯後，必須被預審核器預審核，然後才能生成可以被下載到目標設備上運行的類檔案。把一部分的審核任務放在預審核器中完成，可以使與CLDC兼容的虛擬機審核Java類檔案時速度更快，並且只需要很少的虛擬機代碼和動態記憶體，而它們的安全級別相同。因此，在CLDC/MIDP環境下開發程式，其程式經過編譯後，必須經過預審核後才能運行。
預審核機制
預審核機制特別需要說明的是：
2. 運行時的審核機制CLDC把它交給了設備自己去實現。設備可以根據自身的需要在載入類或是安裝應用程式的過程中執行。在運行時，虛擬機迅速地對位元組碼進行線性掃描，將每個有效的指令與合適的堆疊映射項相匹配。運行時的審核過程是建立在預審核機制之上的，所以比預審核還要快，占用的動態記憶體更少。
5.3 CLDC中的類的檔案格式
CLDC要求所有第三方開發的支持CLDC的Java應用程式在公開發布時都要使用JAR包的格式，而且JAR包內的類必須是經過了預審核器審核之後的。同樣的，CLDC要求所有實現CLDC的虛擬機也必須能夠識別和調用JAR包中的檔案。
類庫
CLDC標準為了能夠涵蓋儘可能多的設備，其類庫只包含了最小的Java平台特性和API。面對嚴格的記憶體限制和當前各種各樣的小型設備，CLDC不可能覆蓋全部的這些設備。因此在CLDC的規範中，不可避免的會造成對某些設備要求過高或是對另一些設備要求又太低的現象。
為了確保與其他Java平台的兼容性，絕大多數的CLDC類庫是從J2SE和J2EE中繼承的，是J2SE和J2EE的子集。由於目標設備的特殊性，CLDC類庫在安全、輸入/輸出、用戶界面、網路和存儲管理等方面沒有全部使用J2SE的實現；其中的部分類庫CLDC進行了重寫，如網路連線。
如4.3中所介紹的，CLDC的類庫可以分為兩種：一種是從J2SE標準類庫中繼承的；另一種是專門為CLDC設計的（這部分類也可以被映射到J2SE中）。
對於第一種CLDC類庫，包括了J2SE的3個最核心的包java.io、java.lang和java.util。而且這3個包和J2SE相比，也只是J2SE相應包的一個很小的子集。例如java.util的類與接口由J2SE中的53個減少到10個。
6.1 java.lang包
java.lang包包含了Java語言API的核心部分繼承下來的類，但是CLDC只繼承了J2SE中一半的類，而且一些類中的接口並沒有完全實現。這主要表現在：
1）絕大部分的虛擬機不支持錯誤類和部分異常類被去掉了。
2）不支持Float和Double數據類型及其相應的類
3）ClassLoader、SecurityManager等CLDC規範上沒有說明必須支持的類也不在此包中。
下表給出了CLDC 的java.lang包中的類及類的繼承關係。
CLDC1.0 java.lang包中的類及類的繼承關係Object類中需要注意的有以下兩點：
1. 沒有finalize( )方法。
數據類：
在前面已經提到過多次，CLDC不支持浮點數據類型，核心庫中的java.lang.Floart類和java.lang.Double類以及其他類中與浮點數據相關的方法均不予支持。CLDC支持的數據類型有：Boolean、Byte、Char、Integer、Long、Short和String。
需要注意的是：
1. java.lang.Number不在核心庫中，java.lang.Byte等基本數據類直接從java.lang.Object類繼承。
3. String類與J2SE相比變化較大，其中去掉了compareToIgnoreCase()、copyValueOf()、equalsIgnoreCase()、split()、match()和intern()等方法；其餘部分方法進行了縮減。
4. java.lang.Math類相對J2SE功能要小很多，只提供了和int、long有關的三組操作。
forName()方法和newInstance()方法仍然可以用，用來獲得未知的class對象。getResourceAsStream(String name)方法可以找到指定名字的資源，並以InputStream的形式獲得。該方法常用於讀取本地MIDlet JAR包中圖片或者文本檔案或是某個Java包。參數——name可以是絕對路徑（以“/”開頭，如/com/sun/MIDlet1/resources/pic.png），也可以是相對於當前MIDlet目錄下的相對路徑（如resources/pic.png）。
System類和Runtime類：
1. 在CLDC的簡表MIDP中定義一些J2SE中沒有的系統屬性（見表2.5）。通過getProperty()方法可以獲得指定的屬性值（String config = System.getProperty("microedition.configuration")）然而，CLDC沒有實現J2SE中的類java.util.Properties。這就意味著，不能通過getProperties( )方法獲得全部系統屬性列表。而且應用程式不能利用setProperty()或setProperties()方法定義自己的屬性。原有的通過JNI連線native code的方法由於JNI的不支持也都被省掉了。其中，如果支持多個簡表，中間用空格區分。
59) 名稱
60) 含義
61) 值
62) microedition.platform
63) 主機平台或設備的名稱
64) 默認值為null
65) microedition.encoding
66) 默認編碼格式
67) 默認值為“ISO8859_1”
68) microedition.configuration
69) 所支持的配置版本
70) 默認值為“CLDC-1.0”
71) microedition.profiles
72) 所支持的簡表名稱
73) 默認值為null
系統屬性列表
2. J2SE中最常用的常量err和out仍然被System類保留了，但是常量in被刪掉了。所以CLDC中沒有標準的輸入數據對象了。
4. 由於設備的記憶體限制，J2ME中gc()的使用率比J2SE高出很多，但是其本質和J2SE並沒有區別，垃圾收集的工作全權由系統負責。另外在J2ME中使用gc()時要找準時機。
Thread類和Throwable類：
CLDC要求虛擬機必須支持多執行緒，即使底層平台並不支持。J2SE中對多執行緒的定義——Tread類、關鍵字synchronized、對象的wait()、notify()和notifyAll()等方法都納入了CLDC規範。然而，CLDC並不支持執行緒組，也沒有提供TreadGroup類。
還有一些和J2SE的Tread類不同的地方是：
1. 執行緒不能自己取名，即getName()和setName()方法在CLDC中不予提供。
2. 刪除了resume()、suspend()和stop()方法。這些方法在J2SE中已經是不在推薦使用的了（depredated）。
Public void run() {
While (!threadStopped){
//the actions in the thread
}
}
4. dumpStack()方法被去掉了，類似的操作會拋出異常。
錯ki/%E9%A1%9E%E5%9C%96 target="_new" class=innerlink>類圖表2.3中可以看到，CLDC中大多數的異常類是在java.lang包中定義的，而錯誤類僅僅3個。這些錯誤類和異常類都和J2SE中的相同。特別需要注意的是Throwable類中的printStack()方法。該方法的輸出格式由虛擬機的實現自行規定；特別是在Sun的實現KVM中，該方法僅僅會把異常的名字列印出來。
6.2 java.util包
集合類：
CLDC 的java.lang包中的類及類的繼承關係
CLDC 的java.lang包中的類及類的繼承關係CLDC規範中包含了4個集合類：Hashtable、Stack、Vector和Enumeration。和J2SE相比，它們的功能被大大削減了，這點從繼承關係上就可以看出：J2SE中的集合框架被取消了，它們都直接從java.lang.Object類直接繼承。
Date類：
CLDC的Date類比J2SE要簡單的多。Deprecated 構造函式和方法都被除去了；多個Date對象的比較方法只能用equals()來進行。因此，我們不能直接通過Date對象獲得時間(日期)的一部分，如年、月、日等。這些功能僅在Calendar類中有定義。
TimeZone類：
CLDC規範規定設備只需要支持其默認的GMT時區。在KVM的實現中，支持GMT和UTC兩種時區表示。
Calendar類：
Calendar cal = Calendar.getInstance();
TimeZone timezone = new TimeZone();
Calendar cal = Calendar.getInstance(timezone);
Date date = new Date();
Calendar cal = Calendar.getInstance();
cal.setTime(date);
Calendar類不能以字元串的形式返回年月日，因為CLDC沒有包含java.text包。在KVM的實現中，只能通過toString()方法獲得形如Sat, 9 Apr 2005 12:00:00 UTC的字元串。不同的虛擬機的實現可能會返回不同格式的字元串。
Timer和TimerTask類：
MIDP通過Timer和TimerTask類提供了一種實現簡單的多任務調度執行的方法，調度由一個專門的後台執行緒完成。其中，TimerTask 是用戶定義的需要被調度的所有任務的抽象基類。Timer 類在任務執行的時候負責創建和調度執行執行緒。這些調度由Timer類的schedule()和scheduleAtFixedRate()方法來完成，而run() 方法用來執行各個任務。此外每個 正在執行的任務必須能夠儘快的終止，因為每個 Timer 對象在同一時間只能執行一個任務。
schedule()和scheduleAtFixedRate()方法都可以通過指定任務的開始時間、延遲時間或者任務的持續時間來調度任務。兩者的區別在於，當某個任務因為某種原因出現一段時間的延遲後，之後所有由schedule()方法調度的任務都會順延；而之後所有由scheduleAtFixedRate()方法調度的任務會自動根據一個固定的頻率來調整。也就是說，在相同的一段時間內，如果用schedule()方法執行10次的任務，用scheduleAtFixedRate()方法調度可能會執行9次或是11次。
另外，TimerTask類提供了cancel()方法用於在任務執行的過程當中強行終止任務，該方法是從Runnable接口類繼承來的。一旦終止了該任務，那么它將退出任務調度。在任何時間調用cancel()方法都是有效的，即使該任務還一次都沒有執行過。
6.3 java.io包 CLDC的java.io包是J2SE的子集，只提供了相當有限的8位輸入/輸出功能。而且，一些抽象類，像FilerInputStream等，也被省掉了，原先從這些抽象類繼承的類直接從它們的父類InputStream和OutputStream繼承。這裡只表2.5給出了CLDC中java.io包中的類及類的繼承關係。
CLDC1.0 java.io包中的類及類的繼承關係對於CLDC，InputStream和OutputStream類是讀寫數據的唯一的途徑。無論是本地檔案或是網路連線的讀寫都要通過這兩個類來完成。一個典型的例子就是：MIDlet提供了本地存儲方式——RecordStore，它以位元組數組的形式存儲內容。MIDlet需要把要存的內容轉換成ByteArrayInputStream或是DataInputStream對象格式來儲存。同樣的，調用在javax.microedition.rms中操作RecordStore的API所返回的也是ByteArrayOutputStream或是DataOutputStream對象。
DataInputStream、DataOutputStream類在J2SE中是從FilerInputStream和FilerOutputStream繼承來的。CLDC中FilerInputStream和FilerOutputStream被省掉了，所以DataInputStream和DataOutputStream直接成為了InputStream和OutputStream的子類。DataInputStream類不能直接構造，要通過其他方法獲得。例如，通過javax.microedition. io.Connector中的openDataInputStream方法，這是CLDC通用連線框架（GCF）中從網路獲取數據流的最長用的方法。而DataOutputStream類可以直接構造，也可以通過如javax.microedition. io.Connector中的openDataOutputStream等方法獲得。
Reader和Writer類從java.lang.Object繼承，基本上與J2SE區別不大。它們的作用是提供有限的國際化支持。J2SE中這是通過Reader和Writer對象實現的，而CLDC中使用了InputStream和OutputStream來完成同樣的功能。
InputStreamReader類用於把8位的輸入數據流轉化成unicode碼。然而，在CLDC規範中僅要求設備支持自身默認的編碼格式，其他的編碼格式可以有選擇的支持。CLDC也不提供可以在運行時把應用程式的編碼自動轉成設備默認編碼格式的功能。系統支持的編碼格式可以從系統屬性microedition.encoding中獲得。如果系統不支持指定的編碼，會拋出UnsupportedEncodingException異常。需mark()和reset()方法；而J2SE中的getEncoding()方法被去掉了。
和InputStreamReader類似，OutputStreamWriter類中也去掉了J2SE中的getEncoding()方法。
PrintStream類直接從OutputStream類繼承，不支持浮點數據的列印。同時需要注意的是，print()和println()不會拋IOException，需要用checkErro()方法查看錯誤狀態。
CLDC的java.io包提供的IOException及其4個子類都和J2SE相同，這裡就不再說明了。
6.4 javax.microedition. io包
CLDC1.0 類及類的繼承關係