元數據封裝：為何選 MANIFEST.MF？
- JAR 規範指定
META-INF/MANIFEST.MF 為應用專用元數據標準位置。
- 效率高：位於 JAR 頭部，掃描只需讀取前幾百位元組，無需解壓整個 JAR (XML 需解壓) 或解析位元碼 (Annotation 需載入類別)。
- 可讀性佳：文本格式，優於編譯後的 class 檔。
- 行長度限制 (72 字元) 手工編寫較繁瑣，**建議用工具生成**：Bnd、Maven Bundle Plugin、SpringSource Bundlor。
- 工具支援註解驅動：Bnd 實驗性支援
@Export 等源碼註解，兼得便利與效能。
後期綁定：服務註冊表模式
問題：介面解耦提供者與消費者，但誰負責「注入」實作？
- 傳統 DI (Spring/Guice) 傾向建立**中央化配置 (God Class/God XML)**，耦合所有模組，脆弱難維護。
- OSGi 方案：**去中心化服務註冊表 (Service Registry)**。
- 提供者發布服務 (介面 + 實作) 到註冊表。
- 消費者查詢註冊表獲取服務參考。
- 註冊表為中性共享黑板，**不掌握全域知識**。
- DI 框架仍有用：模組內部組裝、將物件發布為服務、注入其他服務。**多 DI 框架共存** (同一應用同時用 Spring 和 Guice) 成為可能。
- 註冊表提供低階 API，上層可建構更高階抽象。
總結：複雜性的必要性
OSGi 的每一分複雜性，都是為了解決模組隔離、版本管理、動態更新、服務發現等**真實工程難題**而演化出的最簡方案。若從零設計模組系統，邏輯必然指向 OSGi。
已知不足與應對
- 版本號語義約定 (主.次.修) 依賴開發者自律，第三方庫常不遵守 → 需更完善工具輔助版本相容性分析。
- 傳統庫假設扁平 Classpath (用字串載入類別、
Class.forName()) → 在模組化環境失效。策略：片段 Bundle、動態導入、或包裝適配器，不破壞模組邊界。
