本文介紹了OSGi的概念、特點、例子，以及如何使用NetBeans6與Knopflerfish（OSGi的一個RI）來進行OSGi開發(fā)一個入門程序——HelloOSGi。在介紹的部分里，轉(zhuǎn)載了一些網(wǎng)絡上OSGi的帖子，未能全部提及其出處，請作者見諒！

關(guān)于OSGi的介紹

一. 什么是OSGi？

OSGi是Open Service Gateway Initiative的簡稱，該組織建立于1999年，是一個非贏利機構(gòu)，旨在建立一個開放的服務規(guī)范，為通過網(wǎng)絡向設備提供服務建立開放的標準。

     OSGI 規(guī)范包括了構(gòu)建開放的可交付網(wǎng)絡服務的各方面，OSGI規(guī)范又包括了以下子規(guī)范：

     ◆  Framework規(guī)范(OSGI核心，提供一個安全的可管理的Java Framework來部署可擴展的Java服務。)

     ◆  Package Admin Service規(guī)范（來管理不同的Bundle之間的引用關(guān)系。當Bundle更新或者反安裝時判斷是否有其他的服務正在使用當前的Bundle）

     ◆ Start Level規(guī)范(定義了啟動和停止一個OSGi Service Platform時，不同的Bundles的啟動或者停止的先后順序)

     ◆ Permission Admin Service規(guī)范（Bundle是否許可執(zhí)行另外的Bundle的代碼）

     ◆ URL Handlers Service規(guī)范(怎樣注冊URL Schema，如何將java.io.InputStream對象轉(zhuǎn)換為特定的Java對象)

     ◆Log Service規(guī)范

     ◆Configuration Admin Service規(guī)范

     ◆Device Access Specification

     ◆User Admin Service Specification

     ◆IO Connector Service Specification

     ◆Http Service Specification

     ◆Preference Service Specification

     ◆Wire Admin Service Specification

     ◆XML Parser Service Specification

     ◆Metatype Specification

     ◆Service Tracker Specification

     ◆Measurment and State Specification

     ◆Position Specification

     ◆Execution Environment Specfication

OSGI Framework

    Framework是OSGI Service Platform規(guī)范的核心組成部分。它提供了一個通用的、安全可管理的Java framework。通過這個Framework可以支持一種叫做bundles的Service application的部署和擴展。

    OSGI兼容設備可以下載并且安裝OSGI bundles，也可一當他們不再需要的時候刪除。bundles安裝后會注冊一定數(shù)量的Services,并被由同一個Framework下的其他bundles使用。

    在一個動態(tài)擴展的的 OSGI環(huán)境中，Framework管理bundles的安裝和更新。同時也管理bundles和Services之間的依賴關(guān)系。

    Framework提供給bundle開發(fā)者必須的資源來在Java平臺上開發(fā)，為開發(fā)的bundles提供了代碼動態(tài)加載的功能, 也使得開發(fā)者開發(fā)、部署一個大規(guī)模的Services變的很容易。

    其次，Framework為Java bundle開發(fā)者提供了簡明一致的編程模型。簡化了開發(fā)部署的復雜性。這個編程模型允許開發(fā)者將自己的接口規(guī)范綁定到OSGI環(huán)境中的Service。 The selection of a specific implementation, optimized for a specific need or from a specific vendor, can thus be deferred to run-time.

    一個一致的編程模型幫助開發(fā)者可以應付一些可估計的危急錯誤。Framework將會運行在不同的硬件環(huán)境上，但一致的接口確保軟件組建可以運行在一致的服務接口上。

The Bundle Object

  對于每一個安裝在OSGI Service Platform的bundle都有一個與之關(guān)聯(lián)的bundle object。一個bundle對象用來管理bundle的生命周期。這項工作通常由Management Agent來做。

Bundle State

bundle有以下狀態(tài);

INSTALLED – The bundle has been successfully installed. Native code clauses must have been validated.

RESOLVED – All Java classes that the bundle needs are available. This state indicates that the bundle is either ready to be started or has stopped.

STARTING – The bundle is being started, and the BundleActivato r. start method has been called and has not yet returned.

STOPPING – The bundle is being stopped, and the BundleActivato r. stop method has been called and has not yet returned.

ACTIVE – The bundle has successfully started and is running.

UNINSTALLED – The bundle has been uninstalled. It cannot move into another state.

