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)?

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?

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).

Once Jill has full java 8 support scala development will not be affected. Build times may increase.
– pfnMar 12 '16 at 15:04

As for the "newly supported Java 8 features" availability: only lambda expressions will be available for older Android versions.
– Stefan ZobelMar 12 '16 at 16:35

My guess is, the ultimate optimal solution would be a native Android backend for the Scala compiler. Maybe prototype one in Dotty. We already have JVM and ECMAScript backends, we used to have a CLI backend, there's an unfinished LLVM backend. Multiple backends are supported and do exist, and I believe Dotty's streamlined architecture should make them even simpler.
– Jörg W MittagMar 13 '16 at 3:10

1

"Base assumption is that Dalvik supports up to Java 7 bytecode instructions". Is that "up to" or "up to and including"? AFAIK, Dalvik bytecode doesn't support the Java 7 invokedynamic instruction which is the current implementation device for Java 8 lambda expressions (that's why lambdas compiled with Java 8 could theoretically run on a Java 7 VM if just the necessary support classes would exist there). However, if Jill can truly deal with all kinds of Java 7 class files that would imply that this issue is somehow solved during the conversion to Jayce - something I find a bit hard to believe.
– Stefan ZobelMar 14 '16 at 12:58

@Stefan Zobel Good notice. Theoretically as Dalvik has it's roots in early 2008 it has Java6-like instruction set. So to maintain compatibility with older API versions all Java 7, 8 features are crammed into that set. And to really support new features there should be new Android runtimes with extended sets. But than there should be separately generated APKs for each runtime. But there aren't. So again theoretically: "up to not including".
– Markus MarvellMar 14 '16 at 14:24

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

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.