核心痛點：從「解決問題」到「蓋章通過」
Java Community Process (JCP) 曾是 Java 標準演進的核心引擎，但眾多開發者感覺其已淪為大廠利益的「橡皮圖章」：
- 規范制定由資金雄厚的大公司主導（IBM、Oracle/BEA、Red Hat 等）
- 小公司/個人開發者缺乏實質話語權
- 流程臃腫緩慢，「JSR 蛇行」成為共識
四大觀點深度剖析
觀點 1：小廠/個人邊緣化
「對於擁有良好產品的小公司意味著什麼？他們沒有資金能力將專有產品變為標準。」—— Walter Hurst (Wakesoft CTO)
- JCP 執行委員會（EC）席位傾向大廠
- 專家組成員多為大廠員工，小廠難以進入核心決策圈
觀點 2：非投票成員被邊緣化
「如果你不是投票成員，在很多決議上會受到限制。」—— Mukund Balasubramanian (Infravio CTO)
- 公開評論雖開放，但最終決策權在 EC 手中
- 文檔下載、專家組討論對非成員不透明
觀點 3：大廠政策傾向導致人才流失
- 大廠投入巨資爭取標準控制權（如 BEA 推 WebLogic 成標準）
- 開發者轉向 Apache 等開放社區（Struts、Log4j、Kafka 等皆源於此）
觀點 4：標準化依賴大廠/基金會背書
「獨立開發者必須獲得 Apache 等組織支持才能推動標準化。」
- 成功案例：Struts → JSP Standard Tag Library (JSTL)
- Apache 基金會提供中立治理、法律保護、社區運營
JCP 官方回應：Onno Kluyt (Sun JCP Program Office)
- 承認政治因素存在，但強調個人成員享有同等權利：可加入專家組、領導 JSR、競選 EC
- 舉例：Doug Lea (JSR 166 領導)、Jason Hunter (JSR 102)、Steve Emerson (JSR 108)
- 流程三階段投票：JSR 評審 → 社區評審 → 最終批准，旨在保證公正
社區聲音：呼喚「Java 方法請求」
「JSR 應重新定義為 Java Method Request，回歸解決開發者具體問題，而非單純執行規范。」—— Jason Weiss
- 建議學習 Apache 模式：輕量級、功能驅動、社區治理
- 簡化流程、縮短週期、降低參與門檻
改革建議：Sue Spielman 方案
- 分層治理：核心層（影響力專家）+ 專家組（利益相關方）
- 公開投票機制：全體 Java 社區投票決定優先級，非僅專家組
- 時限制約：強制週期，防止無限拖延
- 試點先行：用即將到來的 JSR 驗證新流程
現代視角：JCP 的歷史使命與繼承者
| 時代 | 標準化主體 | 代表成果 |
|---|
| JCP 全盛期 (2000-2010) | JCP (Sun 主導) | J2EE, JMS, JPA, Servlet, JSP, EJB 3.0 |
| 開源崛起期 (2010-2017) | Apache, Eclipse, Spring 社區 | Spring Framework, Maven, Hadoop, Kafka, Netty |
| 現代雲原生期 (2017+) | OpenJDK + JCP (Oracle/社區共治) + MicroProfile | JDK 17/21 LTS, Jakarta EE 9/10, MicroProfile 5/6 |
總結
JCP 的失望源於治理結構與開發者需求的錯位：大廠主導、流程重、門檻高。但歷史證明，真正推動 Java 生態演進的往往是開源社區（Apache、Eclipse、Spring）而非單一標準組織。現代 Jakarta EE (原 J2EE) 已移交 Eclipse 基金會，MicroProfile 針對微服務快速迭代，OpenJDK 由多廠商共同維護——多中心、輕量級、開發者優先的新治理模式正在取代舊有的 JCP 模式。
