neal gafter_与Neal Gafter讨论Java的未来

neal gafter

5月底，我参加了在巴黎市中心“大雷克斯”举行的首届“下一步是什么”会议 。 两位主要演讲者之一是Neal Gafter，他是Java SE 4和5语言增强功能的主要设计者和实现者，现在可在.NET平台语言上为Microsoft工作。 我很幸运能够采访他的InfoQ，以下是我们谈话的笔录。 尼尔在演讲中表示，Oracle对Sun Microsystems的收购总的来说对Java来说是一件好事，他说“创新在负责人的情况下最有效”，因此，我首先请他就Oracle对Oracle的处理提出意见。 Java社区。

Neal Gafter：好吧，我认为社区是Oracle收购中最不积极的方面。

我认为他们仍然在做很多事情。 我的意思是，我可以告诉您许多他们说他们正在努力但还没有完成的事情。 他们正在尝试公开开发规范。 他们承诺-从根本上说，从现在开始，所有JSR都将公开运行。 所有专家组邮件列表都是公开可读的。

然后，他们推出了JSR-Project Coin和Project Lambda。 他们正在进行中。 然后，他们进行公开审查。 专家组的讨论都不是可读的。

我对他们说，我很乐意在将专家小组讨论作为参考之后，就这些问题提供详细的反馈，因为许多决定的依据将被揭示并且可以理解。以专家组的讨论为参考。

答复是：“我们正在为此努力，我们会把它交给您”。 不是专家组说：“我们不希望这个公众”。 专家组很高兴将讨论公开。 Oracle说他们希望将其公开，但是他们还没有做到。

因此，公众审查期结束。 而且仍然无法访问。 他们正在为修订Java语言规范而在JSR上工作，我对此进行了回顾。 那甚至不是一个专家组。 只是Alex Buckley和Oracle语言团队通过修订规范来修复规范错误。

因此，他们[Oracle]说，“这里是我们认为已在此版本的规范中修复的错误的列表，这是修订后的规范”。 我从该列表中删除，然后去了网站查看这些错误-这些错误是不公开的。 因此，我什至不知道他们认为已修复了哪些错误。 我怎么知道？

我没有足够的信息。 他们说：“哦，这是一个错误，应该将它们公开发布；我们将继续努力”。 然后公众审查期结束。 然后一两个星期后，他们说：“哦，现在可以看到这些错误了”。 但是现在要在公众审查期间获得任何公众反馈为时已晚。

现在，当然，无论是在公共审核期内还是在公共审核期内，他们都乐于收到反馈。 公众审查期是一个正式的时期。 他们将很乐意随时获得反馈。 因此，在语言规范的特定情况下这只是一点。 但是，它们并没有像Sun Microsystems那样关注外部。 他们更加注重内向。 他们有自己的开发人员。 他们不希望Oracle之外的人像Sun Microsystems希望的那样努力。

现在，实际上，大部分工作还是在公司内部进行的-它总是会做，而且可能永远都会做。 但是Sun确实确实尝试了使社区参与并使他们参与进来，而Oracle并非如此。 我认为他们大约有两只左脚。 他们只是很笨拙。 而且我认为他们正在学习。

InfoQ：您认为他们正在尝试解决此问题吗？

Neal Gafter ：我认为他们正在努力。 我不认为这是恶意的。 我认为这可以归因于无能。 我只是认为这是一个社区，与他们过去所使用的社区大不相同。

他们正在学习如何参与。 这是一个艰难的开端，但我认为他们真的想使它起作用。 他们真的想与社区成为良好的合作者，而他们只是想方设法做到这一点。 与其说是技术问题，还不如说是Oracle内部的管理问题。

如果他们想宣布某件事，或者想建立一个公共邮件列表，那么他们就没有管理机制。 而且公司规模足够大，他们不能仅仅让人们自己做。 他们必须有一个程序来批准和制定这些东西。 而且这个过程还不适合他们现在正在尝试做的事情。

