过去的爆炸……

我在2008年5月写了这篇文章……我不得不说，我的观点相当不错，包括Java 8采用了Scala的一些更好的功能：

它开始发生……围绕Scala的FUD。 Scala的危险。 使用Scala的“操作风险”。

它开始于11月，当时我开始进行电梯和Scala项目的出租。 这些问题是合理和合理的：

• 如果您在Scala中构建该项目并进行提升，还有谁可以维护它？ 答：升降机社区中有500+（11月为300+），并且升降机清单中至少3（现在为10）人正在积极寻求Scala和与升降机相关的演出。
• 提升带给我们什么？ 答：Web 2.0协作应用程序的上市时间比其他任何地方都快。
• 为什么不使用Rails，它具有出色的开发人员生产力？ 答：从个人到计算机应用程序，Rails都很出色……当您构建聊天应用程序或人与人之间协作的东西时，lift的Comet支持比Rails更有效……另外，如果您必须同时将应用程序扩展到数百个用户使用您的应用程序，因为JVM具有很大的运行优势，所以可以在一个单独的盒子上完成操作。

然后是一些不太理性的问题：

• 当我们可以将编码外包给印度并向某人支付我们所付钱的5％时，为什么还要使用新技术？ 答：因为我的时薪是我的5％，我的购买力要比您购买的编码器高20倍以上，而且我对开发工作的管理也少了很多。
• 为什么不用Java编写它以获得Java的运行优势？ 答：原型制作很难。 在知道自己想要什么之前，您需要保持敏捷。 Java不是敏捷的。 Ruby / Rails和Scala / lift是敏捷的。 选择其中一个进行原型制作，然后在有必要的情况下移植到Java。
• Scala与我们现有的Java代码不兼容吗？ 答：不。请读我的嘴唇……不。那个编写将Java转换为JVM字节码的程序（javac）的人写了将Scala转换为JVM字节码的程序。 在这个星球上，没有人能比马丁·奥德斯基（Martin Odersky）拥有更兼容的语言。

好吧……快转几个月。 购买功能已经历了原型制作，修订以及软件所经历的所有正常增长。 它可以工作（是的……还需要更多，但这就是软件版本的本质。）还有另一个开发人员（他主要写ECMAScript）选择了提升代码，并在步行2小时后对代码的核心进行了十几处修改。 -通过我和20-30个IM和电子邮件问题进行解答。 他主要从事Flash和Air工作，并发现Scala和lift非常简单。

我们也有机会同时拥有2,000个（同时在他们的键盘上敲击键盘）购买功能的用户，并且由于Jetty Continuations的帮助，我们能够通过与服务器和服务器的2,000个开放连接为所有2,000个用户提供服务双核心opteron上平均每秒有700个请求，平均负载约为0.24…请在您的Rails应用中尝试。

Buy a Feature的一位客户希望将其与其他2个系统集成到他们更大的，基于Java的Web门户中。 我做了整合。 客户问“ Scala零件在哪里？” 我回答“它在此JAR文件中。” 他说：“但是，您的程序是用Scala编写的，但是我查看了字节码，它只是Java。” 我回答“这是Scala…，但是它可以编译为Java字节码，并且可以在Java调试器中运行，您看不出它们之间的区别。” “你是对的，”他说。

因此，对于该客户的JVM，Scala和lift代码的外观，气味和味道都与Java代码类似。 如果将scala-library.jar文件重命名为apache-closures.jar，那么没人会知道其中的区别……。

好的……但是我与之交谈的每一组人，都听说过使用Scala的“操作风险”的类似变化。

让我们退后一分钟。 使用Scala存在开发和团队风险。

一些Java程序员无法绕开三重概念，即（1）类型推断，（2）传递函数/高阶函数以及（3）不变性作为编写代码的默认方式。 我遇到的大多数Ruby程序员都没有上述限制。 因此，找到一个了解某些Java库的Ruby程序，或者找到一个通过Rails或Python或JavaScript完成一些工作的Java程序员，并且您有一个开发人员可以在一周内使用Scala。

是的，Scala-land中的工具不如Java-land中的工具丰富。 但是，再次，任何可以编写Ruby的人都可以在Scala中进行编程。 Scala有一个很好的Textmate捆绑包。 我用的是jEdit。 史蒂夫·詹森（Steve Jenson）使用emacs。 感谢David Bernard的持续编译Maven插件，您可以保存文件并编译了代码。

