为什么很多Java开发人员都对JCP感觉很失望

核心提示：很多富有编程经验的java开发人员都纷纷离开Java社区项目(JCP)，而转换到一些小型的开发者论坛发表他们的新观点，为什么很多Java开发人员都对JCP感觉很失望，JCP曾经是以友情帮助而著称的一片乐土，你可以在上面发表一个问题，JCP已经从解决问题的角色转换到纯粹地执行规范，这样的趋势应该要扭转过来，在几分钟之内就

　　很多富有编程经验的java开发人员都纷纷离开Java社区项目(JCP)，而转换到一些小型的开发者论坛发表他们的新观点。JCP曾经是以友情帮助而著称的一片乐土，你可以在上面发表一个问题，在几分钟之内就可以得到回答。但是，现在的JCP已经变得“肥胖”，“臃肿”，“笨拙”。
　　
　　其中一种感觉就是JCP已经失去了它的吸引力，它不再是被当成针对解决问题的社区，相反，它只是被看成是一些大公司所利用的鉴定规范通过的橡皮图章。这些大公司凭着自身的钱势和力量来指定各种规范从而达到满足自己的利益。
　　
　　“这与有些官僚机构很相似，只不过是JCP在短时间出现这样的发展显得过于迅速。” Redwood城市的Infravio公司的CTO，MukundBalasubramanian谈到JCP时，他这样说到，“现在有太多的程序员和公司都卷入JCP，天天都开发很多软件，天天都有大量的调试和研究要完成，这必然会出现无法控制的局面，单就这一点就可以导致JCP的发展十分缓慢。所以我很能理解很多Java开发人员对JCP厌倦的原因。”
　　
　　作为网络内容开发系统的开发者，Montara软件的Matt Liotta也赞同这样的观点。
　　
　　“越来越少的开发人员涉及到JCP了，”Liotta说道，“相反，他们开始对其他一些组织感爱好，比如Apache，并乐意把自己的软件变成标准化。”
　　
　　Java API已经被推翻了？
　　Sue Spielman是Switchback软件的校长和高级咨询工程师，也是很多Java相关书籍的作者，她说，现在已经有很多Java规范请求(JSRs) “推翻了Java API”。
　　
　　“虽然这并不是一件坏事，但对于一个停留在JCP里的Java开发人员来说无疑是一个挑战，”Spielman说道，“在一些开发人员眼里也是好事，因为JCP显得太浮肿了，而且其发展速度象蛇一般的缓慢，这对任何想钻研JSRs的人是不合适的。”
　　
　　“我的一个建议是重新更改JCP的结构，以致达到适合于不同JSRs的不同层次。其中，主要的层次可以由Java领域中一些有影响力的人组成，专家组可以由对JSR感爱好的组织或个人组成。评论过程将会考虑所有公共意见，但也不是意味着所有的公共意见都会成为最终的JSR。可以通过公共Java社区(并不仅仅是专家组)的投票来决定信誉度，而且期限也是有限制的。所以，以Java社区投票的形式最终决定哪些才是Java开发最重要的。”
　　
　　“至少，我们可以使用一个即将来临的JSR做一个测试以查找结果如何。JCP已经做了很多规范工作，我们不应该删除这些工作，因为社区工作是一个努力，耗时的过程。”
　　
　　下面是Java开发人员的四种观点。
　　
　　观点1：JCP没有给予一些无足重轻的开发者足够的重视，比如一些个人和新手。
　　
　　作为Wakesoft的奠基人和CTO，Walter Hurst十分关注BEA将它们自己的所有权服务器变成Java标准的运动，这一运动意味着在短时间内会引起钱财利益上的冲突。
　　
　　“这实在有些不公平，不是吗？对于那些拥有良好观念和产品的小公司将意味着什么？他们将没有资金能力去获取所有权产品作为标准。”
　　
　　观点2：假如你不是JCP上的投票成员，只是在线的组织对选举是没有太多作用，虽然表面上是开放标准社区的目标。
　　
　　“很多人都觉得JCP变得如此‘慢’是因为JCP把其中的很多可见性都包含在社区的内部工作之中，”Balasubramanian谈到，“假如程序文档化或下载需要很长时间，这是说明JCP变得很臃肿和缓慢。但假如你不是投票人选，那么在很多决议上会受到限制。”
　　
　　观点3：很多开发人员都认为JCP和其他的大公司的政策冲突失去大量的Java程序员。
　　
　　“任何时候，你都可以看到代表多数人的组织决定提高更加成熟的标准，你也可以看到资金雄厚的大公司参与到运动之中，”Balasubramanian说到，“比如JCP是为了Java ，而W3C 是为了Web。这些大公司都有足够的资金和人力去争取这些标准所得到的利益。”
　　
　　“诸如Infravio的小公司并没有被JCP拒绝，但这些小公司可以集中于专业技术的研究，并发表与自己相关的观点。”
　　
　　观点4：一个独立但具有良好想法的开发人员必须得到大公司(比如Apache软件，免费软件组织等)的支持才可以实现软件开发的标准化。
　　
　　“我觉得在一定程度上是对的，”Balasubramanian谈到，“这对于一个开发良好和技术成熟的组织是不利的。假如我是一个独立的软件开发者，我将希望得到Apache的支助，得到Apache一些流行的技术，而且我愿意在JCP社区上回报我的成绩。另一方面，有利于技术的标准化，以获得更多的信任，这对社区的发展非常有好处。这一方面的技术范例即为Struts 和jsp标准类库。”
　　
　　JCP程序治理人员的意见
　　作为Sun微系统的JCP程序办公室的经理，OnnoKluyt也是面临着各种指控。他很坦白自己的意见，他承认政策对JCP起着很重要的作用。然而，他指出个人参与，与公司参与一样，在社区的不同层次上是可能的。
　　
　　“个体成员，如同公司成员一样，能够加入专家组织，倡议和领导JSRs，在年度执行委员会选举中投票，能真正参与到选举中，把自己作为执行委员会的成员。”
　　
　　“这样的例子还是很多的。比如：Doug Lea是JSR 166的主要领导人，他是专家组中的成员，也是SE/EE Executive Committee(SE/EE执行委员会)的成员。”
　　
　　“Jason Hunter也是作为独立个人领导着一个JSR(JSR 102)，Steve Emerson领导JSR 108，还有，一个小公司领导JSR 113 (Java Speech API)，Brian Zimbelman和Jim Keogh在负责年度选举。”
　　
　　当被问及对大公司利用JCP为自己的利益服务的有何感想时，比如BEA利用政治手段获得所有权服务器作为标准这样的例子，Kluyt回答到：
　　
　　“与其他组织一样，JCP也有一系列的政策。但我相信绝大多数的政策都是可以接受也是合理的。JCP通过JSRs实现自身的标准化。一个JSR可以由一个JCP成员来治理，例如BEA。专家组是典型的大小公司和个人的混合体，你可以在专家组中结交很多朋友，当然包括你的竞争对手。JSRs通过三次具有里程碑的投票获得了执行委员会的批准，第一次：JSR评论，第二次：社区评论，第三次：最后赞同投票。这些模式都逐步使很多事件走向公正化。”
　　
　　Jason Weiss最近在Java Developer's Journal(Java开发者杂志)中提到，“[J2EE]规范太复杂。Java开发人员应该重新结盟以建立新的社区，这一方面应该向Apache软件组织学习。”
　　
　　“Java开发人员现在应该逐步为未来的Java和社区投资。” Weiss说到。
　　
　　“所有的JCP应该反映我们的思想，应该立足于为程序员简化各种复杂问题。事实上，JCP应该继续使用JSR缩写词，但应该赋予新的含义：‘Java方法请求’。在以前的很多时候，JCP已经从解决问题的角色转换到纯粹地执行规范，这样的趋势应该要扭转过来，才能保证我们社区的发展。”