所以我认为他们会解决的。 我认为随着时间的推移它们会变得更好。

我们现在的位置当然令人不舒服，但我认为他们希望与社区成为良好的合作者。 他们想建立一个社区。 他们希望该社区存在，因为他们比其他任何人都受益于社区。

这符合他们的最大利益。 因此，我希望情况会更好，并且我经常给他们一些困难，但我知道他们正在努力。 我将继续给他们艰辛的生活，即使他们有所改进，因为总有改进的余地。

但是我认为他们正在朝着正确的方向前进。

InfoQ：我敢肯定您已经多次问过这个问题，但是现在您在为Microsoft工作对我来说很有趣：显然，Microsoft与Sun之间的关系非常糟糕。 出于各种原因，它变得更好了，但是如果没有其他原因，让某人从事C＃并积极参与Java的塑形在政治上很有趣。 那如何运作？

Neal Gafter：嗯，这确实不是我工作的一部分。 我的意思是，Java与我为Microsoft做的事情无关。 我这样做是因为我在乎。 我这样做是因为我很感兴趣。 我这样做是因为我有很多朋友参与其中。 您知道，这是我生命中很重要的一部分，我在乎它的去向。 从微软做事的方式中可以学到很多东西，这对Java来说是很有价值的一课。

Java的许多烦恼是C＃已经经历的烦恼。 Java今天尝试做的许多事情都是C＃想做的事情，然后又做了，现在做得很好。 但是，即使在C＃世界中，也不是完美无缺的。 我的意思是，有些事情我们已经学到了。 Java可以从中受益。

因此，据我了解，我可以回到Java世界，比如说，您是否研究过C＃在使用异步语言功能？ 您是否看过Lambda表达式在C＃中的工作方式？

您知道，例如，并发模式操作在C和LINQ中的工作方式。 我认为这些都是对Java世界非常有用的课程。

InfoQ：我猜想，在C＃中您有一些优势，因为当您添加一些重要功能时，C＃的受众会减少一些，因此更容易打破向后兼容性和类似的东西。 还是更多的是哲学上的差异？

Neal Gafter：好吧，我认为这有一些哲学上的区别。 我猜您在说的是泛型，而不是其他任何东西。

InfoQ：是的。

尼尔·戈夫特（Neal Gafter）：因此，这只是您读者的背景：当Java添加泛型时，他们使用Erasure做到了。

换句话说，它不需要深入的虚拟机更改； 全部在编译时。 在运行时，有关泛型的所有信息或大多数信息将从实际对象中删除。 您无法在运行时将字符串的空列表与整数的空列表区分开。 它们在运行时的表示方式完全相同。

这样做的原因之一是我们希望能够丰富现有的库-库的客户和库的实现者独立。 我们不想要求特定的订单。 我们不想要求图书馆的供应商都具有通用前的版本和后通用的版本。

然后，如果您基于库构建，则必须具有基于每个库构建的版本，对吗？ 从理论上讲，它可能变得非常复杂。 我认为在实践中，对于图书馆供应商来说，它不会像我们担心的那样复杂。

当C＃添加泛型时，它们并没有弃用旧的收集类。 这些收集类仍然是库的一部分。 实际上，非通用集合接口与通用集合接口之间存在继承关系。 我认为，通用的扩展了非通用的。

InfoQ：好的。

Neal Gafter：因此，实际上，当您实现泛型代码时，您也会同时实现非泛型代码。 这使您具有一定程度的互操作性。 这意味着，如果您创建通用集合，则可以将其传递给需要旧式集合的对象。

您不能反其道而行之。 如果您有旧样式的收藏，则不能将其传递给需要新样式的收藏。 但是适应它并不难。 只需创建一个新集合并将所有元素放入其中并不难。

