JCK和Java兼容性

阅读更多
Stefano Mazzochi 老师最近似乎比较闲也比较happy,频频在Harmony的mailing list上制造一些有趣的话题,继Harmony的 经济学讨论之后,他又开始在x86_64上试验Harmony,并且对Harmony的 API覆盖率产生了兴趣,他公布的最惊人发现是,Sun/BEA/IBM的Java 5 API竟然不尽相同! 尽管最终证实IBM JDK 5和Sun JDK 5相比只多了一个StringBuilder.append(StringBuilder),还是很不可思议,要知道这是两个通过了JCK(Java兼容性测试)的Java SE,而增加非标准API是Sun严格禁止并且显示了巨大决心来坚决反对的行为(有人想起什么了?没错,VJ,和法庭判下来的白花花的好多钱),居然出现了Pass JCK的JDK出现如此明显的不兼容API,不禁让人对JCK产生了巨大的怀疑。

开源社区mailing list的人大多是technical person,对此大多付之一笑,谁都会认为只是IBM哪位工程师犯了个错误把本应是private的方法标成了public,而Sun写JCK的工程师又恰好漏掉了检查(StringBuilder是Java 5的新类,test不全可以有些借口),但是问题是这两家公司现在应该怎么办。IBM很可能会感到一定程度的紧张(怕被人指责为XX节档案重现),但多半不肯删除这个API,万一break某大客户的程序不就惨了,标成deprecated? 似乎不解决任何问题。而Sun应该也不至于无聊到为了一个方法敲IBM竹杠,但也不能就这么算了,维护Java兼容性是Sun上上下下的Java person的圣杯,不容丝毫亵渎,把这个方法加进Java API? 万一以后IBM甚至BEA尝到甜头没完没了加东西怎么办?一涉及到Enterprise,这事情还真的很复杂哩...有没有人给算一算,为了这个新方法要花掉多少钱?

这里是另外一个拿JCK打趣的 blog.

你可能感兴趣的:(Java,IBM,SUN,JDK,制造)