如何看待 Google 废弃 Jack 而直接在 javac 和 dx 上支持 Java 8?

> At Google, we always try to do the right thing. Sometimes this means adjusting our plans. We know how much our Android developer community cares about good support for Java 8 language features, and we're changing the way we support them. > We've decided to add support for Java 8 language features directly into the current javac and dx set of tools, and deprecate the Jack toolchain. With this …
关注者
274
被浏览
51742

18 个回答

详细见专栏文:Google 又弃坑了,Jack+Jill vs. javac+dx

Google post原话:

Over time, we realized the cost of switching to Jack was too high for our community when we considered the annotation processors, bytecode analyzers and rewriters impacted.

个人表示三枪全中,我们团队主攻annotation processors, bytecode analyzers and rewriters。事实上,团队内部的Github上至今还有一个issue叫:Support Jack/Jill and its Java8 features。现在可以放心地准备review and close了。

具体一点:

1. jack + jill 比 javac+dx慢(很多)耗内存,意味着更长的build过程,而且没有Instant Run,编译器是个长年累月的活

2. annotation processors: 用来处理Java Annotation的,比如依赖注入类的Dagger。同时ButterKnife以及一麻袋star上千的库的作者Jake Wharton说Android N Preview已经(开始)支持annotation processors,只不过来的太晚。Annotation-based的库可以大大减少代码量,如果编译器不支持的话库作者都没有办法改过来,只能等

3. bytecode analyzers:这类就广了,最常见的就是Lint类工具,用来静态找bug的(比如这个变量定义了没有用之类的)。其他的bytecode analyzers还有原来Java用来分析内存泄露、多线程竞争的工具。不支持的原因很简单,Java bytecode没有了,要么analyzers都按照Dalvik bytecode重写一遍。同样这个不支持是致命的

4. rewriters:重写以及插桩工具,有不少工具是基于objectweb.ASM处理标准Java bytecode的(幸好我们团队的是DEX的),这些工具广泛用于PGO (profiling-guided optimization) 还有其他动态分析。

总结

Android Dalvik的起点是拥有“over 1 billion设备”的Java,这点眼光是对的(虽然当年的Dalvik VM是多么烂):1)快速吸引大量Java程序员;2)基本原来Java的工具可以用到Android;3)巧妙解决了License问题(Dalvik VM is not JVM,避免了Trademark的问题)

除了给Dalvik VM不断改进(JIT,GC等),后来搞出了ART,想法也是不错的(保留了Dalvik bytecode,javac+dx继承了所有Java的工具,GC硬伤得以改善)

但是Jack/Jill从产品上的确是一个值得质疑的决定,要知道产品永远要比技术本身更重要。

“如何看待”类问题好难回答。有啥好“如何看待”的呢 >_<|||

能导致一个项目中途被砍有若干常见原因,其中例如有:
  • 内部斗争
  • 开发资源被撤销
  • 东西实在太烂
不知道Jack and Jill实质上遇到了上面的哪些情况呢。或许一个都没中,或许全中。好想去八卦一下…

我自己没有自己用过Jack,没有一手资料所以没发言权。只能贩卖点二道消息。
去年下半年的时候听朋友说用Jack用得非常痛苦,这编译器如果要拿来编译AOSP自身的Java库的话需要极大的内存才带得动,而且其中某些比较大的类还是编译不了,得退回到用javac来编译。感觉有点尴尬…

不知道实际有用过Jack或者对Jack的内部实现有了解的大大怎么看呢?

其实之前稍微瞄过一眼AOSP上Jack的ub-jack分支的代码,感觉还算中规中矩,但或许太想把代码组织得漂亮而没控制好资源消耗吧?