先月のOSGi DevCon in New Yorkで，OSGi Allianceは，OSGi Core Release 6をリリースした。2012年のOSGi R5と後方互換性を持つこのリリースは，Eclipse Lunaの一部としてEquinoxに実装されている。
仕様では新機能の一覧が更新されると同時に，いくつかのマイナーチェンジによる２つの新機能が加わっている。
Data Transfer Objectsは，OSGiフレームワーク内部のオブジェクトの状態を示す手段を提供するものだ。
Versioning Annotationsは，パッケージのバージョンと，インターフェースが参照用なのか実装用なのかを宣言するために使用する。
Native Namespaceは，汎用的なRequire-Capabilityの標準ネームスペースであるosgi.nativeを提供する。
Extension BundleActivatorsは，フレームワークの起動と停止にバンドルを関連付ける目的で追加されている。
Data Transfer Objectのルートクラスとして"org.osgi.dto.DTO"クラスが定義された。各サブクラスは，基底となるOSGiオブジェクトにマッピングされたパブリックな属性を数多く所持する。このオブジェクトは，プロバイダに依存しない方法でシステムのスナップショットを取得して，ネットワーク経由で遠隔地にデータをシリアライズするために導入された。DTOにアクセスするためには，所定のDTOタイプ名を指定して，基盤となっているフレームワークオブジェクトのadapt()を呼び出せばよい。
BundleDTO bdto = bundle.adapt(BundleDTO.class).
残念ながら，そしてデータオブジェクトにもかかわらず，DTOクラスはSerialise可能ではない。従って標準的なJavaの直列化メソッドは利用できないが，GSonなどのライブラリを使えば，ネットワーク経由で送信可能な形式に変換することは可能だ。オブジェクトの内容のデバッグ手段としてはtoStringメソッドを利用できるが，仕様が不明確であって相互運用に耐えるものではない。ただしリモート管理インターフェースを使えば，DTO仕様のメリットを活用してリモートOSGiフレームワークの状態を取得し，ユーザインターフェースを通じて確認することは可能だろう。
DTOインターフェースは読み取り専用のスナップショットを目的としたものなので，状況変化に応じてフレームワークを操作するためのメソッドや手段は用意されていない。
Versioning Annotationは，インターフェースがクライアントからの利用を意図したものか，あるいはクライアントで実装されるためのものかを識別する手段を提供する。"@ProviderType"でアノテートされたインターフェースは，クライアントが利用するためのものであって実装目的ではない。これはEclipseで使用されている"@noimplement"に相当する。実装を目的とするインターフェースは"@ConsumerType"でアノテートする。
これらのアノテーション(クラスファイルには保持されるが，実行時には参照されない)はツールで解釈され，意味的なバージョン番号に基づいて警告やエラーが報告される。"@ProviderType"でアノテートされたインターフェースは，メソッドを追加しても下位互換性が維持されるため，パッケージまたはバンドルのマイナー番号を更新するだけでよい。しかし"@ConsumerType"でアノテートされたインターフェースでは，メソッドの追加は互換性を損なう変更であるため，メジャー番号の更新が必要になる。
付加的な"@Version"というアノテーションもパッケージ内で参照されて，その内容が (package-infoファイル用に) パッケージレベルで保持される。ツールを使ってこれを処理すれば，適切なバージョン番号情報を生成することができる。
アノテーションはコアフレームワーク自体ではなく，osgi.annotationsという独立したJARファイルで提供される。これらのアノテーションを使用しようとするコードは，コアフレームワークの実装に代えてこのJARを追加する必要がある。アノテーションJARはバンドルではない(META-INF/MANIFEST.MFファイル内にExport-Packageヘッダを持たない)ので，依存性の結合にパッケージ名を使用するPDEビルドではクラス依存を解決できない。代わりにクラスパスの依存関係として追加するか，あるいはEquinoxフレームワークが行っているようにリポジトリにチェックインする必要がある。この記事の執筆時点では，Eclipse LunaではOSGi JARを利用できないので，EclipseユーザはJavaDocの@noimplementタグを引き続き使用する必要がありそうだ。
osgi.nativeネームスペースは，Require-CapabilityとProvide-Capabilityというエレメントをバンドル内にエンコードして，依存関係を正しく結ぶための手段を提供する。Bundle-NativeCodeヘッダに代わるのではなく，Bundle-NativeCodeで規定される制約をosgi.nativeの要件と規定に変換するためのものだ。
フレームワークにはExtensionBundle-Activatorという概念が加えられた。フレームワークの起動と停止にバンドルをフックするためのもので，フレームワークの拡張として (0}Fragment-Host: system.bundle;extension:=frameworkというように) 宣言されている。BundleActivator標準インターフェースを実装するバンドルだが，実質的にはフレームワーク拡張だ。
OSGi Core Release 6にはその他にも，既存のオブジェクトにいくつかのマイナーチェンジが加えられている。Frameworkクラスには可変数のFrameworkListenersを取得するinitメソッドが，FrameworkWiringにはfindProvidersメソッドが，それぞれ追加された。またフックの織り込み(weaving)を行うWovenClassListenerが新たに加えられている。
OSGi Core Release 6の詳細については，OSGi Webサイトの仕様を参照してほしい。OSGi Allianceではさらに，En Routeというツールチェーンを開発中である。InfoQでは近日中に，Peter Kriens氏から詳しい話を聞く予定だ。