Java标准制定组织已经由于IBM和BEA的作用而被腐蚀了吗？Sun的AppServer 8.0会在已有的产品中形成竞争力并为用户提供更多选择吗？我在这里将给出自己对此的感受，以及与Sun的软件大帝Jonathan Schwartz的会谈内容。
评论：最近，我写了一个专栏，提出了这样一个问题：这难道就是我们所知的Java的末日吗？这个问题的提出是由一项向Java标准制定组织（Java Community Process，JCP）提出的增强Java标准的提案引起的，这项提案希望JCP的成员，比如IBM和BEA，在采纳这一提案之后（而不是之前）实现对Java标准的增强。
多年以来，JCP一直都是讨论Java技术改进提案的场所。Java由很多不断变化的部分和组件构成，包括Java虚拟机（Java Virtual Machine，JVM）各种针对占用空间的版本。事实上，所有这些单独的Java规范以及对它们的任何升级——也就是Java迷所知的Java规范请求（Java Specification Request，JSR）——会在被正式融合到Java标准里或者在得到符合Java标准的产品的支持之前，被发散出去，并由JCP的组成成员来修改和改进。
从历史上讲，当创建Java扩展的官方过程被某一家公司以某种被认为违反Java“一次编写，随处可用”承诺的方式绕过时，该公司必须要提醒开发人员它将背离Java的承诺（在开发人员调用这类供应商专用的扩展时），或者，在大多数人所共知情况下，面对Sun的愤怒。
当微软向自己的Java虚拟机里加入Windows专用的扩展而没有事先提醒开发人员的时候，Sun告了微软一状，这场官司在2001年审结。而这场官司在行业里的反响一直延续到现在。
类似的， IBM于2001年10月提出用Eclipse集成开发环境（Integrated Development Environment，IDE）作为一种开放源代码的方案取代Sun认可的IDE——NetBeans，尽管没有提起诉讼，但是Sun被这种做法激怒了。Eclipse向开发人员提供了多个撤离Java地盘的方法，但是Sun关心的一个东西是IBM开发的、用于Java的图形用户界面（Graphical User Interface，GUI），叫做SWT。为了保证Java“一次写成、随处可用”的承诺，Sun鼓励用户坚持用SWING（这是NetBeans里默认的GUI库）。
尽管先前对Java领地的侵犯是单方面的，但是最近IBM和BEA联合努力的公开化可能标志着Java生态系统已经进入了一个新的时期。JCP的这两个成员，都是J2EE的JSR的组成成员，它们通过合作推出三个J2EE扩展（服务数据对象、应用服务器计时器和应用服务器工作管理器）绕过了传统的提出—批准—支持这一顺序。它们承诺首先在其应用服务的下一版本里对这些扩展进行支持，然后再将它们提交给JCP。
根据最近的统计，IBM和BEA已经取得了J2EE市场领先者的桂冠，它们共同控制了该市场66％的分额。IBM和微软的市场存在让其他的竞争者没有多少选择，只有去使用这两家公司合作制定的各种Web服务规范。通过相同的方式，IBM和BEA两者在J2EE市场上的力量让其他竞争者在这一市场剩下的份额里没有多少选择，只有去使用这两家共同支持的各种规范。
从走程序的角度来看，IBM和微软在万维网协会（World Wide Web consortium，W3C）里努力建立事实的（即由任何标准化组织而不是由官方认可的）Web服务标准的过程同IBM和BEA在JCP里确立优先权的过程惊人地相似，而且现在可能已经成了惯例。
最近很多在2003年提出的规范——尤其是那些Web服务的规范——已经或者将要获得事实的标准地位，这都是IBM或者微软（或者两者共同）同与规范相关的市场上第二大的公司共同推动并联合宣布对该规范（例如安全方面的Verisign）进行合作研究的结果。
微软和IBM单个都还没有强大到利用这些规范威胁整个行业的地步。但是当它们相互联合，或者与它们将要介入的市场上第二大的猩猩联合的时候，整个行业就必须跟着它们走。IBM和BEA的合作就是对这一公式的另一个完美的执行。
尽管这两家公司和Java的守卫者Sun可能不同意我的评价，因为它们认为所提出的规范已经作为JSR 235、236和237（这三个都把IBM和BEA列为其主导者）列入了JCP的日程，但是我的感觉是，把这些提案提交给JCP只不过是象征性的。而其他的JSR，包括最近提出的用于移动国际化API的JSR 238，所列出的支持者要比这个领导者单子上的多。我最近一次查过，由IBM和BEA提出的这三个JSR除了它们自己，就没有别的支持者了。
