Peter對于JSR 277是極度的關注，畢竟JSR 277和OSGi在實現的目標上具備了那么多的共同性，從98年開始，Peter就希望能加入JSR 277 JCP Group，但是被拒了，JSR 277基本完全是SUN在主導的，經過這么多年了，JSR 277的草稿終于是發布出來了，Peter在對JSR 277做了Review后特意寫了篇Blog做了評價，總結而言，Peter認為JSR 277 just like a toy,JSR 277并沒有吸取OSGi在這8年模塊化方面的教訓和經驗，在模塊的一致性校驗、可選性、分離包機制等等方面都缺少足夠的考慮，原文見：
http://www.osgi.org/blog/2006/10/jsr-277-review.html作為OSGi的主席，Peter在Java規范的模塊化和動態化絕對是具備足夠的發言權的，他對于JSR 277過分簡單的解決規范的模塊化的策略感到很遺憾，JSR 277采取的是一種類似OSGi Require-Bundle的機制來形成模塊，模塊在JSR 277中定義為以Module的形式來進行部署，對于Module的信息如(引用的模塊、對外暴露的包和資源文件等)則在MODULE-INF/METADATA.module中進行描述，每個標準的JSR 277模塊需要有一個Main類，在這個類中需要有一個Main方法，在觸發Main方法前，環境必須首先檢測此模塊所引用的模塊是否已OK，如沒有OK的話是不會啟動的，從這已經反應出了，JSR 277是不支持動態化的，在JSR 277中模塊不支持卸載，同樣，在運行期是無法改變模塊和加載新的模塊的，必須在停了VM后才能進行這些操作，OK，也許對于不是那么看重動態性的應用來講這點沒那么重要，但是JSR 277在規范的模塊化上做的實在是過于簡單，考慮欠周，為什么這么說呢？
按照Peter說的幾點來看看：
一致性校驗
JSR 277中模塊是通過直接引用其他的模塊來形成依賴的，但它僅僅以模塊名以及版本來構成依賴，并未去解決一致性的問題，這樣說很晦澀，舉例來說：
有A、B、C、D四個模塊：
A 引用 B 1.0，C 1.0
B 1.0?引用 D 1.1
C?1.0 引用 D 1.0
在JSR 277中這樣的情況下會出現A同時可看到D 1.0和1.1兩個版本下的類，自然就很容易產生沖突，這個相信大家早就對java中引用包沖突的現象恨之入骨了....
可選性
可選性這個顯然是因為JSR 277不支持動態性而形成的，Peter舉了個例子是這樣的：
一個類可被作為Ant Task、Eclipse Plugin等多種形式來運行，在JSR 277為了讓這個類可以被各種各樣的方式運行，不得不把相關的包全部導入，而在OSGi中則不需要，可以通過optional的方式來動態的去加載所需要的包，這點對于大型應用而言是比較重要的。
未提供包共享的機制
JSR 277不是采用包共享的機制來實現模塊之間的類的共享，而是通過模塊引用的方式來實現，這個帶來的問題很明顯，平白的去多引用了不需要的東西，而JSR 277采用模塊引用這樣的方式也讓我們看到JSR 277并沒有充分考慮如何實現模塊之間的互動。
Peter最后提及他非常不看好JSR 277，他覺得如果JSR 277能夠通過的話要么是因為各大廠商根本就不關心，要么就是因為SUN在這個規范中的主導地位。
上面幾點是Peter所言，個人認為JSR 277作為模塊化的規范，應該為模塊的定義、設計、開發、部署都做到足夠的考慮，而以目前JSR 277來看，在模塊通信機制、模塊管理上缺乏完整的定義，而這些是一個模塊化的規范中最為根本和重要的東西，而OSGi中則提供了Bundle contains multiple components,Service-Oriented Component Model以及強大的動態化的Bundle管理API來實現模塊的通信和管理，至少從目前看來，OSGi的設計思想仍然是模塊化設計系統的一種很好的指導思想。
ps: 在明年的Eclipse大會上將會專門有OSGi的專題部分，而且在看Eclipse 3.3的feature中可以發現Eclipse 3.3很重視對于基于OSGi開發系統更好的支持 :)