我认为，使JSR-14的工程设计变得简单并不是明确的目标。 说“我们要减少添加泛型的工作量”不是明确的目标之一。 但是，以Java的方式添加泛型的工作量要比在Microsoft平台中完成的工作少得多，因为Microsoft平台不仅在编译器方面进行了深刻的更改，而且在虚拟机和操作系统方面也进行了深刻的更改。运行时库。 我的意思是，它遍及整个系统。 这是对系统的更彻底和广泛的改变。

从技术上讲，它不会破坏任何现有的库，但是，如果您要迁移库以使用泛型，则必须经过一个步骤，在此过程中，您将实际进行迁移。 我认为，如果Sun对用户采取与C＃相同的方法，那将不会是一个沉重的负担。 对Sun来说，这将是[极大的努力]。

Sun将有更多工作要做，而实际上他们没有资源来做。

InfoQ：对。

Neal Gafter：至少不在那个时间范围内。 要像Microsoft那样真正实现它，可能要花几年或更多的时间，因为Microsoft在.NET平台上一直比在Sun中具有同等的资源更多的工程资源。微系统。 现在，就功能点而言，人均Sun Microsystems的确比Microsoft完成了更多的工程工作。

我认为Microsoft通常会设计，测试，集成程度更高的系统-绝对经过更仔细的审查，并且与Sun所拥有的资源相比，该系统的所有部分协同工作都更加干净奉献。 例如，在1.1中，Sun Microsystems同时向该平台添加了内部类和序列化。 我实际上并没有从事这些工作。 但是据我了解，这些团队确实将它们视为独立或正交的功能，但事实并非如此。

它们不是正交特征。 因此，它们之间的交互从未像现在这样舒适。 我的意思是，这些功能之间的边缘确实存在薄弱环节。 而且，如果您有更多的时间，更多的资源，更多的测试和复查，则可能会花费更长的时间，或者开发成本会更高，但我认为您最终可能会得到更好的选择。 我在C＃方面的经验是，从很多方面来说，它是比Java更坚固的设计，而泛型就是其中的一个例子。

那能回答您的问题吗？

InfoQ：是的。 在Java中运行了很长时间的争论，我想它也在.NET中运行，这实际上是您是否应该继续添加功能的争论。 是否存在由于添加新功能而使您的语言变得足够复杂而您应该停止的一点？ 每个人都抛出的示例是C，它确实已经有一段时间没有发展很多了，但仍然是一种广泛使用的语言，可能就是因为这个原因。 与C＃之间的对比尤其明显，尽管有许多非常Swift的变化。 你站在那？ 您对此有何看法？

Neal Gafter：我认为变革是必要的，但必须非常谨慎地进行管理。 出于多种原因，在Java中比在C＃中更困难。

第一：资源限制。

第二：Java没有像C＃那样对语言进行长期规划。

C＃非常清楚-我的意思是，有Anders Hejlsberg。 他是语言和平台的架构师。 他的设计意识很强。 实际上，就他与与他一起工作的人的协作方式而言，他的态度非常轻松。 但是对于语言的去向和方式有长期的看法。 并且考虑到的每个更改都首先要考虑该语言是否朝着该方向发展，或者它是否只是因为一方愿意而只是另一面的问题。

您可以做很多事情，某人会满意，但大多数人不会从中受益。 当您添加某人无法从中受益的东西时，对他们实际上是不利的。 即使他们不必使用，查看或关心它，对于他们来说，这也使系统变得更加复杂。

因此，我们在Microsoft内部进行思考的一种方式是，每种语言建议的起始点均为负1,000点。 而且，您甚至必须在积极的方面奋战超过负1000点，并且值得被认为真的被添加到了该语言中。 在某一点上，我知道这是负100点，而现在是1,000点。 因此，杆会移动，因此更难。 而且应该很难添加一种语言。

甚至C编程语言也发生了变化。 有一个标准委员会。 标准的新版本问世。 随着时间的流逝，语言也发生了真正的变化。 与例如C ++标准委员会相比，C委员会对这些更改更为保守。

