最近在我的J2ME項目中，我想把JSR75的FileConnection類包裝成類似J2SE中的File類來對文件進行操作，所以研究了FileConnection類的行為和在不同機器上的實現，以尋求最小的功能集合。之所以要抽象出一個File類，是因為我想將來用RMS模擬出一個文件系統。

這個File類能夠通過簡單的構造函數File(String path)來創建，并且提供部分FileConnection的功能。當然更重要的是提供簡單的讀寫函數read(byte[] data),write(byte[] data)和獲得InputStream，OutputStream。于是，接下來就要研究一下對于同一個文件，不同的操作系統，能夠同時打開多少個FileConnection和多少個輸入輸出流。

在這之前，還有一個不能忽視的問題。J2ME系統對一些敏感的API進行了安全保護，沒有簽名的MIDlet如果要訪問這些受保護的API，系統將會暫停當前程序并給用戶一個提示，并由用戶選擇是否允許不受信任的程序訪問這些API。

有些系統，如Moto和Siemens，對于FileConnection的訪問可以選擇只在第一次調用的時候詢問，之后直到程序退出，都不會再向用戶發出詢問。也就是用戶的選擇可以在當前的整個會話Session中有效。

而對于目前相對主流的Symbian S60 v3系統則不是，每次調用FileConnectionAPI都會發出詢問（沒有"Session有效"的選項）。如果軟件中有很多對文件的操作，不斷彈出的系統提示必然會影響用戶體驗。想完全回避這些提示的唯一方法就是對軟件進行簽名。但是在S60 v3的系統下，對于我們開發者來說，想要簽名一個MIDlet并且被系統承認幾乎是不可能的。因為S60 v3系統中內置根證書簽發機構的證書費用都非常昂貴，一年要上千美刀。

對于S60系統，我們能做的可能就是在軟件中盡量少的出現這種系統提示，這就需要知道系統到底在調用FileConnection什么方法時才會彈出提示。于是我寫了幾行代碼進行了測試。

在S60 v3 模擬器和Nokia E70上運行后得出，所有的安全提示只會在執行Connector.open方法時才會出現，FileConnection對象返回以后，調用它的任何方法都不會再出現提示。在Connector.open中如果用只讀的方式創建FileConnection只會出現一次提示，如果用讀寫方式，則會連續的出現兩次提示（一次讀確認一次寫確認）。在Moto的模擬器上測試，只讀和讀寫方式分別只彈出一次提示，并且可以Session有效。

下面我又寫了幾行代碼，測試了對于一個物理文件來說，可以同時創建多少個不同的FileConnection，獲得多少個不同的InputStream和OutputStream。在WTK，S60 v3模擬器，Moto模擬器上測試，結果如下：

Moto模擬器和WTK的結果完全一樣，懷疑Moto的是基于WTK的（很多地方他倆都很相似）。

OOM：一直跑到系統拋出OutOfMemory錯誤（我機器內存小啊），實際系統支持的最大數量無法測到，不過肯定是夠用了。

軟環境：JRE6.0+Windows Server 2003

這樣的結果真是奇怪，反正最終得到，在S60 v3的機器上，一個文件只能且僅能通過同一個FileConnection對象得到一個InputStream和一個OutputStream。

另外，對于從Jar壓縮包中讀取文件，用getClass().getResourceAsStream(String path)得到InputStream，在所有測試平臺上都是OOM。

由于WTK是建立在PC上的，它的J2ME實現有時候過于強大，功能太完善，往往迷惑了我們的眼睛。把程序拿到其他模擬器甚至是機器上，很多東西就不是那么回事了。要小心啊。