热点｜HOT
OpenJDK将对Android开发产生怎样的影响
Google已决定将从下一版本的Android开始采用OpenJDK，本文将部分摘录互联网上对于这一决定的反响。
在去年年底，我们曾提到Google已经决定在Android中使用OpenJDK，以取代基于Harmony实现的Java库（详情请见此处）。尽管这条消息在宣布时恰逢圣诞期间，但Google的这一决定还是在互联网上引起了很大的反响，我们将在本文中对于这些观点进行一次总结。
从这个Git工单可以看出，早在2015年二月，Google就已经在代码中露出了切换至OpenJDK的计划。在去年十二月，这次代码提交中所包含的一个重要的授权信息的变化被媒体曝光了。Android N中所使用的新Java库将不再基于Apache License 2.0（APL）授权协议，而是基于GNU GPL 2协议，并且在版权信息中包含了以下声明：“Oracle及其附属机构版权所有，1997,2011”。
Mozilla的前任CTO Andreas Gal为此专门写了一篇标题有些骇人的博客“Oracle将它的魔爪伸向了Android”。他表示，Google长期以来一直坚持使用Harmony的Java库及Apache授权，其原因在于：用户能够任意使用及修改APL代码，而无需发布这些改动。换句话说，你能够进行具有专利权的改动与改进。而这一点对于基于LGPL授权协议的GNU libc来说是不可能的。我可以确信地说，我知道为什么Google认为这一点很重要，因为在发布Firefox OS的过程中，我曾经和许多与Google有合作关系的芯片供应商以及OEM厂家进行过交流。芯片与OEM厂商都希望在软件层面上表现出他们的优势，尝试对Android的代码进行全方位的改进。尤其是芯片厂商经常会改动类库中代码，以充分利用自家的专利芯片，而且他们不愿意公开分享这些改动。通过这种方式能够体现出他们的竞争优势，即在专利上的优势。
Bob Ross回复了Gal的文章，他自称是某家OEM厂商的员工，对于APL与GPL的争论提出了一些见解：我们确实会对libcore进行一些改动，在这种场合，主要问题是进行开源会带来很大的工作量，倒不是说要保护这些代码。至少从我曾经参与过的改动来看，情况就是如此。
Bradley M. Kuhn目前担任自由软件管理机构（Software Freedom Conservancy）的主席，同时也是自由软件基金会（Free Software Foundation）的董事会成员。他对于GPL可能对Andoid开发所造成的影响有着不同的见解。在最近的一篇博客文章“Sun、Oracle、Android、Google以及JDK复制权（copyleft）的质疑”中，Kuhn注意到OpenJDK授权其实属于一个“非常宽松”的协议，即包含Classpath例外的GNU协议。Kuhn曾经参与了Classpath例外协议的设计与命名，这一协议旨在避免通过复制权保护的方式“感染”整个Java生态系统，否则所有的Java程序都将被迫选择可以免费使用及重新分发的方式。如此一来，从授权协议的角度来看，选择使用OpenJDK与使用Harmony也没有多大的区别了。
按照Kuhn的说法，采用了Oracle的GPL及Classpath例外协议的JDK与具备Apache授权的Java userspace又有多大的差别呢？它们的差别其实并不大！Android的重新分发者已经在kernel space方面承担了很大的复制权责任，并且请你记住，Webkit是基于LGPL授权协议的，所以说围绕着Android已经存在着一些比较宽松的复制权遵循责任了。如此一来，如果说某个重新分发者已经满足了以上协议，那么要遵循那些新加入JDK代码中的需求也不是什么麻烦事，因为这些需求只有更为宽松。
但在Gal看来，Oracle对于Android的未来发展将产生重大的影响，这不仅仅是因为授权的原因，同时也受到Java的发展路线、商标、条约与专利的影响。
除了源代码之外，Oracle还有别的方法可以控制Java的发展，因此OpenJDK所谓的自由性就好像一所监狱。你可以投票决定外墙有多高，甚至可以去参与砌墙工作，但一旦你进入这里，就只有Oracle能够决定你何时才能出去。Oracle对于OpenJDK的路线图有很大的决定权，通过对于兼容性需求、商标、现有协议以及API版权控诉（Oracle与Google之间的控诉）的掌握，Oracle几乎全盘控制了OpenJDK的发展方向。
部分读者在Gal的博客中留言表示，如果Oracle不能胜任OpenJDK的发展，那么Google完全可以创建一个分支，并自行决定它的发展方向。
Gal同时预测，对于Android来说，接下来的一年注定是艰难的一年。
由于代码与技术的混杂，这将在战术层面上牵连Android的开发。不夸张的说，所改动的代码将达到几百万行，并且从实现方面来看，新的OpenJDK与Google原本采用的Harmony代码在正确性或性能表现上有许多微妙的差别。如你所见，Google在日期数据的处理上更正了一个针对特定边界条件的测试用例。这是由于Harmony与Oracle的OpenJDK的表现有所差别，因此必须对测试进行更正。
而Android应用的整个生态系统就建立在这些正面临着变化基础上。Android的应用商店中有几百万个应用都依赖于Java的标准类，正如上文所述，不仅必须对测试进行更正，并且由于OpenJDK的转换所产生的微妙差别，这些应用都有可能随机地发生错误……
由于这次的巨变，我感觉Android N已经很难按期发布了。Google的做法无异于在飞行途中更换引擎，此时优先级最高的任务是保证不会坠机，至于是否能够按时抵达目的地，Google已经没时间去担心这个了。
Brendan Eich在一条推文中表示支持Gal的意见：“虽然我们的所知有限，但我同意@andreasgal的看法，代码的改动将带来成本与风险的上升。”
Codename One的联合创始人之一的Shai Almog也同意Google和Android的开发者将不得不面对一些额外的工作，但并没有Gal与Eich所认为的那么严重，并且使用OpenJDK还能够多多少少让他们受益。
虽然有些改动能够让用户直接受益，但对于大多数软件开发过程来说，改动无法带来直接的受益。并且也不是所有开发者都能够完全利用每一个语言与API的特性。
由于基础代码库得到了统一，用户将从中受益，并且安全审核流程也可以专注于这个具有更高统一性的基础代码库了。其结果是许多标准Java工具在Android上或许能够表现得更出色……
没错，Google需要付出一定精力以完成这一过程，也确实会有一些应用可能会受到影响。但我敢说，这次改动比起Marshmallow（即Android 6.0）的改动所带来的影响会小的多，并且Google本身有一些工具能够让许多问题得以缓解（例如SDK版本提示）。
有些人怀疑Google决定采用OpenJDK是否和他们与Oracle之间的控诉纠纷有关。而Kuhn则相信Google这次决定的背后是出于技术方面的原因：
一位Java业界分析师（他在这一行已经有十年以上的经验了）告诉我，他相信这一决定的主要动力是技术方面的原因。在Android平台上开发userspace应用的作者们都在寻找新的Java语言实现，考虑到市面上已经存在了这个合理的、具有授权的免费软件，因此Google就有理由选择在技术上转换至这个更有优势的代码库，毕竟它为API的使用者在技术层面上提供了他们想要的东西，同时也降低了维护的难度。这样看来，这个决定是非常合理的。这种说法或许没有权威人士的观点那样令人震撼，但技术方面的原因的确很可能是这个决定的主要推动力。
Android从新版本操作系统开始将采用OpenJDK，这一举措会带来怎样的影响，目前来说还难以进行全面的透彻分析，这很大程度上取决于Oracle与Google之间争论不休的版权控诉将走向何方。目前为止，还没有人能够清楚地说明一个API接口是否能够拥有版权信息，法律与法院必须明确地解答这一点。自从上一个现有版本的库开始，Android中的部分代码，包括Java与C在内就开始了重新构建工作，某些无用的代码被删除，但依然保留了接口或头文件。那么是不是说Android从此就可以摆脱那些麻烦了呢？这还有待时间观察。不过采用OpenJDK之后应该能够起到一些缓解作用，因为Google如今已经满足了Java授权和专利许可，Oracle也不能再对Android说三道四了。
Python将迁移到GitHub
Python目前的维护者，Brett Cannon，日前在Python的核心工作流邮件列表中宣布了Python将迁移到Github中，在与InfoQ的对话中，Cannon解释了决定此次迁移花了超过一年的时间，当初主要的考虑有如下三个备选方案：
● 创建forge.python.org来托管Python的仓库；
最后到决定是选择了GitHub，主要归结为以下三个方面的原因：
GitHub和GitLab在功能方面基本差不多；但是，Cannon这里特别提到，GitLab的开源与否根本就不是决定性的因素。
活跃的开发者均熟悉Github，无论是核心开发者还是外围的贡献者。另外就是，虽然有一些开发者明确的反对迁移到GitHub，但是没有一个说如果社区就这么决定了就没有人使用Github了。
Guido van Rossum偏爱Github, Cannon考虑到尽管现在Rossum只是偶尔贡献一下，但他的影响力仍在，为了避免潜在的冲突，应当考虑Rossum的感受。
Cannon向InfoQ谈到他是如何做这个决定的：基本上我这次的所作的决策过程和原来做过的两次没有太大的不同，过程都是这样的：我向PEP请求关于问题的可能的解决办法，基于所提出的议题来进行讨论（尽管讨论通常都是流于形式的，但是PEP会自始自终都保留详细记录，有最新的建议一般都会通知到），制订各种期限，比如测试实例这样的，到那时，当我要做出决策的时候，我所基于的素材就非常的丰富了。
这里值得一题的是Python使用GitHub，仅用于其代码托管和代码审核的支持，这也就意味着Python的缺陷跟踪和维基百科不会迁移到GitHub上。
Cannon还讲过Python的核心开发者们彼此之间也是争论的不可开交。Stefan Krah所表达的观点其实是代表了开发者当中倾向于使用GitLab的人们，为此，Cannon专门进行了回复，并收到了很多未抄送给邮件列表的私聊回复，均回答了假定GitHub是首选的话大家是否会停止提交代码？他还补充到，在他看来无论是迁移到GitHub或者是其它的仓库都会有一小部分人的不适应，但必须要妥善处理。
InfoQ借机采访了Brett Cannon，希望更加深入的了解到此次决定所能带来的好处，在整个流程中目前处于何种地步。等等。
你能解释下Python和Python社区迁移到Github有何好处吗？
我目前正在写的一个PEP的草稿可以解答一部分，但是我们所期望的好处是可以做到更快速的补丁审核以及人们能够更加容易的参与到社区（真正的关键还是前者，但后者属于锦上添花）。希望是所有的工具都是或可以是围绕着GitHub所构建，能够做到为Python开发团队过去需要手动去做的大量的工作均替代为自动化，减少花时间去审核补丁的时间，从而提高生产效率。（目前我们最大的问题就是在缺陷跟踪上对于外来贡献者特别的不好，甚至让他们非常的不爽）。更何况不论是开发团队还是更为广泛的开源社区均对GitHub熟悉有加，而且我希望的是让所有人参与其中能够更加的快速和方便。
目前的状态是什么？下一步将会做什么？
说到状态，我是在2016年1月1日对Python的开发迁移到GitHub上这个决定的，现在的话我正在撰写关于我们各个代码仓库迁移所需要的所有步骤的PEP（在上一个问题的回答中我给出的链接）。一旦在我们的核心工作流邮件列表中达成共识，且PEP会更加的完善、突出一些细节。在那之后，我们就会开始我们的工作。
至于具体的接下来的工作，他们要做的就是解决掉那些个会妨碍代码仓库迁移的“拦路虎”。因为我们迁移仓库所花费的困难是取决于他们所需要的工具，我希望是首先解决掉所有仓库的通用问题，然后再根据具体的仓库问题具体的解决。
你在公告中提到邮件列表中仍然有一些争论存在，你希望以何种方式来结束这场讨论？
你指的是在我发表过决定之后在核心工作流邮件列表中的讨论吧！我对此结果非常的满意。虽然有一些人因为GitLab拥有一个开源的版本就愿意去选择它，但是所有人都理解我为何做出如此的决定，而且支持我的坚持。大家还是对此次迁移持积极态度的，而且利用此机会让我们的开发平台尽可能的保持平台无关性，在未来能够不懈的追求更加的简单（这一定能够实现，自从我成为核心开发者之后，这算是第三次改动了，而且Python到今天已经走过了第25个年头，依然保持强劲的势头，当然，在接下来的几年，我们是不会再做平台的变换的了）。
开源项目近期往Github上迁移似乎渐渐的增多，你是否有过担心，如其他人那样认为如此依托给一个商业公司是不靠谱的？你认为这会给Python带来困扰吗？
对于未来的平台发生改变的情况还是非常担心的（将来某个时候一定会发生）。但是我们将仅使用GitHub来托管代码以及用来做代码审核，前者是很容易找到替代产品，而后者的话，一旦关闭某个pull request历史，其临近的也就没有什么价值了。也就是说，我们会对代码审核的历史做备份，那么我们一旦找到替代者，我们可以得到有效的代码审核，因为审核历史是有价值的，哪怕是直有一条接受的提交。如果GitHub不能提供开放的API给我们访问数据以及提高壁垒的话，我们当初就不会考虑它。另外，诸如GitLab之类的平台会提供一些工具让你来替代GitHub，包括pull request都可以导入到他们的平台，我们知道我们并不会失去什么，但是GitHub可以给我们最快的时间。还有就是我们的缺陷跟踪系统不会迁移到GitHub上去，这就让那些担心失去控制的稍稍放松一些，缩小了一些改动的范围。