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除了它们自己，就没有别的支持者了。
看看这个公式就知道：在为IBM创立J2EE事实标准上，JCP扮演的角色与结构化信息标准推进组织（Organization for the Advancement of Structured Information Standards，OASIS）在创建事实的Web服务标准上所扮演的角色相同。它们都是带有知识产权政策的政权制度（这是任何需要邀请行业其他成员参与的规范所需要的），而且对不具备辨别力的客户、管理者、联邦反垄断检察官、阴谋理论家（但不是这个）、唱反调的人、媒体等来说，把它们的名字与规范联系在一起会造成一种印象，觉得统治的尝试还没有开始，但事实上，统治已经开始了。
也就是说，尽管所要讨论的JSR正在走相应的程序，而且如果它们最终的版本被批准的话，我的感觉是，尽管通过了JCP体制的洗礼，但是对这些JSR的整体影响只会是稍有不同，如果有变化的话。不论是哪种情况，IBM关于Java的要求将会得到回应，因为IBM在多个场合告诉过我，说它们希望看到Java从Sun的控制之下摆脱出来（尽管Sun声称没有控制它）。
对于我来说，这种完全是强权玩的游戏似乎已经把JCP边缘化了，这就同IBM和微软将W3C边缘化是一回事，这就是为什么我在自己专栏里公开提出“这是否我们所知的Java的末日”的原因？我和Sun的软件执行副总裁Jonathan Schwartz交谈过，了解了Sun对这一问题的看法。
在我进行的采访中，Schwartz不同意IBM和BEA采取的行动降低了的Java和JCP的完整性，他说BEA和IBM将规范提交给JCP的原因不是为了掩饰（我所说的那种）强势压制，而是“因为市场向JCP寻求它们感觉可靠的标准”。Schwartz后来将这种可靠性的特性总结为JCP为了客户的利益而进行的竞争和替换。Schwartz相信，如果有什么东西的话，那就是JCP的凝聚力“挫败了IBM”。
Schwartz澄清说，Sun没有被判失败。暴露于氪化物之下的超人看上去会被打败，但是最后却成功地摆脱了它的影响拯救了地球。Schwartz在谈到Sun自己的J2EE产品——AppServer 8.0——时就采用了类似的方式，就好像它是Sun、Java和行业里救世主，奋起反抗体重800磅、妄图统治世界的、发狂的大猩猩。它可能是。尽管时间最终会验证Schwartz的预测，但是现在还是让我成为第一个承认AppServer 8.0可能成为破坏IBM努力的秘密武器的愤青吧。
就像Schwartz在采访中告诉我的一样，AppServer 8.0服务于多个目的。由于它符合最新版本的J2EE（1.4版），这在该规范于2003年11月通过JCP最后投票过程两周之内就实现了，而IBM直到2004年2月才在其WebSphere里支持这一规范，所以IBM找不到借口说JCP制定标准的过程太慢。在规范通过批准之前，JSR的所有成员都具有平等的权利改进它，这就使得这些成员能够及时地发布符合该标准的应用服务器。
Schwartz说，如果IBM真的对时间那么敏感的话，它就应该在该规范被JCP批准的几天内推出符合1.4版标准的服务器。但是，作为第一个拿出符合J2EE 1.4标准的应用服务器还不够，AppServer 8.0还是最早（甚至早于微软）支持Web服务互操作性组织（Web Services Interoperability Organization，WS-I）基本特性验证方案（Basic Profile）的服务器之一。而WS-I是由IBM和微软发起建立的，Sun是后来者，对于它来说，在某个创始成员之前就迅速地拿出符合WS-I特性验证方案的技术很能够说明Sun的职责。
但是坦诚地说，如果这些说法都是真实的话，我发现它们大多都是Sun及其开发人员的精神胜利法。但是AppServer 8.0最实际的两个影响将是其价格和它所支持的平台——它是免费的，没有附加任何限制条件，可以运行在Solaris、HP-UX、Linux和Windows上。
在AppServer 8.0发布之前，Sun被认为是应用服务器阵营里比较拖沓的人。讽刺的是，Sun发明了Java，但是却无法比得上甚至是接近IBM的WebSphere或者BEA的WebLogic。Sun早期对Web服务的排斥，（Schwartz将其特性总结为“垂直的”视角），以及Sun受到Web服务运动中政治暗流的排挤，可能都是Sun在应用服务器市场上不佳表现的原因。现在，有一种“Sun碰到JBOSS（JBOSS是一个免费的、基于开放源代码的J2EE服务器）”的产品，它实际上是J2EE 1.4规范的参考实现，运行在多个平台上，它也加入了（和“垂直”相反）Web服务运动，在这样一个产品里，有哪个组织不回去上前仔细看看，尤其是那些已经忠于Java的公司（不同于那些属于微软的.Net阵营的公司）。
Schwartz会是行业里新的超级英雄吗？可能是。他和我谈到了所有的东西，从JCP到Linux赔偿，再到Sun要做什么才能够把Windows的开发人员吸引到Java这边来。你是怎么认为的呢？
本文地址：http://com.8s8s.com/it/it12720.htm