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除了它们自己,就没有别的支持者了。