Oracle诉讼Google之联想
2010-08-28 16:18:30 
阿炯
Oracle诉讼Google缘何正确
技术产业喜爱一场厂商的恶斗，来势汹汹的Google与Oracle之间的法律之争就有着它所需的一切壮观特质。
被热议的就是Dalvik，那个特殊的、基于Java的Google Android智能手机操作系统核心中的运行环境。在2009年收购Sun Microsystems之后接管了Java platform 的Oracle控告Dalvik有知觉地，愿意地，和有意地侵犯其Java知识产权。据上周美国San Francisco地方法院存档的申诉报告，Oracle欲叫停Android的任何进一步开发，销毁一切侵权的Android软件，并要求Google 赔偿实际构成的和法律意义上的损失。
博客人们、评论员们和开发者们纷纷责难这场诉讼。Farata Systems的Anatole Tartakovsky写道，Oracle管理者脑子进水了。PC World的 Tony Bradley把Oracle描述成一个专利恶魔，有其他人则毫不客气地把它和SCO Group相提并论。InfoWorld自己的编辑Eric Knorr，把Oracle比作Darth Vader 和同一栏目里的Batman's Nemesis the Joker。
如此不由自主的迅速反映是有误导意味的。Google并非Luke Skywalker，其对Java的处理本身就问题重重。认为Oracle手辣，是因为忽视了更大的事实就是在最近几年里，Sun对Java的管理太温顺、太无力了。没有强硬的领导，Java社区承受了缓慢和负重的发展进程，让这一平台的未来疑问重重。对 Google的诉讼是Oracle致力于改变这一切的明证这也可能正是Java社区所需要的。
只在名字上是Java
具有讽刺意味的是，鲜有公司如Google那样对Sun失败的领导直言不讳的。比如在四月的Red Hat Middleware 2020虚拟会议上，Google首席Java构架官Josh Bloch描述这一平台是无方向的，力促Oracle在决定它的未来上起到领导作用。过去几年里的技术和许可争议已经十分有害了。它们耗费了社区的精力，引起了一系列不适的压力，Bloch说。
可是谈话已经没有用了。实际上Google已经不再期待Oracle，它已经怀着自己的Java计划奋斗前冲了。结果就是Android，一个只在名字上是Java的平台。Dalvik虚拟机甚至不能执行Java字节码；相反Java class文件必须预编译成Google自己的.dex格式才能运行。而且Android开发平台既不是Java SE 也不是Java ME，而是一个来自stock Java、Apache 基金会和 Google自己所贡献的的一个类的大杂烩。
这不是偶然。在一个博客帖子上，Java创始人James Gosling回忆起Sun与Google的早期谈话，以及那家搜索巨头是如何更感兴趣于用Android分食Apple的市场而非真心支持Java的互通用性核心原则尽管遭到Sun的强力反对。
这也不是Google漠视Java标准的唯一例证。2009年，Simon Phipps，Sun当时的首席开源官，批评Google在其应用引擎云计算平台上未能支持Java核心的类的全集。在Java平台上生成核心类的子集有充分的理由被禁止，Phipps在一个博客帖上写道，并且玩弄规则是荒唐和不负责任的表现。
同样地，谷歌网页工具集(GWT)声称是一个帮助开发者用Java写客户端网页应用并以Javascript形式发布它们的工具，但Google自己承认 GWT只支持大多数核心Java语言语法和标准Java类的一个小子集。看来Google对Java的爱还只是因为它作为一个语言很流行，而不是作为一个平台所具有的凝聚力。
Oracle诉Google案
但是如果创造Java只是为了发明一个新语言，Sun当初就不会那么煞费苦心了。Java大部分语法是从C、C++,和其它一些地方借来的。真正让它出新并且重要的是JVM，其沙盒安全模型和其一次写成，处处运行之承诺。与Java类库相伴，JVM使Java成为一个从对下面操作系统的依赖之恼中解放了开发者的独特的平台。尽管在最近几年里，Java在好多路上有辜负其最崇高的目标，Sun为保住Java作为一个始终如一的、统一的平台所作出的努力还是未尝改变过的。
这些努力所迎的最大一次挑战是在20世界90年代后期，当微软试图通过提供一个唯Windows版的这一语言来分裂Java社区之时。Sun把事件带到了法庭上，论微软的作为侵犯了Java许可协议。当2001年尘落定之时，微软同意打消其Java企图，向Sun支付两千万美元损失赔偿。
现在如果微软想要使用Java，它们不得不使用和每个人都一样的Java，Sun副总裁Rich Green当时说。难道Google不应该以同样的标准被约束吗？Oracle认为应该，并且像当年的Sun一样，它选择了诉诸法律。
开源之后，Java的许可现在更加复杂了。这也可以解释为什么Oracle在对战Google时更看好专利路线。开源大师Bruce Perens指出，Java语言规范包括了许给Java实现者对Sun专利的免许可自由这一条款，但它在此案件中不适用。因为只有对Java及其必需包的完整安装启用才有权免许可；不可以是其子集或是超集，这点Android在Java使用上没能做到。
Oracle的投诉还提及版权，但是这里细节不足。Java和Android都是开源的，但尽管Java使用GPL，Google更喜欢那个更加商业友好的Apache许可。如果Google在其代码库中包含逐字的Java源代码，这一许可冲突就可能成为侵权立案的有力根据。
接下来会发生什么
Google说Oracle的行动是对Java社区的重重一击，但那只当Google是在发展Java时才是真的。然而就Android 和Dalvik VM，藐视建立起来了的Java标准，作出了自己的Java实现这一事实来讲，Oracle把Android比作纯Java之敌是正确的。并且作为 Java知识产权的所有者，Oracle有权也许也有责任来陈防卫这一平台免受此敌之害。
但是也请我们不要再哄自己了，别再开玩笑了。Darth Vader的比喻是夸张的，但没人曾把Oracle比作白衣救士，它在这里也绝对不是本着无私的动机来行动的。这场诉讼结束的那一天，剩下的都只是钱的问题。Android现在是一个建成了的良好平台，Google承受不了这场拖延时间的法律之争。Oracle等待着Google来解决，结果当然是每一部Android手机上的一个咖啡杯图标以及一笔可观的收入。更有甚者，这一诉讼会更加巩固这一信条走 Java之路必经Oracle，Java使用者跳出这条路等待着他们的将会是危险。
可是这如此可怕吗？Java社区需要一个领导。Sun之把Java推向社区的爱臂的尝试被证明是像把该公司推向失败的其它点子那样：学术上合理，外交上精明，而结果是行不通的。Google的Bloch叫Oracle强硬一点是正确的。或许他当初对他的期望多点谨慎就更好了。
提醒一下，Oracle并非一定会赢之场官司。这场诉讼之中所涉的专利引起了太多的头疼太多的怀疑。Google避开这个子弹也还是有时间的最简单的方法也许就是避开Java本身。因此听到新系列的Android是第一个基于Google Go的平台之说，请不要感到惊讶。
Android与Java间的尴尬
2010年整个Java阵营都陷于一场讨论Oracle和Google之间关于Android平台的专利诉讼官司的混战中。来自外刊IT评论的最新翻译文章解释最近 Oracle 想要告 Google 的 Android 系统的原因。该文章解释 Android 平台与 Java 千丝万缕的关系。
文章内容如下：
最近整个Java阵营都陷于一场讨论Oracle和Google之间关于Android平台的专利诉讼官司的混战中。我已经在很多地方都发表过我的观点，但这确实是个 重大的话题，需要在所有地方反复重申这个观点 所以，这篇文章就是要再次的完全的揭露事实真相。第八大千禧年问题： Android = Java?
前几天，有研究者宣称找到了P !=NP的证据,这在编程界引起了不小的兴趣;至少为此狂热了好几天，直到开始有评论家指出证据中有很多的缺陷。我在做计算机科学系学生时研究过这个题目，但说实话，我的高等数学的水平还达不到看懂这些证据的水平(P = NP? 是克雷数学研究所提出的七个千禧年数学问题中的一个。)所以，还是让我们来讨论一个稍微简单点的问题：Android是否相当于Java？请注意，我并没有说相等，我说的是相当，就像P = NP里的那样。
相当的类/字节码格式
在很多层面上，Android和Java都有明显的相当。Android应用程序是用Java(TM)语言写成的，使用JDK的javac(或等效工具，例如ECJ)来编译。这个过程产生标准的Java字节码(.class文件)。这些文件再转化成Android的.dex文件，从使用的角度来看，它就是一种不同格式的Java class文件。不错，这是一种更优秀的格式；对Sun自从1994年以来的设计有了很大的改进。但就如你可以把一个GIF格式的图片转换成更高级的完美的完全等效的PNG格式，尽管它们的字节流完全的不同。
等效的文件格式在细节的实现上非常的不同，主要是为了优化。就好比如果我们简单的满足于低效率的视频数据流，没有采用高端的、跨不同框架的压缩技术，那我们就可以避免跟MPEGLA视频解码专利做斗争的麻烦了。
Android特异的classfile设计有好几种动机；而为了避免和Sun的知识产权保护冲突显然是一个主要的因素。不管怎样，Google并没有走的离Java足够远。两种文件格式非常的类似。它们在特定的底层数据结构上有区别，但这些结构体在语法上一致的，存储完全相同的信息。我相信在 JavaSE或JavaME VM里可以轻易的在它们的系统classloader里添加一个.dex分析器来加载Android classes。
Android SDK 依赖于.java -> .class -> .dex 转换的事实情况既微不足道也毫无损失。毫无损失的事实很重要：当GIF = PNG 时，跟受损的JPG文件就不等了; 它解码不出完全相同的信息。如果JVM和Dalvik都各自独立，你很难写出一个相对简单的工具将一种编译过的代码转换成另一种；而且不做任何妥协：不丢失信息，不使用冗余来补偿某种特征在一种VM中是first-class而在另一种中却不是的情况，不需要额外的runtime层 上在一种VM中实现另一种VM的核心API。
(我知道dx转换器有多么的复杂。我看过它的源代码。那个字节码转换器是一个巨大的，全功能的反编译/重编译器，通过SSA构造完成。但是这个转换器在概念上仍然是无足轻重的；从Java字节码到Dalvik字节码的映射在设计上是很平滑的。堆栈相对于寄存器架构中细节上进行了优化；而重要的东西，例如VM层的类型系统是完全一致的。)
VM相当
这Dalvik 和 JVM 的相当也是很容易看清楚的。并不只是源代码或字节码格式上的问题：它们的runtime对等物上也一样。一但一个Android class被加载到Dalvik VM里，它就会像Java class一样运行，像Java class一样工作。如果你懂得Java编程(深入到高级的，底层的细节)，你也就懂得Android编程。你只需要学一些新的API和框架概念。他们是对等的系统。
是否记得微软的.NET
当.NET刚出世时，Java阵营迅速的反击指责.NET是对Java的剽窃。我也是其中的一份子，但今天我看问题更清楚了。是的，它过去是个严重的剽窃产品；C# 1.0 就是一个 区分一种语言和另一种语言最简单的方法就是看它们的惯用风格 —— 例如toString() 相对于 ToString()。 但在最重要的VM规范里，微软做了很大的功课。它的CLR,CLI,和核心框架，都非常的不同于Java，所以我们不能说JVM = CLR这个等式。你不可能使用一个简单的文件格式转换工具把你编译好的Java class转换成能在.NET runtime上运行的代码。
要证据吗？你只需看一看IKVM就知道了。这是一个非常有趣的项目，它能够使Java和.NET跨平台兼容，于是，你的Java代码可以在不做修改的情况下在CLR(或者是等效的.NET runtime，比如Mono)上运行 但IKVM并不是一个简单的、类dx的 文件格式转换器。对Java class的转化、对Java核心API的适配，都是十分的复杂，即使对一个简单的HelloWorld程序也是这样。各个平台的内部机制，如反射，安全，并行，异常处理，字节码验证，I/O，以及其它核心API，特征上大致相同，但是在细节上完全不同，一些死胡同的情况会迫使IKVM不得不钻越一个又一个的火圈来让Java代码运行到了.NET VM上。它需要依赖于一个巨大的额外的runtime层，来适配从OpenJDK源代码里来的完整JavaSE API。我大致的关注IKVM的开发已经有数年了 —— 我阅读这精彩的IKVM 博客 – 所以我完全清楚他们为了让Java程序和JavaSE应用适配到.NET上所做的巨大的努力。(这项工作仍然没有完工；而且很多部分都需要以丧失某些性能为代价。)
(老的Visual J++ Visual J# 也不是一个简单的 Java-to-.NET 转换器。我不想讨论它，但我们完全可以说Visual J# 对Java的兼容并不比最早期的IKVM强多少。)
我把P = NP引进来了讨论；有些人把图灵等效(Turing-equivalence)理论引进来，说任何图灵完备的平台/语言/VM都是相互等价的。这也没错， 但与本论题无关。图灵模型这种方式太泛化了；使用这种表面价值来考量会把更个软件专利系统摧毁(尽管这不是个坏事！)。我们需要在地上为JVM等效画条 线，一条更接近实用需求而远离图灵等效的线。按我的观点，这微不足道的二进制格式转换，穷尽的高层源代码和runtime的兼容，使Android明显的 处于Java等效的这条线内。
APIs 和 Runtime 相当
Android使用了一个相当大的JavaSE APIs子集。这些APIs (来自于Harmony项目)都是全新的实现，但它们是以JavaSE为模子。如果不是因为TCK许可证问题，Harmony完全可以取得JavaSE认 证。但这并没有改变这样的一个事实：Harmony 和 JavaSE APIs是 完全的等效的 —— 这是特意的，不是偶然的。就像Charles Nutter——有名的JRuby人物——最近写道：
Android支持一个不完整的(但相当大的)Java 1.5 类库子集。这个子集大到一个复杂的JRuby项目几乎不经任何修改就能在Android上运行，很少有限制情况。看起来Dalvik对JVM是如此的接近，它不得不完全兼容大部分的JVM规范，包括完全详细的JMM (就像Android支持Java风格的线程和并发，已经深入到了高级的java.util.concurrent包里了)。可为什么有如此多的Dalvik是个新VM或Dalvik不能运行Java类 的说法呢(90%的讨论这场诉讼的论坛和博客都持这种观点)。
最后的思考
这篇博客并不是关于Oracle和Google诉讼官司的法律依据的。我将会忽略(我会删除掉)那些跑题的评论(跟Android = Java不相关的话)。我只是讨厌那些Android跟Java完全没关系的胡说八道;Google和 Android的拥护者必须要找一个更有意义的论据。(我将拭目以待这场官司的进展，带着我所有的预见，直到所有细节和最终结果都出来。除非你有内部消息(我没有)，不要太天真、保持冷静。 我们并不知道Oracle的 或 Google的；真正的全部动机和计划。我们并不知道这荧幕背后的故事，自从2007年Google首次宣告Android的诞生(这导致了JavaME生态环境的崩溃), Sun就痛恨不已，但最后还是不得不夹着尾巴行事。我不相信任何一个有10亿美金的股东控股公司会有利他主义的动机：Google不会，Oracle不会，即使我喜爱的老的Sun公司也不会。我们等着看吧。)
我不相信Google没有能力创造出一种既不背离Java太远，又以Java风格为基础的平台(就像.NET做的那样)。 Dalvik，以及Android框架，它们可能是在权衡了与大量的现有的Java程序，类库，Java天才，和Java工具链高度兼容的愿望的最后结果。微软在一咬牙一跺脚后放弃了现成移植Java带来的好处，创造了全新的.NET。Google没有这样做。
这个Android = Java等式显然并不是包括所有的东西(不是一一对应的)。每种平台都有自己一些独特的API，当然，Android是一个完整的操作系统，包括一个 Linux-based的内核，图形系统和电信堆栈，等等。很显然，我只是谈论其中最常用的部分：Java为中心的用户使用区/依赖于Java源代码、 Java classes(切不管什么格式)、Java APIs(包括成千上万的常用JavaSE APIs)和出色的类Java的虚拟机的应用框架。对于Android和其它的Java平台之间的关系有个准确的说法，就是使用版本的概念。我曾记得有个博客说过这样的话Android里没有J。那么我现在说也不晚：我建议把Android改名为Java GE(Java Google Edition)。这样一来就再也不会导致混淆了。
上文英文原文。
美国能禁止编程语言或编译器授权吗？
如果美国禁止向中国出口CPU，那么国内电脑将只能选用国产芯片。如果美国撤销编程语言或编译器的授权，那么是否咱们还得自己发明一套编程语言或编译器呢？
唯一能约束一种编程语言的就是专利，但C语言等目前并不受任何专利约束。Bell实验室最早实现了C语言和Unix，但是其未能通过专利的力量阻止其他平台上C语言的实现和使用，未能阻止BSD和GNU的出现，未能阻止Unix大战，使得最后正统意义的Unix不复存在。后来从开源社区诞生的语言比如Python、Ruby、PHP、Go等，原本就不受专利约束，任何人都能自己实现它。
当然仍然受专利约束的编程语言是存在的。比如Java在Oracle的手上，仍受专利约束，所以才有了上面旷日持久的Oracle诉Google案。如果发生新冷战，到时候可能不能合法地使用Java了，像C#、Delphi、VBA等由商业公司创制的编程语言可能也将不能使用，只要他们随便在专利或者授权上找一个把柄就可以了。x86、ARM指令集也是受专利保护的，这就使得这些处理器的汇编语言也有可能不能合法使用。
至于编译器，可以去了解一下GPL协议。现代编译器一般分为前后端，即使后端代码生成部分不能再生成x86、ARM汇编代码，我们也能通过合法使用开源协议来为我们的自主架构，或者RISC-V等开放的架构开发自主的代码生成模块。而对于GCC、LLVM而言，其他东西本身是开源的，假设编译器原有代码本身不侵犯其他企业的专利，GPL协议并没有什么国家安全的特例之类条款，只要保证能够不关闭其源代码，因制裁被禁用的国家就可以随便用。
技术产业喜爱一场厂商的恶斗，来势汹汹的Google与Oracle之间的法律之争就有着它所需的一切壮观特质。
被热议的就是Dalvik，那个特殊的、基于Java的Google Android智能手机操作系统核心中的运行环境。在2009年收购Sun Microsystems之后接管了Java platform 的Oracle控告Dalvik有知觉地，愿意地，和有意地侵犯其Java知识产权。据上周美国San Francisco地方法院存档的申诉报告，Oracle欲叫停Android的任何进一步开发，销毁一切侵权的Android软件，并要求Google 赔偿实际构成的和法律意义上的损失。
博客人们、评论员们和开发者们纷纷责难这场诉讼。Farata Systems的Anatole Tartakovsky写道，Oracle管理者脑子进水了。PC World的 Tony Bradley把Oracle描述成一个专利恶魔，有其他人则毫不客气地把它和SCO Group相提并论。InfoWorld自己的编辑Eric Knorr，把Oracle比作Darth Vader 和同一栏目里的Batman's Nemesis the Joker。
如此不由自主的迅速反映是有误导意味的。Google并非Luke Skywalker，其对Java的处理本身就问题重重。认为Oracle手辣，是因为忽视了更大的事实就是在最近几年里，Sun对Java的管理太温顺、太无力了。没有强硬的领导，Java社区承受了缓慢和负重的发展进程，让这一平台的未来疑问重重。对 Google的诉讼是Oracle致力于改变这一切的明证这也可能正是Java社区所需要的。
只在名字上是Java
具有讽刺意味的是，鲜有公司如Google那样对Sun失败的领导直言不讳的。比如在四月的Red Hat Middleware 2020虚拟会议上，Google首席Java构架官Josh Bloch描述这一平台是无方向的，力促Oracle在决定它的未来上起到领导作用。过去几年里的技术和许可争议已经十分有害了。它们耗费了社区的精力，引起了一系列不适的压力，Bloch说。
可是谈话已经没有用了。实际上Google已经不再期待Oracle，它已经怀着自己的Java计划奋斗前冲了。结果就是Android，一个只在名字上是Java的平台。Dalvik虚拟机甚至不能执行Java字节码；相反Java class文件必须预编译成Google自己的.dex格式才能运行。而且Android开发平台既不是Java SE 也不是Java ME，而是一个来自stock Java、Apache 基金会和 Google自己所贡献的的一个类的大杂烩。
这不是偶然。在一个博客帖子上，Java创始人James Gosling回忆起Sun与Google的早期谈话，以及那家搜索巨头是如何更感兴趣于用Android分食Apple的市场而非真心支持Java的互通用性核心原则尽管遭到Sun的强力反对。
这也不是Google漠视Java标准的唯一例证。2009年，Simon Phipps，Sun当时的首席开源官，批评Google在其应用引擎云计算平台上未能支持Java核心的类的全集。在Java平台上生成核心类的子集有充分的理由被禁止，Phipps在一个博客帖上写道，并且玩弄规则是荒唐和不负责任的表现。
同样地，谷歌网页工具集(GWT)声称是一个帮助开发者用Java写客户端网页应用并以Javascript形式发布它们的工具，但Google自己承认 GWT只支持大多数核心Java语言语法和标准Java类的一个小子集。看来Google对Java的爱还只是因为它作为一个语言很流行，而不是作为一个平台所具有的凝聚力。
Oracle诉Google案
但是如果创造Java只是为了发明一个新语言，Sun当初就不会那么煞费苦心了。Java大部分语法是从C、C++,和其它一些地方借来的。真正让它出新并且重要的是JVM，其沙盒安全模型和其一次写成，处处运行之承诺。与Java类库相伴，JVM使Java成为一个从对下面操作系统的依赖之恼中解放了开发者的独特的平台。尽管在最近几年里，Java在好多路上有辜负其最崇高的目标，Sun为保住Java作为一个始终如一的、统一的平台所作出的努力还是未尝改变过的。
这些努力所迎的最大一次挑战是在20世界90年代后期，当微软试图通过提供一个唯Windows版的这一语言来分裂Java社区之时。Sun把事件带到了法庭上，论微软的作为侵犯了Java许可协议。当2001年尘落定之时，微软同意打消其Java企图，向Sun支付两千万美元损失赔偿。
现在如果微软想要使用Java，它们不得不使用和每个人都一样的Java，Sun副总裁Rich Green当时说。难道Google不应该以同样的标准被约束吗？Oracle认为应该，并且像当年的Sun一样，它选择了诉诸法律。
开源之后，Java的许可现在更加复杂了。这也可以解释为什么Oracle在对战Google时更看好专利路线。开源大师Bruce Perens指出，Java语言规范包括了许给Java实现者对Sun专利的免许可自由这一条款，但它在此案件中不适用。因为只有对Java及其必需包的完整安装启用才有权免许可；不可以是其子集或是超集，这点Android在Java使用上没能做到。
Oracle的投诉还提及版权，但是这里细节不足。Java和Android都是开源的，但尽管Java使用GPL，Google更喜欢那个更加商业友好的Apache许可。如果Google在其代码库中包含逐字的Java源代码，这一许可冲突就可能成为侵权立案的有力根据。
接下来会发生什么
Google说Oracle的行动是对Java社区的重重一击，但那只当Google是在发展Java时才是真的。然而就Android 和Dalvik VM，藐视建立起来了的Java标准，作出了自己的Java实现这一事实来讲，Oracle把Android比作纯Java之敌是正确的。并且作为 Java知识产权的所有者，Oracle有权也许也有责任来陈防卫这一平台免受此敌之害。
但是也请我们不要再哄自己了，别再开玩笑了。Darth Vader的比喻是夸张的，但没人曾把Oracle比作白衣救士，它在这里也绝对不是本着无私的动机来行动的。这场诉讼结束的那一天，剩下的都只是钱的问题。Android现在是一个建成了的良好平台，Google承受不了这场拖延时间的法律之争。Oracle等待着Google来解决，结果当然是每一部Android手机上的一个咖啡杯图标以及一笔可观的收入。更有甚者，这一诉讼会更加巩固这一信条走 Java之路必经Oracle，Java使用者跳出这条路等待着他们的将会是危险。
可是这如此可怕吗？Java社区需要一个领导。Sun之把Java推向社区的爱臂的尝试被证明是像把该公司推向失败的其它点子那样：学术上合理，外交上精明，而结果是行不通的。Google的Bloch叫Oracle强硬一点是正确的。或许他当初对他的期望多点谨慎就更好了。
提醒一下，Oracle并非一定会赢之场官司。这场诉讼之中所涉的专利引起了太多的头疼太多的怀疑。Google避开这个子弹也还是有时间的最简单的方法也许就是避开Java本身。因此听到新系列的Android是第一个基于Google Go的平台之说，请不要感到惊讶。
Android与Java间的尴尬
2010年整个Java阵营都陷于一场讨论Oracle和Google之间关于Android平台的专利诉讼官司的混战中。来自外刊IT评论的最新翻译文章解释最近 Oracle 想要告 Google 的 Android 系统的原因。该文章解释 Android 平台与 Java 千丝万缕的关系。
文章内容如下：
最近整个Java阵营都陷于一场讨论Oracle和Google之间关于Android平台的专利诉讼官司的混战中。我已经在很多地方都发表过我的观点，但这确实是个 重大的话题，需要在所有地方反复重申这个观点 所以，这篇文章就是要再次的完全的揭露事实真相。第八大千禧年问题： Android = Java?
前几天，有研究者宣称找到了P !=NP的证据,这在编程界引起了不小的兴趣;至少为此狂热了好几天，直到开始有评论家指出证据中有很多的缺陷。我在做计算机科学系学生时研究过这个题目，但说实话，我的高等数学的水平还达不到看懂这些证据的水平(P = NP? 是克雷数学研究所提出的七个千禧年数学问题中的一个。)所以，还是让我们来讨论一个稍微简单点的问题：Android是否相当于Java？请注意，我并没有说相等，我说的是相当，就像P = NP里的那样。
相当的类/字节码格式
在很多层面上，Android和Java都有明显的相当。Android应用程序是用Java(TM)语言写成的，使用JDK的javac(或等效工具，例如ECJ)来编译。这个过程产生标准的Java字节码(.class文件)。这些文件再转化成Android的.dex文件，从使用的角度来看，它就是一种不同格式的Java class文件。不错，这是一种更优秀的格式；对Sun自从1994年以来的设计有了很大的改进。但就如你可以把一个GIF格式的图片转换成更高级的完美的完全等效的PNG格式，尽管它们的字节流完全的不同。
等效的文件格式在细节的实现上非常的不同，主要是为了优化。就好比如果我们简单的满足于低效率的视频数据流，没有采用高端的、跨不同框架的压缩技术，那我们就可以避免跟MPEGLA视频解码专利做斗争的麻烦了。
Android特异的classfile设计有好几种动机；而为了避免和Sun的知识产权保护冲突显然是一个主要的因素。不管怎样，Google并没有走的离Java足够远。两种文件格式非常的类似。它们在特定的底层数据结构上有区别，但这些结构体在语法上一致的，存储完全相同的信息。我相信在 JavaSE或JavaME VM里可以轻易的在它们的系统classloader里添加一个.dex分析器来加载Android classes。
Android SDK 依赖于.java -> .class -> .dex 转换的事实情况既微不足道也毫无损失。毫无损失的事实很重要：当GIF = PNG 时，跟受损的JPG文件就不等了; 它解码不出完全相同的信息。如果JVM和Dalvik都各自独立，你很难写出一个相对简单的工具将一种编译过的代码转换成另一种；而且不做任何妥协：不丢失信息，不使用冗余来补偿某种特征在一种VM中是first-class而在另一种中却不是的情况，不需要额外的runtime层 上在一种VM中实现另一种VM的核心API。
(我知道dx转换器有多么的复杂。我看过它的源代码。那个字节码转换器是一个巨大的，全功能的反编译/重编译器，通过SSA构造完成。但是这个转换器在概念上仍然是无足轻重的；从Java字节码到Dalvik字节码的映射在设计上是很平滑的。堆栈相对于寄存器架构中细节上进行了优化；而重要的东西，例如VM层的类型系统是完全一致的。)
VM相当
这Dalvik 和 JVM 的相当也是很容易看清楚的。并不只是源代码或字节码格式上的问题：它们的runtime对等物上也一样。一但一个Android class被加载到Dalvik VM里，它就会像Java class一样运行，像Java class一样工作。如果你懂得Java编程(深入到高级的，底层的细节)，你也就懂得Android编程。你只需要学一些新的API和框架概念。他们是对等的系统。
是否记得微软的.NET
当.NET刚出世时，Java阵营迅速的反击指责.NET是对Java的剽窃。我也是其中的一份子，但今天我看问题更清楚了。是的，它过去是个严重的剽窃产品；C# 1.0 就是一个 区分一种语言和另一种语言最简单的方法就是看它们的惯用风格 —— 例如toString() 相对于 ToString()。 但在最重要的VM规范里，微软做了很大的功课。它的CLR,CLI,和核心框架，都非常的不同于Java，所以我们不能说JVM = CLR这个等式。你不可能使用一个简单的文件格式转换工具把你编译好的Java class转换成能在.NET runtime上运行的代码。
要证据吗？你只需看一看IKVM就知道了。这是一个非常有趣的项目，它能够使Java和.NET跨平台兼容，于是，你的Java代码可以在不做修改的情况下在CLR(或者是等效的.NET runtime，比如Mono)上运行 但IKVM并不是一个简单的、类dx的 文件格式转换器。对Java class的转化、对Java核心API的适配，都是十分的复杂，即使对一个简单的HelloWorld程序也是这样。各个平台的内部机制，如反射，安全，并行，异常处理，字节码验证，I/O，以及其它核心API，特征上大致相同，但是在细节上完全不同，一些死胡同的情况会迫使IKVM不得不钻越一个又一个的火圈来让Java代码运行到了.NET VM上。它需要依赖于一个巨大的额外的runtime层，来适配从OpenJDK源代码里来的完整JavaSE API。我大致的关注IKVM的开发已经有数年了 —— 我阅读这精彩的IKVM 博客 – 所以我完全清楚他们为了让Java程序和JavaSE应用适配到.NET上所做的巨大的努力。(这项工作仍然没有完工；而且很多部分都需要以丧失某些性能为代价。)
(老的Visual J++ Visual J# 也不是一个简单的 Java-to-.NET 转换器。我不想讨论它，但我们完全可以说Visual J# 对Java的兼容并不比最早期的IKVM强多少。)
我把P = NP引进来了讨论；有些人把图灵等效(Turing-equivalence)理论引进来，说任何图灵完备的平台/语言/VM都是相互等价的。这也没错， 但与本论题无关。图灵模型这种方式太泛化了；使用这种表面价值来考量会把更个软件专利系统摧毁(尽管这不是个坏事！)。我们需要在地上为JVM等效画条 线，一条更接近实用需求而远离图灵等效的线。按我的观点，这微不足道的二进制格式转换，穷尽的高层源代码和runtime的兼容，使Android明显的 处于Java等效的这条线内。
APIs 和 Runtime 相当
Android使用了一个相当大的JavaSE APIs子集。这些APIs (来自于Harmony项目)都是全新的实现，但它们是以JavaSE为模子。如果不是因为TCK许可证问题，Harmony完全可以取得JavaSE认 证。但这并没有改变这样的一个事实：Harmony 和 JavaSE APIs是 完全的等效的 —— 这是特意的，不是偶然的。就像Charles Nutter——有名的JRuby人物——最近写道：
Android支持一个不完整的(但相当大的)Java 1.5 类库子集。这个子集大到一个复杂的JRuby项目几乎不经任何修改就能在Android上运行，很少有限制情况。看起来Dalvik对JVM是如此的接近，它不得不完全兼容大部分的JVM规范，包括完全详细的JMM (就像Android支持Java风格的线程和并发，已经深入到了高级的java.util.concurrent包里了)。可为什么有如此多的Dalvik是个新VM或Dalvik不能运行Java类 的说法呢(90%的讨论这场诉讼的论坛和博客都持这种观点)。
最后的思考
这篇博客并不是关于Oracle和Google诉讼官司的法律依据的。我将会忽略(我会删除掉)那些跑题的评论(跟Android = Java不相关的话)。我只是讨厌那些Android跟Java完全没关系的胡说八道;Google和 Android的拥护者必须要找一个更有意义的论据。(我将拭目以待这场官司的进展，带着我所有的预见，直到所有细节和最终结果都出来。除非你有内部消息(我没有)，不要太天真、保持冷静。 我们并不知道Oracle的 或 Google的；真正的全部动机和计划。我们并不知道这荧幕背后的故事，自从2007年Google首次宣告Android的诞生(这导致了JavaME生态环境的崩溃), Sun就痛恨不已，但最后还是不得不夹着尾巴行事。我不相信任何一个有10亿美金的股东控股公司会有利他主义的动机：Google不会，Oracle不会，即使我喜爱的老的Sun公司也不会。我们等着看吧。)
我不相信Google没有能力创造出一种既不背离Java太远，又以Java风格为基础的平台(就像.NET做的那样)。 Dalvik，以及Android框架，它们可能是在权衡了与大量的现有的Java程序，类库，Java天才，和Java工具链高度兼容的愿望的最后结果。微软在一咬牙一跺脚后放弃了现成移植Java带来的好处，创造了全新的.NET。Google没有这样做。
这个Android = Java等式显然并不是包括所有的东西(不是一一对应的)。每种平台都有自己一些独特的API，当然，Android是一个完整的操作系统，包括一个 Linux-based的内核，图形系统和电信堆栈，等等。很显然，我只是谈论其中最常用的部分：Java为中心的用户使用区/依赖于Java源代码、 Java classes(切不管什么格式)、Java APIs(包括成千上万的常用JavaSE APIs)和出色的类Java的虚拟机的应用框架。对于Android和其它的Java平台之间的关系有个准确的说法，就是使用版本的概念。我曾记得有个博客说过这样的话Android里没有J。那么我现在说也不晚：我建议把Android改名为Java GE(Java Google Edition)。这样一来就再也不会导致混淆了。
上文英文原文。
美国能禁止编程语言或编译器授权吗？
如果美国禁止向中国出口CPU，那么国内电脑将只能选用国产芯片。如果美国撤销编程语言或编译器的授权，那么是否咱们还得自己发明一套编程语言或编译器呢？
唯一能约束一种编程语言的就是专利，但C语言等目前并不受任何专利约束。Bell实验室最早实现了C语言和Unix，但是其未能通过专利的力量阻止其他平台上C语言的实现和使用，未能阻止BSD和GNU的出现，未能阻止Unix大战，使得最后正统意义的Unix不复存在。后来从开源社区诞生的语言比如Python、Ruby、PHP、Go等，原本就不受专利约束，任何人都能自己实现它。
当然仍然受专利约束的编程语言是存在的。比如Java在Oracle的手上，仍受专利约束，所以才有了上面旷日持久的Oracle诉Google案。如果发生新冷战，到时候可能不能合法地使用Java了，像C#、Delphi、VBA等由商业公司创制的编程语言可能也将不能使用，只要他们随便在专利或者授权上找一个把柄就可以了。x86、ARM指令集也是受专利保护的，这就使得这些处理器的汇编语言也有可能不能合法使用。
至于编译器，可以去了解一下GPL协议。现代编译器一般分为前后端，即使后端代码生成部分不能再生成x86、ARM汇编代码，我们也能通过合法使用开源协议来为我们的自主架构，或者RISC-V等开放的架构开发自主的代码生成模块。而对于GCC、LLVM而言，其他东西本身是开源的，假设编译器原有代码本身不侵犯其他企业的专利，GPL协议并没有什么国家安全的特例之类条款，只要保证能够不关闭其源代码，因制裁被禁用的国家就可以随便用。