哦……还有一个旧的Eclipse插件，该插件或多或少都可以工作并且可以访问Eclipse调试器，并且据报道新的Eclipse插件可以很好地工作。 然后是NetBeans插件，它仍然是原始的，但是每周都会变得越来越好。

即使受弱IDE支持的限制，面对面的人们也可以比编写Java代码快2到10倍来编写Scala代码，并且由于Scala强大的类型系统和代码简洁性，维护Scala代码要容易得多。

但是，回到我们的老朋友“你不能说它不是Java”之后，我编写了一个Scala程序，并使用-g：vars对其进行了编译（将所有符号放入类文件中），并在jdb下启动了该程序（ Java调试器……稍后再介绍），并设置一个断点。 这就是我得到的：

>     Step completed: "thread=main", foo.ScalaDB$$anonfun$main$1.apply(), line=6 bci=0
>     6 args.zipWithIndex.foreach(v => println(v))main[1] dump vv = {_2: instance of java.lang.Integer(id=463)_1: "Hello"}main[1] where[1] foo.ScalaDB$$anonfun$main$1.apply (ScalaDB.scala:6)[2] foo.ScalaDB$$anonfun$main$1.apply (ScalaDB.scala:6)[3] scala.Iterator$class.foreach (Iterator.scala:387)[4] scala.runtime.BoxedArray$$anon$2.foreach (BoxedArray.scala:45)[5] scala.Iterable$class.foreach (Iterable.scala:256)[6] scala.runtime.BoxedArray.foreach (BoxedArray.scala:24)[7] foo.ScalaDB$.main (ScalaDB.scala:6)[8] foo.ScalaDB.main (null)main[1] print vv = "(Hello,0)"main[1]

我的代码在标准Java调试器内部无需花哨的工作即可工作。 我所在的行的文本和本地作用域中的变量都在这里，就像是Java程序一样。 堆栈跟踪的工作方式相同。 这些符号以相同的方式工作。 一切工作方式相同。 就像Java代码一样，Scala代码在JVM上的外观，味道和味道……现在，让我们探讨一下原因。

很久以前，当Java是Oak时，它被设计为将不可信代码分发到机顶盒（以及后来的浏览器）的一种方式，这些规则定义了程序的执行方式以及指令集的含义（字节码） ）非常重要。 此外，程序的语义必须使运行代码的虚拟机能够（1）验证代码的行为是否正确，以及（2）源代码和目标代码的含义相同。 例如，Java中的转换操作会编译为一个字节代码，以检查该类是否可以实际转换为正确的东西，并且验证程序确保没有代码路径可以将未经检查的值放入变量中。 换句话说，没有办法编写可验证的字节码来将对非String的引用放入定义为String的变量中。 不仅在编译器级别，而且在实际的虚拟机级别强制执行对象键入。

在Java 1.0天中，Java语言代码和Java字节代码之间几乎有1：1的对应关系。 换句话说，您只能用Java字节码编写不能用Java源代码编写的东西（这与在构造函数中调用super有关。）每个类文件只有一个源代码文件。

Java 1.1引入了内部类，这些内部类打破了Java代码与字节代码之间的1：1关系。 内部类引入的一件事是内部类对私有实例变量的访问。 通过创建访问器方法来完成此操作，而不会违反JVM对JVM私有变量隐私的强制实施，该访问器方法是编译器强制（但不是JVM强制）的方式供匿名类访问私有变量。 但是无论如何，这时马已经离开了谷仓，因为1.1给我们带来了反思，而私有不再是私有的。

关于JVM的一件有趣的事情。 从1.0到1.6，尚未向JVM添加新指令。 哇。 想一想。 486出现时，Java出现了。 自1995年以来，已经向英特尔机器添加了多少指令？ Microsoft CLR自2000年以来一直存在，并且经历了3个修订，并且在每个修订中都添加了新说明，并且在较旧版本下编译的源代码不适用于较新版本。 另一方面，我有Java 1.1编译的代码，可以在Java 1.6下正常工作。 相当了不起。

直到今天，Java Generic还是使用与1996年相同的JVM字节码实现的。这就是为什么您会收到“类型擦除”警告的原因。 编译器知道类型，但是JVM不知道……因此，即使编译器不允许您将List<String>传递给需要List<URL>的对象， List<String>在JVM上看起来也像List。 在我们信任代码的服务器端，这不是问题。 如果我们正在为一个不受信任的世界编写代码，那么我们将更加关注执行环境所强制执行的源代码的语义。

因此，自Java发布以来，没有新的JVM指令。 在基于ADA的军事项目中，JVM也许是指定的最佳软件。 一切都有规范和滞销的JSR。 事实证明，这对我们有利。