C ++标准委员会在考虑使用什么语言以及拒绝使用什么方面更为慷慨。 您知道，我认为确实存在保守主义的原因，但我认为，我们今天使用的任何语言在不接受某种程度的变化的情况下，都不可能保持至关重要。

同样对于Java来说，更改变得更加困难的原因之一是，许多更改通常说来都是好主意，但是这些更改的添加方式并未考虑语言的未来发展。 这可以追溯到我的长期观点。

泛型可能是一个很好的例子，当人们过渡到添加泛型的版本时，人们担心库的迁移。 使用擦除可以使特定的过渡更加容易。 问题是，Erasure使将来添加其他语言功能变得更加困难。 例如，将擦除类型作为泛型的一部分，将功能类型添加到编程语言要困难得多。

InfoQ：如果我没记错的话，你曾经在一篇博客文章中指出，你仍然可以解决这个问题。 您可以创建不依赖Java中的Erasure类型的泛型版本。 我说对了吗？ 我想我记得读过。

Neal Gafter：对。 所以我建议您实际上可以同时拥有两者。 但是您最终将获得非泛型，并且将擦除泛型类型参数，并对其进行了整形化，但是您将永远不会摆脱Erasure。 某些类型参数将始终被擦除，而某些类型参数将永远不会被擦除。

问题在于，对于“擦除”干扰语言的未来发展的方式，这无济于事。 它仍然在那里。 而且，它以前与语言干扰的方式仍然会与语言干扰。 对于那些特别希望能够使用泛型并因某些特定的事情而希望对其进行修正的人来说，它将为他们提供帮助。 但是您在很多事情上仍然受到Erasure的阻碍。 而且我知道有些人正在研究[问题]我们可以得到多少最小的破损以证实今天作为泛型的东西。 我们能做到而又不破坏太多吗？

这是一个非常困难的问题，但是有些人有信心，他们也许可以在这方面取得一些进展。 如果他们成功了，将会有一个发行版本，其中某些通用代码在技术上可能被破坏，但过去一直有效，它将不再起作用。 但是，将来您可能会泛化泛型。 如果可能的话，我认为那会很棒，但是我有点怀疑。

InfoQ：是的。 我很努力地自己看，但是很有趣。 Stephen Colebourne等人认为，Oracle应该有效地生产Java的非向后兼容版本。 因此，去修复我们出错的地方，并可能维护两个版本。 所以...

Neal Gafter：好的。 微软已经做到了。 它称为C＃。 好的。 我的意思是，我想问一个问题，为什么应该是Oracle？

为什么将其称为Java？ 您知道，它与Java有什么共同点？ 它不是Java编程语言。 如果不向后兼容，则不是Java编程语言。 如果您希望它在Java VM上运行并且要使用泛型通用化，那么您会遇到问题，因为泛型通用化需要VM支持。

因此，如果它是新的VM和新的编程语言，那么Oracle与它有什么关系？

你知道，那是我的问题。 我当然认为Java以外的语言还有空间。 如果我不相信这一点，那么我现在不会在Microsoft工作。 但是，即使在Java虚拟机上，也有一些Java的出色替代品，例如Scala。

您知道，如果我在VM上工作并且可以选择使用的语言，Scala在我的首选项列表中将非常重要。

InfoQ：您认为我们应该注意的语言正在出现什么趋势？ 您提到Scala是一种面向对象的功能混合对象，而我猜想在.NET中使用F＃也有类似的事情。 您认为功能之外的下一件事是什么？

Neal Gafter：好吧，超越功能了吗？ 我认为这有很多方面。 通过这样的回答，我有点回避这个问题。

但是我确实确实认为，尤其是对于Java和C＃以及以更命令式风格开始的语言而言，在解释函数式编程社区的思想方面还有很多工作要做。 而且我认为这将需要数年的时间才能被开发出来。

而且我不认为Java或C＃可以达到您的期望。 我认为它们永远不会成为函数式编程语言。 我的意思是，它们具有某种必然需要的风格。 使用功能惯用法有很多好处，特别是使用不变数据编程时。 我认为，为了真正利用并发并使用良好的旧锁和信号（您知道，这是最早的Java版本中的那种东西）来实现，它就不切实际。