二. OSGi的特點

1、JRE版本無關(guān)性。雖然Java一直被人們認為是“Write Once, Run Anywhere”，但對于許多大型項目并非如此，常常因為不同JRE之間的一些小差別而花費巨大，被人們戲稱為“Write Once，Debug Anywhere”。OSGi首先希望能消除這種無關(guān)性，因此它提供給人們一個比JRE更穩(wěn)定的承諾。

2、嵌入式設備的開發(fā)平臺。OSGi創(chuàng)立之初的方向是瞄準了J2ME，可以看到委員會成員多數(shù)都不是軟件企業(yè)。倒是Moto和Nokia這類企業(yè)非常熱心。

3、高于package的完整的組件形式，還包括自從有組件開發(fā)以來一直困擾人們的組件版本問題。（這個可不是jar包啊，jar包只是bundle的一種實現(xiàn)-方式。）

4、推遲發(fā)生的依賴關(guān)系。當組件A（例如含有菜單的窗體）依賴于組件B（例如菜單所表達的一個功能）時，在語言級上必須先有B再有A，但顯示中往往是先有A再有-B，所以OSGi為它們提供一種運行時后綁定的機制。

5、新的軟件架構(gòu)。OSGi幾乎每個成員都是其所在領(lǐng)域的TOP，這些領(lǐng)域也都是在未來的數(shù)十年中軟件大行其到的地方，軟件商們（比如IBM）希望這些領(lǐng)域的軟-件架構(gòu)能夠統(tǒng)一一些，甚至是組件可以通用。

OSGI典型的應用案例

一. OSGi: Eclipse的根基

OSGi為網(wǎng)絡服務提供了一套標準的, 面向組件的規(guī)范. 而網(wǎng)絡服務又是SOA(Service Oriented Architecture)的基礎. 使用OSGI平臺, 就可以很輕松的管理軟件組件的生命周期, 這組件是可以位于網(wǎng)絡中的任何設備上, 而且組件可以動態(tài)的安裝, 加載, 升級和卸載, 而不用終止和重啟設備. 這里的組件是指程序庫或者是應用程序, 它們又可以動態(tài)的使用別的庫和程序。

        其實OSGi原本是為了解決家庭網(wǎng)絡或者嵌入式設備由于本身的限制(CPU, 內(nèi)存, 帶寬等)而出的一個解決方案, 是一個輕量級的框架. 但現(xiàn)在OSGi已經(jīng)遠遠的超過了它的原來的的功能. OSGi已經(jīng)應用于移動通訊, 汽車, 電信, 嵌入設備, PC桌面和服務器等眾多領(lǐng)域. 由于它的開放和簡單的風格, 吸引越來越多的著名公司加入, 使OSGi也愈加強大和開放。

        我不了解OSGi在其他領(lǐng)域的應用, 只是由于要使用Eclipse, 所以也只對OSGi在PC桌面方面的應用做了些熟悉和了解. 和OSGi一樣, Eclipse也是個開放的平臺, 它的基礎就是OSGi服務平臺(Services Platform), 架構(gòu)在OSGi上的Eclipse具有融合其他應用和組件的能力, 使不同的組件能夠運行在一個JVM(Java Virtual Machine)上, 使它們之間能夠協(xié)同工作, 占用較少得內(nèi)存和CPU時間, 而且能夠由平臺管理組件的全生命周期的活動, 可以說一切都在控制之中。

        在OSGi中, 每個具體的組件都要繼承于Bundle, Bundle是個接口, 定義了安裝, 升級, 卸載, 啟動, 停止等操作. 其實, 在Eclipse中, 插件(即上面所說的組件)并不是從Bundle繼承的, 而是從另外一個重要接口BundleActivator繼承的. 后者只有兩個接口函數(shù)-Start和Stop. 從它的名稱就可以看出, 它其實是一個控制Bundle的類. 在Eclipse中有大量這樣的應用, 一個類負責提供接口滿足不同的需要, 而有另外一個類負責操作這個類. 比如IWorkbench和WorkbenchAdvisor, IWorkbenchWindow和WorkbenchWindowAdvisor等, 這樣可以避免客戶直接和核心類打交道, 也減輕了客戶的負擔。

        在Eclipse中, 組件都是以Plugin形式存在的, 幾乎每個組件都要有一個類實現(xiàn)(繼承)Plugin類(也有例外), 一般都是由Plugin來控制服務的加載和卸載, 因為Plugin繼承于BundleActivor. 除了Bundle, BundleActivor外, OSGi也提供了BundleEvent, BundleListner等接口. 這些比較簡單。

        另外一個重要的接口是BundleContext, 該接口提供了一個Bundle所需要的上下文環(huán)境, 一個Bundle對應一個BundleContext, 當Bundle停止(Stop)時, 它也就銷毀了. BundleContext提供注冊服務工廠(ServiceFactory)的接口, Bundle可以注冊一些服務工廠接口, 這樣其他的Bundle就可以通過實現(xiàn)這些接口達到擴展的目的. 在Eclipse中對應的概念是”擴展點(IExtensionPoint)”和”擴展(IExtension)”. Bundle之間的交互是非常重要的, 利用這種技術(shù), 就可以將很大的項目分成多個Bundle, 然后搭積木就可以了。

        eclipse 3.0并沒有用OSGI替換掉原來的PlugIn機制。它只是做了與標準兼容的工作：給用戶提供了一系列的API來訪問，在這個過程中，就必須要做一些改 變(比如plugin registry和loading機制)來同OSGI標準完全兼容。最初的Plugin核心只支持靜態(tài)的擴展，就是說，如果要改變一個已經(jīng)存在的Plug 就必須重啟core,也就是要退出Eclipse并重啟。

        有很多人問Eclipse為什么要兼容OSGI規(guī)范而不是其他的規(guī)范呢?

        在Eclipse被捐贈出來以前，Eclipse由OTI來開發(fā)，其目標是開發(fā)一個嵌入式Java軟件的開發(fā)平臺?；ヂ?lián)網(wǎng)上現(xiàn)在仍然由很多的連接指向 Visual Age Micro Edition (VAME). 這也是SWT被構(gòu)思的一個原因，他們想將SWT使用在嵌入式設備中的用戶界面。這種淵源關(guān)系解釋了當時為什么選擇OSGI規(guī)范。

        另外一個原因是除了OSGI沒有其他的規(guī)范。OSGI規(guī)范在輕量級服務架構(gòu)應用方面被廣泛的支持。而且OSGI被好多電信業(yè)的知名公司和一些其他行業(yè)的知名公司所支持。他們需要使用OSGI來同Sun的J2ME來抗衡。

