37

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:

please share related links in comments or answers

Related questions:

Related:

Please vote for Jack tool feature request:

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

enter image description here

Community
  • 1
  • 1
Markus Marvell
  • 1,916
  • 1
  • 21
  • 26
  • 6
    Once Jill has full java 8 support scala development will not be affected. Build times may increase. – pfn Mar 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 Zobel Mar 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 Mittag Mar 13 '16 at 03: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 Zobel Mar 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 Marvell Mar 14 '16 at 14:24
  • @Markus I don't really understand your conclusion on the 3rd question. To my knowledge, Java 8 default & static interface methods can be used in Java source (using Jack), but the app can then only run on Android N. OTH, Java 8 Lambda expressions & method references can be used in Java source (using Jack) as far back as Gingerbread. – Stefan Zobel Mar 14 '16 at 16:06
  • @Stefan Zobel It's based on optimistic assumption that Jack can represent Java 8 features in Dalvik bytecode. But there's nothing said in docs about that. And i can't try new SDK because of absence of ARM emulator. So you may be right. But than we back to question #3: how it could affect project organization? I.e. how code for legacy and new APIs with/wo new language features usage can coexist? – Markus Marvell Mar 14 '16 at 16:45
  • @Markus Jack compiles lambdas to anonymous classes, that's why it can work on SDKs <= 23 (documented in your 1st and 4th link). Interface default methods: I don't think it is possible - the bytecode and the bytecode verifier have to change (same thing had to be done for the Java 8 VM). As for the "project organization": don't know, but suspect that it will get quite messy. – Stefan Zobel Mar 14 '16 at 17:28

3 Answers3

6

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

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

Community
  • 1
  • 1
Joan
  • 4,079
  • 2
  • 28
  • 37
2

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.

Community
  • 1
  • 1
dant3
  • 966
  • 9
  • 26
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.

stamanuel
  • 3,731
  • 1
  • 30
  • 45