Jack(Java Android编译器工具包)将如何影响Scala开发人员

Mar*_*ell 36 android scala java-8

现在宣布杰克谷歌澄清了Java与Android相关的可预见的未来.但是对Scala和其他基于JVM的语言开发人员有什么影响.特别是:

  1. 由于自己的编译器产生Java字节码,Scala确实很神奇.但Jack工具链不处理字节码.生成的字节码会获得Jack处理的任何优化优势吗?
  2. 从Scala 12开始,仅支持Java 8+.那就是生成的字节码也是Java 8+.杰克可以使用Java 8字节码(没有或有限制)?
  3. 可以使用新支持的Java 8功能来开发较旧的Android版本(minSdkVersion <'N'),还是应该为每个Java版本维护单独的分支?(文件中不清楚).

所有这些问题归结为一个问题:未来可以将Scala用于Android开发而不会牺牲新Scala功能和新Android工具链的优势吗?

相关阅读:

请在评论或答案中分享相关链接

相关问题:

有关:

请投票给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字节码).因此,三维问题的答案是:是的,可以使用Java 8功能.但仅限于项目Java源代码.App仍与任何运行时兼容.但是由于转换为Java 7(Dalvik字节码),Java 8的优势被删除.


在此输入图像描述

Joa*_*oan 5

重要的是要了解引入了2个工具:

所以听起来这里有两个独立的问题:

  • Scala兼容性:
    Jack不支持Scala,因为Jack编译Java源代码.
    然而,Scala 2.11编译为Java 1.6字节码,因此Jill将能够选择该代码并转换为jack文件以提供Jack编译器.
    请参阅  Android N Java 8功能(Jack编译器)和Kotlin互操作  (Kotlin与Scala相同,因为它是JVM语言)

  • Java 8,因此Scala 2.12+,兼容性:
    这部分正在开发中,如果Jack/Jill支持Java 8,那么它也将支持Scala 2.12+(通过Jill).如果没有,Java 8开发人员与Scala 2.12开发人员在同一条船上.
    在杰克支持Java 8但不支持Jill的情况下,Java 8库开发人员将与Scala 2.12开发人员在同一条船上.
    请参阅  https://www.guardsquare.com/blog/DroidconLondon2015