How Jack (Java Android Compiler Kit) will affect Scala developers

Question

Now with announcement of Jack Google clarified the foreseeable future of Java in relation to Android. But what are the implications to Scala and other JVM-based languages developers. In particular:

1. Scala does it's magic due to own compiler that produces Java bytecode. But Jack toolchain doesn't deal with bytecode. Will generated bytecode gain any optimization benefits of Jack processing?
2. Starting from Scala 12 only Java 8+ is supported. That is the generated bytecode is Java 8+ too. Can Jack utilize Java 8 bytecode (without or with limitations)?
3. Can newly supported Java 8 features be used for developing for older Android versions (minSdkVersion < 'N') or i should maintain separate branch for each Java version? (it is not clear from documentation).

All these questions boil down to one: Can Scala be used for Android development in future without sacrificing the benefits of new Scala features and new Android tool chain?

Related reading:

• Java 8 Language Features

• Jack (Java Android Compiler Kit)

• New Android Tool Chain - Jack and Jill

• The Jack and Jill build system (slides)

• Hello World, meet our new experimental toolchain

• Scala 2.12 roadmap

please share related links in comments or answers

Related questions:

• Android N Java 8 features (Jack compiler) and Kotlin interop

Related:

• scala-on-android group discussion

Please vote for Jack tool feature request:

• Support for Java 8 bytecode (libraries) by Jill
• Support Java 8 language features

---

EDIT:

I'm trying to reason about (NOT to answer) my question hoping that experts will correct me if i'm wrong.

Below is a hypothetical flow of Jack build with some extra blocks that was added basing on my logic and what i have learned from available docs.

Base assumption is that Dalvik supports up to Java 7 bytecode instructions. If that is correct Java 8 instructions can not be directly passed to Dalvik, they should be somehow transformed to Java 7. (May be something similar to that Scala compiler always does).

Than the question is where is that transformation happens? Seems Jill can't process Java 8 bytecode as for now, so that possibly happens in block (3) of hypothetical flow. If that is correct than only Java source project files are subject to transformation and the answer to 2-nd question is - No. Java 8 classes from libraries can not be utilized until Jill will be able to do it (if it's possible at all). That is we can not use Scala 12+.

If all code optimization is performed in block (6) than the answer to 1-st question is - Yes. Scala code being converted to library .jar can benefit from Jack optimizations. But preliminarily it should be transformed to .jayce (AST-like representation) that will increase build time.

And finally Jack produces .dex Dalvik bytecode to maintain compatibility with older Dalvik runtimes (ART consumes Dalvik bytecode too). So the answer to 3-d question is: Yes, Java 8 features can be used. But only in project Java sources. App is still compatible with any runtime. But Java 8 advantages are dropped due to converting to Java 7 (Dalvik bytecode).

---

Answer 1

Google just announced that the Jack toolchain will deprecate the Jack toolchain and Android adds "support for Java 8 language features directly into the current javac and dx set of tools"

Source: https://android-developers.googleblog.com/2017/03/future-of-java-8-language-feature.html

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.

and:

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.

Answer 2

It’s important to understand that there is 2 tool introduced:

• Jack: A new compiler to replace the complicated javac + proguard + dx

• Jill: A library linker that will be able to link currently compiled libraries (.class) and more.
  See http://tools.android.com/tech-docs/jackandjill

So it sounds like there is 2 separate problem here:

• Scala compatibility:
  Scala will not be supported by Jack, as Jack compiles Java source code.
  However Scala 2.11 compiles to Java 1.6 bytecode and therefore Jill will be able to pick that code and convert to jack files to feed the Jack compiler.
  See Android N Java 8 features (Jack compiler) and Kotlin interop (Kotlin as the same issue as Scala as it’s a JVM language)

• Java 8, and therefore Scala 2.12+, compatibility:
  This part is under development, if Jack/Jill supports Java 8, then it will also support Scala 2.12+ (through Jill). If not, Java 8 developers are in the same boat as Scala 2.12 developers.
  In the case Jack supports Java 8 but not Jill, then Java 8 libraries developers will be in the same boat as Scala 2.12 developers.
  See https://www.guardsquare.com/blog/DroidconLondon2015

Answer 3

Joan is correct, but I think Jill will have support for Java 8 at some point to, otherwise it will be impossible to use Java 8 in android libraries that will be consumed by android apps, as they package their code in a jar files inside of aar and I don't see this format change happening anywhere soon. Anyway we can only guess, as Google is currently a blackbox in respect to those kinds of changes.

Revising since new info is out in 2017: jack toolchain is now deprecated and old dex/javac stack will receive java8 support so nothing will change for scala now.