甲骨文vs谷歌

这单公案其实属于美国人民内部矛盾，属于逐渐式微的老派数据库霸主对移动计算时代风光无两当红炸子鸡的浓浓恶意：

两家公司自2010年以来一直就该争端在诉诸法庭，当时甲骨文起诉谷歌时声称后者在它的安卓（Android）移动软件中使用了甲骨文的Java软件中部分代码。此案现在已经经历了两次联邦法院审判，并且地方法院的判决还曾遭遇上诉法院推翻，该案还曾在美国最高法院有短暂逗留。甲骨文在该案中寻求来自谷歌高达90亿美元的侵权损害赔偿。

2010年1月份，甲骨文完成了对Sun微系统公司的收购，后者是Java程序语言及平台的开发商。那年的8月份，甲骨文起诉谷歌，声称谷歌的安卓（Android）使用Java相关技术是对甲骨文版权和专利的侵犯。2012年，华盛顿特区地方法院的判决有利于谷歌，声称所谓的Java API不属于版权。不过对于谷歌来说不幸的是，一家上诉法院推翻了那次判决，并且美国最高法院拒绝对该案进行听讼。

Google当年为了加速发布安卓系统，并且创造一个对开发者友好的开发环境，选择了Java作为手机操作系统上应用程序的开发语言(Sun: 欢迎使用！），看中的是庞大的开发人员基数。Java面世20年，在服务器领域大显神威，工业标准可不是说着玩儿的。大把程序员靠java吃饭，Google推出基于Java的SDK，等于一次性向所有Java背景的程序员敞开大门，相比之下“一次编码，处处运行”的语言特性就显得不是那么重要了——好吧，除了安卓也没别的平台让你运行。

Java很好很强大，但在安卓上没用了

08年那会儿搞移动应用开发，除了苹果用的Objective C，就是诺基亚Symbian上基于C++的Qt框架，再有就是那一坨运行在功能机上的嵌入式J2ME了。当时Google除了自建一套Java虚拟机，并没有更好地选择。

而今天就不一样了：首先，“一次编写，多端发布”的理念已经深入人心，对图形效果没有特别要求的应用，会选择React Native进行开发，经过编译后生成的都是原生系统控件，和使用Android Studio/Xml设计出来的原生UI毫无二致(感谢Facebook!)。

其次，对于占据移动应用半壁江山的游戏，Unity3D/Cocos2D等游戏引擎，把通用app之外的游戏/娱乐类高交互性app给包了圆，和React Native一样，使用这些引擎，都只需要用一种编程语言写一遍代码，就有了多个平台发布的能力，官方、社区支持都极为专业和活跃。用Java写的游戏引擎如AndEngine基本都无人问津。

再次，随着移动设备性能逐渐赶上台式机：2.2G CPU + 8G RAM，HTML宿主webview的体验已经和原生系统极为接近，Reactive Native 说是用javascript开发，但Virtual Dom/redux/flux还是有一定学习成本。Ionic的出现，使得原来大批前端工程师——熟悉js/html/css——就可以无缝迁移到app开发中来，这一批开发者数量和当年的Java基本盘比起来，多了何止一个数量级。

未来？用啥都好

所以未来移动开发领域，除了维护遗留系统，基本没Java什么事儿了。

有小道消息说Google准备转投已经开源的Swift，如果是真的，苹果也乐得看到自己的亲生儿子大展鸿图。而Google自己的亲儿子Go，也被开发者寄予厚望。哪种语言都好，不过，原生开发语言SDK，还有多少开发者真的需要呢？