二. BMW汽車的應用控制系統(tǒng)

BMW汽車的應用控制系統(tǒng)采用OSGI作為其底層架構(gòu)，估計這一定程度上顛覆了很多人對于Java的認識，很多人都認為基于java的系統(tǒng)低效，不可能用 于汽車這樣的應用控制系統(tǒng)上，在EclipseCon 2006會議上BMW采用OSGI得到了證實，估計是猜想會被很多人懷疑，演講者在PPT上講了下BMW汽車的應用控制系統(tǒng)，這套系統(tǒng)主要用來控制汽車上 的音箱、燈光等等設備，總共由1000多個Bundle構(gòu)成，但BMW汽車的應用控制系統(tǒng)啟動時間卻只需要3.5秒，是不是很令人驚訝呢，這也從很大程度 上反應了采用OSGI的系統(tǒng)的效率并不會低。

這兩個非常成功的案例向大家證明了基于OSGI開發(fā)系統(tǒng)的可行性，同時這個兩個成功案 例的足夠的知名性以及優(yōu)秀的使用、技術(shù)效果也為OSGI的推廣鋪設了不錯的基礎，到目前為止，關(guān)于OSGI被商業(yè)領(lǐng)域（例如IBM P5服務器系列、Websphere V6.1、Lotus Sametime、Adobe CS2等）、知名開源軟件領(lǐng)域（例如Apache等）采用的消息已經(jīng)是不斷的傳出，可以看出OSGI在服務器端應用、企業(yè)應用中已經(jīng)開始廣泛流行了，而這 對于OSGI更好的發(fā)展成為支撐服務器端應用和企業(yè)應用的規(guī)范會起到很好的推動作用。

OSGi與類似技術(shù)的討論

一. OSGi與JMX

JMX 本來設計的用途就只為了管理，我們不該把他拿來 (over use) 作為開發(fā)應用程序的組件 (那是 EJB 或 JavaBeans 該做的事)。但 OSGi 卻可以!