JVM具有明确定义的调试接口。 非常清楚地指定了类文件需要提供给JVM的行号，变量名等信息。 因为JVM具有有限的指令集，并且在加载类时知道并验证了堆栈中每个项目的类型以及类中每个实例变量的类型，所以调试信息适用于可编译为Java字节码并具有语义的任何内容。命名局部变量和命名实例变量的集合。 Scala与Java共享这些语义，这就是Scala编译器可以编译具有适当调试信息的字节码的原因，以便它“可以”与jdb一起使用。 而且，需要明确的是，jdb在JVM中使用了标准的，记录良好的接口来进行调试，而JVM的所有其他 IDE都使用了相同的接口。 这意味着编译Scala的IDE也可以挂接到JVM并调试Scala。 这就是为什么调试可与Scala Eclipse插件一起使用的原因。

但是，让我们回到声明：没有人知道Scala的操作特性。

那不是真的。 Scala的操作特性与Java相同。 Scala编译器生成的字节代码与Java编译器几乎相同。 实际上，除了某些构造函数操作之外，您可以反编译Scala代码并使用可读的Java代码结束。 对于JVM，Scala代码和Java代码是无法区分的。 唯一的区别是，有一个额外的库文件来支持Scala。

现在，在大多数软件项目中，您没有首席执行官和董事会成员，每个人的祖母都在问您正在使用什么库。 实际上，在我参与的每个项目中，至少有2个高级开发人员没有添加库，但是以某种方式将其引入到组合中（我相信对库进行审计以确保在库组合中不存在违反许可证的情况。 。）因此，在正常的业务过程中，总是将库添加到项目中。 任何中等复杂的项目都依赖于数十个库。 我可以100％肯定地告诉您，其中的图书馆不会通过“支持图书馆的公司会在5年内成立吗？”的信息。 测试。 期。 当然，memcached将在5年后出现，并且大多数memcached客户都会。 另一方面，幻灯片已“退休”。 还有杂种...

选择使用Scala应该是一个经过深思熟虑的合理选择。 它与开发人员的生产力有关，既要构建初始产品，又要在2-5年的生命周期内维护产品。 它与维护现有的QA和操作基础结构（对于现有的JVM商店）或围绕JVM迁移到最具可扩展性，灵活性，可预测性，经过良好测试和受良好支持的Web基础结构有关。

招募可以做Scala的团队成员可能是一个挑战。 由于对Scala IDE的支持尚不成熟，因此在开发环境上进行标准化可能是一个挑战（但始终可以正常使用emacs，vi，jEdit和Textmate。）对编码样式进行标准化是一项挑战。 这些都是人们面临的挑战，并且都局限于招聘，开发和管理。 辩论中唯一合理的部分是招募和组织团队之间的权衡，以及从Scala获得的收益。

但是，您说的是，如果马丁·奥德斯基（Martin Odersky）决定将Scala带入错误的方向呢？ 然后冻结在Scala 2.7或2.8或任何您认为中断合理的位置。 直到去年，Kaiser才从Java 1.3迁移到1.4。 使用2或3年的技术正常工作。 对抗主干不是一个组织问“马丁在5年内将Scala带到哪里？”的问题的方式。 哦，顺便说一句，如果Martin因某种原因而偏离轨道或Scala，那很可能是与GJ（泛型Java…Martin的先前项目变成Java泛型）相同的情况……这是因为Java 8或Java 9已经充分采用了Scala的功能以使Scala处于边缘地位。 在这种情况下，您将花费几个月的时间将Scala代码移植到Java XX，并在此过程中修复了一些错误。

并没有提出过分的观点，但马丁的团队运行着我见过的最好的独立软件开发商之一。 他们每六个月左右发布一次功能丰富的新版本。 他们有时会在几个小时内对错误报告做出响应。 这里有一个积极的支持机制，其中包括一些最好的编码人员，他们在等待回答新手和老手的问题。 如果我们要按照商业标准衡量Scala团队，那么他们的资金来源比周围的任何私有软件公司都要长，而且它们的响应能力比几乎所有公共或私有ISV都要快。 那么，如果他们是学术专家呢……也许这意味着他们正在思考问题，而不是成为代码浪费的奴隶。

底线……对那些亲手编写代码的人以及必须招募和管理它们的人来说，“对于您所知道的，这只是另一个Java库。”

翻译自: https://www.javacodegeeks.com/2014/09/for-all-you-know-its-just-a-java-library.html