您不能以这种方式并发构建大型系统。 好吧，也许可以，但是我不能。 对于批量数据操作和不可变的fork join并发编程，问题是共享的可变状态。

解决方案是您不共享或不变异。

功能风格表明您不会变异。 您不会改变自己的状态。 您使用不可变的数据。 为了支持该样式，需要用Java语言完成一些事情。 库中有很多事情要做，支持库中有很多事情要做。 与那些被广泛使用的编程风格相比，我们还有很长的路要走。

InfoQ：那么您认为我们有效的编程方法需要改变以利用多核等吗？

Neal Gafter：是的。 而且我认为这不会发生革命。

我认为实际上是这样。 您知道，我们发现我们存在性能问题或可靠性问题，并且使用更具可扩展性的样式替换子系统。

InfoQ：是否像Actor模型或Erlang之类的消息传递之类的当前方法对您而言特别适合Java或C＃？

Neal Gafter：我想可以，但是我认为这要求该语言朝着目前没有人计划的方向发展。 模式匹配是使Actor风格值得的一件事，Scala通过案例类获得了模式匹配。

今天，没有人考虑为Java做类似的事情。 我认为对于Java应该值得考虑，但我认为需要长期制定“总体规划”，而且我很容易看出这将是Java的一个组成部分。

但是，如果没有计划，没有长期计划，您将永远无法到达目的地。 我不认为有人会说：“好吧，在版本x中，我们将添加Actor”。 需要有一个长期计划。 现在用Java构建表示不可变数据的类很尴尬。 那将必须更容易。 进行模式匹配将更加容易。 我不认为以当前形式进行序列化是传递不可变数据的理想方法，但也许可以，对吧？ 如果将其应用于今天不存在的不可变数据类型，则可能是正确的机制。 但是对于Java来说，今天还不是。 这似乎不太适合。

我认为被视为未来的一部分肯定很有价值。 但是我还没有听说过Oracle中有人谈论Java。 因此对于Java 7或8来说肯定不是。如果发生类似的事情，那将超出该时间范围。

但是我认为，如果您希望以这种风格进行编程-并且以这种风格进行编程有很多好处-那么（特别是在今天，无论如何）选择一种自然的语言会更好。 在像Java或C＃这样的语言中，必须先进行太多更改，然后才能在该语言中轻松表达该样式。 因此，将Scala用于这种编程风格，或在.NET平台上使用F＃。

InfoQ：我猜想.NET平台和Java平台的另一个共同趋势是对Java和C＃以外的语言的支持。 两者兼而有之，但微软在一开始就更加强调它。

Neal Gafter：当然，您可以在Java中看到这一点。 名称java.lang.Object，对吗？

InfoQ：是的，是的。

Neal Gafter：应该是所有语言的对象，但是事实并非如此-最初没有人想到这一点。

InfoQ：是的。 因此，John Rose一直负责该Java项目。 作为达芬奇机器项目一部分的其他事项-尾递归-如果您可以执行下一个，您下一步将做什么？ 那会是什么？

Neal Gafter：您可能试图在整个方向上完成几项不同的事情，以支持动态语言。 其中之一是VM中的一些东西，可以简化实现动态语言的过程，而这正是Da Vinci项目一直关注的重点。 您知道吗，我们可以投入什么来支持各种编程语言？ 但是另一件事是使语言在平台上更易于相互操作。 这是Microsoft使用DLR以及将dynamic作为一种类型来支持C＃编程语言中的语言互操作性的重点之一。

这个想法是微软所做的，它使这些语言不仅可以高效执行，还支持有效的动态调度，而且还具有元对象协议，以便来自一种动态语言的对象可以具有一些合理的条件。语义从另一种编程语言中使用时，这样您就可以在具有某种合理语义的语言之间进行互操作。