JMX 多數(shù)用于 server 系統(tǒng)中，而 OSGi 卻不限于所開發(fā)的應用程序。你可以用它開發(fā) embedded 系統(tǒng)、desktop 程序，甚至是 server 程序。

OSGi 不但提供了與 JMX 相似的容器管理能力，甚至它本身就是一套精密的 Framework。OSGi 采用Micro-Kernel 的架構(gòu)，可以提供無限延伸的功能。OSGi 的 Bundles 在線更新功能、以及應用程序之微量內(nèi)存執(zhí)行能力，都是開發(fā)應用程序的利基。

行 文至此，又覺得 OSGi 與 JCA、JNDI 都有一些功能重迭及互補之處。只是 JMX、JCA、EJB、JNDI都經(jīng) JCP 標準，都屬于 J2EE 家族成員，但 OSGi 過去屈居于 Embedded System，聲名就不若前述標準響亮...。我覺得這完全是兩種思維模式：J2EE 的思維是 build on large scale，OSGi 的思維是 build on dynamic scale。OSGi 以小搏大。

為什么要用osgi，我認為主要是因為java至今沒有出 現(xiàn)一個方便易用的組件配置模型。過去，JMX、ClassLoader、reflect都似乎可以做這個事情。但是，JMX太麻煩了，況且原本為J2EE 準備的JMX，確實不太易用，走專用的協(xié)議，需要專門的客戶端，需要adapter來訪問等等....

而ClassLoader，單獨用ClassLoader，需要自己在其上構(gòu)建一層包裝，否則用起來很麻煩。Reflect的配置方式和ClassLoader一樣的問題 。

但是，所有java的組件配置方式，包括使用classloader的osgi在內(nèi)共有的一個問題就是，被替換組件的回收時間無法控制。

二. OSGi與SCA

OSGi和SCA到底能有什么關(guān)系呢，確實，至少從現(xiàn)有的OSGi規(guī)范以及SCA規(guī)范分別來看，兩者沒有直接的關(guān)聯(lián)，由于OSGi規(guī)范是對于嵌入式領(lǐng)域的 軟件而制定的，其特別注重軟件的動態(tài)性的支持，而SCA規(guī)范是對于企業(yè)應用領(lǐng)域的軟件而制定的，并且是基于SOA的，其特別注重對于企業(yè)應用而言的基礎設 施的實現(xiàn)，同時又盡量的去屏蔽對于SCA容器使用者而言SOA帶來的技術(shù)實現(xiàn)細節(jié)的難度；但根據(jù)OSGi規(guī)范以及SCA規(guī)范，同時又能發(fā)現(xiàn)兩者有個共同希 望解決的問題，那就是規(guī)范的模塊化，這是OSGi規(guī)范和SCA規(guī)范中的一個共同目標。
在規(guī)范的模塊化上無疑OSGi占據(jù)了優(yōu)勢，OSGi規(guī)范詳細 的定義了作為OSGi框架應該如何去實現(xiàn)以支撐規(guī)范的模塊化，同時也定義了應該如何規(guī)范的來建設模塊，而在SCA規(guī)范中只定義了如何規(guī)范的來建設模塊，并 未定義如何規(guī)范的來實現(xiàn)SCA容器，既然是這樣，SCA規(guī)范是否可以考慮直接使用現(xiàn)有的好輪子---OSGi作為SCA容器實現(xiàn)的基礎呢，在使用OSGi 的情況下，SCA容器就沒必要費勁就考慮怎么樣實現(xiàn)自己規(guī)范的模塊化了，這個就有點象當年的Java Module System規(guī)范，除非SCA小組能夠有突破性進展的實現(xiàn)規(guī)范模塊化的方法，那另當別論。
使用OSGi的話自然的就給SCA帶去了一個好處，那就 是動態(tài)性的支持上，這是OSGi的核心也是最大的優(yōu)勢，Peter在他最新的blog中也提及Module Layer是OSGi規(guī)范中最為關(guān)鍵的部分，正是因為Module Layer才使得OSGi其他部分得以搭建。
當然，基于OSGi去實現(xiàn)SCA容器必然會碰到這樣那樣的技術(shù)難題，這可以依靠OSGi框架的實現(xiàn)者們和SCA容器的實現(xiàn)者們來協(xié)作的解決，就像Spring and OSGi。
那 么對于OSGi而言呢，基于OSGi去實現(xiàn)SCA容器又會給OSGi帶來什么好處呢，其實非常明顯，在這樣的情況下OSGi就真正的進入了企業(yè)應用領(lǐng)域， 真正的成為了以后企業(yè)應用領(lǐng)域的核心基礎，所以我在之前的blog中說過，SCA非常象是OSGi在企業(yè)應用的延伸或擴展形成的規(guī)范。
當然，要做 到上面所說的，不僅僅是想就有用的，需要去努力做到，近期準備發(fā)封mail先試探著問問OSGi EEG們對于SCA有什么想法，是否可以考慮直接讓SCA變成OSGi EEG的規(guī)范，同時讓SCA規(guī)范制定小組納入OSGi Core作為SCA容器實現(xiàn)的規(guī)范的部分。

