【发布时间】：2016-06-27 19:05:59
【问题描述】：
现在，随着Jack 的发布，Google 阐明了 Java 与 Android 相关的可预见未来。但是对 Scala 和其他基于 JVM 的语言开发人员有什么影响。特别是：
- Scala 之所以如此神奇，是因为它拥有生成 Java 字节码的编译器。 But Jack toolchain doesn't deal with bytecode。生成的字节码会获得 Jack 处理的任何优化优势吗？
- 从 Scala 12 开始，仅支持 Java 8+。那就是生成的字节码也是Java 8+。 Jack 可以使用 Java 8 字节码（不受限制或不受限制）吗？
- 是否可以使用新支持的 Java 8 功能为旧 Android 版本（minSdkVersion
所有这些问题都归结为一个问题：Scala 是否可以在不牺牲 Scala 新功能和新 Android 工具链的优势的情况下用于 Android 开发？
相关阅读：
请在 cmets 或答案中分享相关链接
相关问题：
相关：
请为 Jack 工具功能请求投票：
编辑：
我正在尝试推理（不回答）我的问题，希望如果我错了专家会纠正我。
下面是一个假设的 Jack 构建流程，其中包含一些额外的块，这些块是根据我的逻辑和我从可用文档中学到的知识添加的。
基本假设是 Dalvik 最多支持 Java 7 字节码指令。如果这是正确的，Java 8 指令不能直接传递给 Dalvik，它们应该以某种方式转换为 Java 7。（可能类似于 Scala 编译器总是做的事情）。
问题是这种转变发生在哪里？似乎 Jill 目前无法处理 Java 8 字节码，因此这可能发生在假设流程的块 (3) 中。如果这是正确的，那么只有 Java 源项目文件需要进行转换，并且第二个问题的答案是 - 不。在 Jill 能够做到之前，不能使用库中的 Java 8 类（如果可能的话）。那就是我们不能使用 Scala 12+。
如果在块 (6) 中执行所有代码优化，那么第一个问题的答案是 - 是。转换为库 .jar 的 Scala 代码可以从 Jack 优化中受益。但最初应该将其转换为 .jayce（类似 AST 的表示），这会增加构建时间。
最后，Jack 生成 .dex Dalvik 字节码以保持与旧的 Dalvik 运行时的兼容性（ART 也使用 Dalvik 字节码）。所以3-d question的答案是：是的，可以使用Java 8 的特性。但仅在项目 Java 源代码中。应用程序仍然与任何运行时兼容。但是由于转换为 Java 7（Dalvik 字节码），Java 8 的优势就消失了。
【问题讨论】：
-
一旦 Jill 拥有完整的 java 8 支持，scala 开发将不会受到影响。构建时间可能会增加。
-
关于“新支持的 Java 8 功能”可用性：只有 lambda 表达式可用于旧版 Android。
-
我的猜测是，最终的最佳解决方案将是 Scala 编译器的原生 Android 后端。也许是 Dotty 的原型。我们已经有了 JVM 和 ECMAScript 后端，我们曾经有一个 CLI 后端，还有一个未完成的 LLVM 后端。支持并且确实存在多个后端，我相信 Dotty 的简化架构应该使它们更加简单。
-
“基本假设是 Dalvik 最多支持 Java 7 字节码指令”。那是“最多”还是“最多并包括”？ AFAIK，Dalvik 字节码不支持 Java 7 调用动态指令，这是 Java 8 lambda 表达式的当前实现设备（这就是为什么用 Java 8 编译的 lambda 理论上可以在 Java 7 VM 上运行，如果那里存在必要的支持类） .但是，如果 Jill 能够真正处理所有类型的 Java 7 类文件，这意味着在转换到 Jayce 的过程中这个问题会以某种方式得到解决——我觉得有点难以置信。
-
@Stefan Zobel 好的通知。从理论上讲，Dalvik 起源于 2008 年初，它具有类似 Java6 的指令集。因此，为了保持与旧 API 版本的兼容性，所有 Java 7、8 特性都被塞进了该集合。为了真正支持新功能，应该有带有扩展集的新 Android 运行时。但是应该为每个运行时单独生成 APK。但是没有。所以理论上来说：“最多不包括”。