OSGi 4.2將于8月發布 新版特性預覽
將于今年8月底發布的OSGi 4.2具有很多新特性，其中一些特性已經被Equinox（Eclipse背后的OSGi引擎）實現。
以下是OSGi 4.2核心的新特性：
◆標準的啟動框架，這會簡化OSGi系統的啟動過程而不管底層的實現如何（比如說可以通過變換類路徑用Felix替換掉Equinox）。
◆Service Hooks，憑借它OSGi bundle能夠攔截并過濾去往其他bundle的服務（這么做能夠進行安全檢查，諸如此類）。
◆Bundle tracker，它可以在bundle啟動和停止時對其進行監控。
◆增強的安全機制，這樣不管是肯定還是否定的許可都可以對授權機制進行定制。
◆標準的Bundle-License頭，這樣bundle就可以定義其協議需求以達到管理的目的。
OSGi綱要涵蓋了可能會出現的其他服務，它規定下一個發布要遵循著核心，但還會包括：
◆信息初始化，初始化信息可以存儲在bundle的清單中。
◆聲明式服務，現在BND已經支持聲明式服務了，同時消除了某些限制。
◆遠程服務，之前發布的OSGi（即RFC 119）通過遠程技術將不同VM之間的OSGi服務連接器來。Bundle的外部配置可以定義服務的連接方式。不像RMI那樣，這些服務無需checked exception（很明顯，如果發生了通信錯誤則會拋出RuntimeException）。這已被Eclipse的ECF及Felix CXF實現了。
◆Blueprint extender提供了一個配置驅動的服務模型（類似于聲明式服務）但卻基于Spring模式。未來，服務可以在啟動時實例化并綁定到代理上，之后還可以進行改變。
Enterprise OSGi服務也不甘寂寞，它將含有一個基于OSGi的Transaction API（基于JTA），通過OSGi服務提供JDBC與JNDI，同時還會借助于JMX管理OSGi系統。Enterprise OSGi的一個難題就是Web容器，容器應該可以將WAR安裝到運行著的OSGi系統中，正如Spring DM Server那樣。
還有幾個試驗性質的服務（并沒有定義在規范中），例如創建嵌套框架的能力（OSGi引擎可以在其上實例化另一個OSGi引擎來運行應用）以及TSL——一種基于shell的腳本語言，用于與OSGi服務進行交互并支持運行時命令。后者的目標是實現一個標準的shell以控制任意的OSGi引擎而不是針對特定系統的特定shell。像POSH和Pax-Shell這樣的系統已經開始使用TSL了。
OSGi中那些試驗性服務的試驗手段與JCP中定義的那些試驗性系統是有很大區別的，相對于花費很長時間來定義規范，然后再獲得其工作方式的反饋信息，RFC采取了不同的策略：首先提供臨時性的細節描述，然后采取多個實現（Felix、Knopflerfish及Equinox等等）來獲得其反饋信息，接下來根據反饋來精華規范直到其穩定為止而不是發布某些不確定的東西（與Java的發布形成了鮮明的對比）。在發布最終規范前有機會進行試驗并獲得反饋信息意味著未來的變化不太可能對最終規范造成嚴重影響。
該演講的一些結論與JSR 294的結果不謀而合。目前已經合并了很多需求和實現，由于JavaC處理元模塊系統方式的原因，有人提出改變Java中可視化（visibility）的工作方式（包括新引入的模塊keyword）。大家就元模塊的含義與keyword展開了激烈的討論。Sun工程師及Felix提交者Richard Hall說到：
就我來說，我很理解Peter的擔憂：我們定義的東西含義太不明晰了，這最終會毀掉Java的愿景：“編寫一次，到處運行”。定義東西時如果能具體一些就好了。
幸好JSR 294還有時間進行完善；最近關于JSR 294的眾多評論表明大家都希望能有一個解決這些問題的合理方案。
【編輯推薦】