ps：近期Spring and OSGi的進展非常可喜，現(xiàn)在Spring and OSGi的project已經(jīng)提升為了正式的project，而且在提升之前也對外正式公布了Spring and OSGi的repository，Spring and OSGi project的網(wǎng)站地址位于：
http://www./osgi

三. OSGi與JSR 277的爭論

JSR 277（Java 模塊系統(tǒng)）與OSGi（JSR 291）的爭論再次變得白熱化，JSR 316（Java EE 6）的提交又一次引燃了關(guān)于OSGi與JSR 277互相重疊的爭論。InfoQ整理總結(jié)了其中的若干觀點和論據(jù)。

Peter Kriens寫了一篇博客文章討論Java EE 6中對Profile的使用，并展示了如何用組件結(jié)構(gòu)來代替模塊系統(tǒng)作為Java EE 6的基礎。Kriens還質(zhì)疑了Java EE 6規(guī)范中對JSR 277的使用，他說：

JSR 316僅僅在規(guī)范的需求部分，以一種相當間接的方式提到了JSR 277。大致上是說JSR 277正在制定中，他們將推遲任何決定，直到JSR 277完成?？瓷先ヮH有道理，因為從編號上看277比291更老也更成熟？但實際上，277仍然處在草案復審階段，而291已經(jīng)最終發(fā)布，因為291的基 礎是從1999年發(fā)布至今，已經(jīng)經(jīng)過4個主要修訂版的非常成熟的OSGi規(guī)范。那么，應該有別的理由不提JSR 291吧？也許277提供了291缺少的特性？嗯，沒有。從JSR 277規(guī)范的需求看，誰也沒法說它的目標比JSR 291/OSGi更加遠大：沒有動態(tài)、沒有類空間一致性、沒有卸載、沒有包引用等等。277的初步草案仍然處在一種過于簡單化的程度。即便是277唯一比291強的Repository，也仍然有許多晦澀不明之處。JSR 277最近開放了郵件列表， 從里面的討論中可以看出，似乎他們?nèi)匀槐灰恍┗镜哪K性問題所困擾。不過，幸運的是，JSR 277專家組已經(jīng)承諾讓277的模塊系統(tǒng)與JSR 291/OSGi互操作。這就消除了選擇OSGi的最后一絲風險，更不用提今天就可以在各種VM（從1.2到6，以及嵌入式設備）上運行OSGi的額外好 處，而JSR 277只能運行在2008年下半年才會發(fā)布Java 7上。那么，為什么JSR 316要停下來等？我們已經(jīng)有一個完美的方案，而且JSR 277承諾將會兼容？

Alex Blewitt也質(zhì)疑了Java EE 6選擇JSR 277的決定：

提交的草案聲稱：

為了更好地支持這個平臺在擴展性方面的目標，應該有一個更加寬泛的模塊概念。這項工作正由“JSR 277——Java模塊系統(tǒng)”展開，它的目標是Java SE 7。我們預期Java EE 7將建立在這項技術(shù)的基礎上，因此我們將推遲任何可能與將來的版本沖突的技術(shù)規(guī)范。

也就是說，他們選擇了JSR 277而非JSR 291，并且拒絕在JSR 277隨Java 7發(fā)布之前考慮任何其它選擇。

InfoQ也詢問了Eric Newcomer是否認為SUN應該接受OSGi：

絕對應該，絕對合理。更重要的問題是關(guān)于Java的未來，關(guān)于SUN是會擁抱OSGi還是繼續(xù)對抗，如果他們繼續(xù)對抗OSGi，對Java又會有什么影響。根據(jù)我最近有限的OSGi經(jīng)驗來說，它在許多方面都給Java帶來了顯著的改進——模塊性、版本、增強的類裝載。