因此，我认为可能在VM或VM上方的贴面处添加元对象协议对于动态语言之间的互操作很有用。

InfoQ：这是您在.NET中所做的，不是吗？ 这是CLR上方的图书馆。

Neal Gafter：是的。 好吧，实际上CLR中有一些支持，但主要是CLR之上的库，是的。

然后第二件事就是Java编程语言的支持。 如果以C＃风格完成，则基本上是一种称为“动态”的类型，其基本意思是“在运行时确定语义。让我在编译时执行我想做的任何事情，但在运行时确定语义” 。 这样，您就可以与由动态编程语言创建的对象进行互操作。

因此，我认为拥有动态的元对象协议是一个非常有用的方向。

我很想在VM中看到很多支持动态语言的东西，是的，尾递归就是其中之一。 这不是一个大问题，但是对于某些编程语言而言，它却起了很大的作用。

也分段堆栈。 现在，这对于Java和C＃都是一个问题。 这些平台消除了C和C ++等本地语言的许多可靠性问题。 您不会发生索引超出范围的错误，因为您的索引已检查并且得到了异常。 您无法覆盖已释放的内存，也不能写入未分配的内存等，因为您无法自己管理内存； 垃圾收集器为您完成。 但是这些平台目前不能很好地完成的事情之一就是处理堆栈溢出。 而且由于错误，堆栈溢出并非总是会发生。 它并不总是会发生，因为您有一些本不希望拥有的无限递归。

有时会发生堆栈溢出，因为您具有自然递归的功能。 我使用编译器，仅通过编写in i = 1 + 1 + 1 + 1并执行数千次操作就很容易使Java编译器崩溃。 语义分析器将尝试进行分析，或者解析器将尝试对其进行分析，这只会使堆栈崩溃。 而发生的是，该过程崩溃了。

你知道的，这没有很好的恢复。 您可以通过说“嗯，我们再次从头开始，但我会分配更多的堆栈”来修复它。 问题是，您不一定事先知道要分配给任何给定线程多少堆栈。

像Google的Go系统这样的分段堆栈的优点是您不必提前决定。 它根据程序的需要动态调整。 它使某些软件更易于编写。

线程在Java中很昂贵，之所以将它们全部合并，是因为它们很昂贵。 如果它们不贵，就不会合并它们。 而且它们之所以昂贵，是因为堆栈已预先分配。 有很多堆栈，有很多资源。 您不希望用完它，对，所以您要分配这个大堆栈的东西。 如果您有分段的堆栈，线程本身将便宜得多。

随着线程的便宜，很多事情变得更加容易。 您知道，异步-人们认为异步编程，状态机编写和协程很多。 如果线程足够便宜，那么您就不需要做任何事情。 您只需创建一个线程并让线程等待，因为它在等待时不消耗任何资源。

它甚至没有在虚拟地址空间中分配堆栈。 因此，我认为考虑为Java做类似的事情很有价值。

那将对该平台产生微妙的影响，但我相信它将产生深远的影响，这将是非常有益的。 随着继续发展平台，这会对您认为需要或不需要的各种事情产生影响。 因此，我将投票支持这一点-分段堆栈。 而不是例如在VM级别上使用协同例程。

InfoQ：非常感谢。

关于被访者

是Java SE 4和5语言增强功能的主要设计者和实现者，他的Java Closures实现获得了OpenJDK创新者挑战奖。 他继续谈论SE 7和8正在进行的语言更改。Neal以前曾在Google的在线日历中工作。 他是C ++标准委员会的成员，并领导了Sun Microsystems，Microtec Research和Texas Instruments的C和C ++编译器的开发。 如今，Neal在.NET平台语言上为Microsoft工作。 Neal是“ Java Puzzlers：陷阱，陷阱和特例”的合著者（Addison Wesley，2005年）。 他拥有博士学位。 罗彻斯特大学计算机科学专业。

翻译自: https://www.infoq.com/articles/neal-gafter-on-java/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

neal gafter