Sun 投票反對JSR 291，不過JSR 291仍然獲得了通過，正式成為JSE的一部分。不過這已經(jīng)表明了Sun的立場。JSR 277是由Sun提案的，內(nèi)容是Java模塊性，這看起來明顯跟OSGi重疊。Sun有過很好的機會擁抱OSGi并以之為基礎構(gòu)造Java 7，不過，雖然沒有正式的聲明，但看上去他們更傾向于重復OSGi的工作而不是擁抱OSGi。

我期望Sun能盡快理性地對待OSGi。不過，也許Sun繼續(xù)站在OSGi的對立面反而更好，因為至今OSGi都發(fā)展得很好。

Hani Suleiman，JSR 291專家組的成員之一，對這場爭論有不同看法。在回答關(guān)于JSR 277和OSGi有什么共同基礎時，他說：

[……]JSR-277（在某種程度上）是一個共同的基礎。它從JDK這一面著手解決問題，這讓OSGi和其他類似方案（Maven、Ivy等）的任務變得更加容易。組件包（Bundle）/模塊成為JVM層次的一等公民。

除此之外，（OSGi或其它）框架可以按照自己的意思添加任何增值功能。277并沒有限制。OSGi支持者們感到不高興只是因為基礎標準用的不是他們的實現(xiàn)，而且還考慮了很多其它方面的東西。

用Hibernate來打比方，請想象這樣的情形：JBoss一直攻擊JPA規(guī)范，說它是重新發(fā)明輪子，所有人都應該把Hibernate當作標準。這就是OSGi支持者們正在做的。

其他人，如Neil Bartlett，也就JSR 277專家組的討論內(nèi)容提出了他們的擔心：

請看看JSR 277的專家組郵件列表，它已經(jīng)向公眾開放（雖然是只讀的）。從這些討論來看，很難認為他們有傾聽兩位OSGi專家（Glyn Normington和Richard Hall）的意見。在JSR 277草案的規(guī)范定義和應用舉例中，有很多地方跟OSGi是不可調(diào)和的：Sun拒絕學習任何OSGi/JSR 291的經(jīng)驗。

OSGi支持者們并不是因為我們最中意的模塊系統(tǒng)沒被選中就大發(fā)牢騷。這太孩子氣了。我們鼓噪是因為原則問題，JSR 277這個模塊系統(tǒng)正在邁向失敗！如果在JVM里綁死了一個殘缺的模塊系統(tǒng)，這會給整個Java社區(qū)造成巨大的破壞。

Chris Custine從另一個角度看這場爭論的起源：

我認為Sun和OSGi的激烈沖突純粹是關(guān)于控制權(quán)和許可證的政治斗爭。根本和技術(shù)無關(guān)！Java社區(qū)的政治又一次無視了每個理智的人都具備的常識和邏輯。我一向非常期待Java能夠再次復興它在創(chuàng)新和進化上的能力，但正是這些東西讓我擔心……

Glyn Normington，JSR 277專家組成員和JSR 291的規(guī)范帶頭人，試圖謹慎地表達他的觀點。除了兩者的特性對照，Normington還就爭論中涉及的問題寫了一篇詳細的介紹。他解釋說“這兩項JSR的目標是非常不同的，雖然背后的概念很接近。JSR 277和294是在Java SE平臺之中加入基本支持；而JSR 291是純Java的，它建立在Java平臺之上”。

Normington認為在JSR 277中重用OSGi并不容易，他也討論并推翻了放棄JSR 277的想法，最后提出了他認為最合適的解決方案：

最佳方案很清楚：JSR 277應該接受JSR 291，為此應該在JSR 294里加強語言和VM上的支持，并且加入JSR 277的Repository架構(gòu)。這樣可以讓JSR 277的進程提前數(shù)年，還保證了JSR 277和JSR 291之間完美的互操作性。

但要想實現(xiàn)這個最佳方案，需要Sun轉(zhuǎn)一個180度的大彎。也許，只是也許，Sun為了保證Java的成功，終究會做這件事。也許，只是也許，將來Java社區(qū)可以回顧今天，并且模仿丘吉爾的話說：“在窮盡了所有選擇之后，總是可以指望Sun做正確的事”。

社區(qū)里面對于什么是這個困境的最佳解決方案肯定也是爭論不休——您的看法呢？