98

Update 3. KOTLIN IS NOW OFFICIALLY SUPPORTED FOR ANDROID DEVELOPMENT. BY GOOGLE. YAAAAAAAAS!

Update 2: It looks like JetBrains is really committed to supporting Kotlin for Android in the long run. I'm a happy kotlin user :).

Update: Hadi Hariri, from JetBrains, mentioned they're going to release some info on this topic. I will update this post once they do.


=== DEPRECATED STUFF NEXT ===

Google just released a preview for the upcoming Android N with some interesting features, the most notable being partial Java 8 language support. This is possible due to the new Jack toolchain Google is working on.

The current toolchain using javac or kotlinc:
javac (.java --> .class) --> dx (.class --> .dex)
kotlinc (.kt --> .class) --> dx (.class --> .dex)

New Jack toolchain:
Jack (.java --> .jack --> .dex)

I am assuming Google will push forward towards making Jack the default toolchain for Android development. Update: Jack is now deprecated. Yas.

My question is how will this new toolchain affect me, in the future, as a kotlin user for Android development? Will I get "stuck in the past"?

Tudor Luca
  • 6,259
  • 2
  • 29
  • 44
  • 1
    ( kotlin_library(multiple*.kt) => .jar) then Jill (.jar => Jayce) then import to jack (similar as other (non android)(plain java) jars) – Selvin Mar 10 '16 at 15:14
  • Reading the docs: *"You don’t have to do anything differently to use Jack — just use your standard makefile commands to compile the tree or your project. Jack is the default Android build toolchain for M."* - source : https://source.android.com/source/jack.html surely thats a typo and they mean **'N'** not **'M'** ? – Mark May 03 '16 at 12:00
  • Jack is dead, rejoice :P – EpicPandaForce Apr 24 '18 at 02:28

8 Answers8

63

disclaimer: I work on Jack

This won't affect you. Kotlin's compiler produces Java 6 bytecode, which Jack/Jill can import just fine.

Lukas Bergstrom
  • 757
  • 4
  • 3
  • 7
    Can you share some details on that? :) – Tudor Luca Mar 11 '16 at 01:18
  • But will Kotlin be able to benefit the performance optimization of Jack ? (at least one day) because jack seems pretty awesome (i can't wait for some benchmark right now) – NitroG42 Mar 11 '16 at 13:48
  • I've seen a video presentation of a benchmark from the author of proguard, With a bit of googling you'll be able to find it – sakis kaliakoudas Mar 11 '16 at 15:04
  • We are experiencing some difficulties with building the Android project with the Kotlin stdlib attached. Looks like a bug in Jill/Jack. Could you please look into it? https://code.google.com/p/android/issues/detail?id=196084 – yanex Mar 11 '16 at 15:15
  • @Lukas Bergstrom Would you please answer that related question http://stackoverflow.com/questions/35958814/how-jack-java-android-compiler-kit-will-affect-scala-developers – Markus Marvell Mar 14 '16 at 14:39
  • 1
    Does it mean Jill doesn't accept Java 8 bytecode? What about library modules? If they are compiled to .aar and than imported by Jill are they also unable to use Java 8? I.e. does it mean that Java new features are available only for internal project .java sources? – far.be Mar 15 '16 at 03:41
  • Hi Lukas, could you please take a look at my question [here](http://stackoverflow.com/q/37314760/3287204)? Thank you ... – Yash Sampat May 23 '16 at 12:44
15

@Pavel Dudka

Jack - is a compiler. Similar to javac, but it does a slightly different thing:

enter image description here

As you can see, Jack compiles Java source code straight into Dex file! We don't have intermediate *.class files anymore, so dx tool is not needed!

But wait! What if I include a third-party library in my project (which comes as a collection of .class files)?

And that's when Jill comes into play:

enter image description here

Jill can process class files and transform them into special Jayce format which can be used as an input for Jack compiler.

So now let's step aside for a second and think... What is going to happen to all those cool plugins we got so addicted to? They all need .class files and Jack compiler doesn't have those anymore...

Luckily, Jack provides some of those important for us features out of the box:

  • Retrolambda - will not be needed. Jack can handle lambdas properly
  • Proguard - it is baked into Jack now, so you can still use obfuscation and minimization

Advantages:

Jack supports Java programming language 1.7 and integrates additional features described below.

  • Predexing

    When generating a JACK library file, the .dex of the library is generated and stored inside the .jack library file as a pre-dex. When compiling, JACK reuses the pre-dex from each library. All libraries are pre-dexed.

  • Incremental compilation

    Incremental compilation means that only components that were touched since the last compilation, and their dependencies, are recompiled. Incremental compilation can be significantly faster than a full compilation when changes are limited to only a limited set of components.

  • Repackaging

    JACK uses jarjar configuration files to do the repackaging.

  • Multidex support

    Since dex files are limited to 65K methods, apps with over 65K methods must be split into multiple dex files. (See ‘Building Apps with Over 65K Methods’ for more information about multidex.)

Disadvantages:

  • Transform API is not supported by Jack - there is no intermediate Java bytecode you can modify, so some plugins I didn't mention here will stop working
  • Annotation processing is not currently supported by Jack, so if you heavily depend on libraries like Dagger, AutoValue, etc., you should think twice before switching to Jack. EDIT: As pointed out by Jake Wharton, Jack in N Preview has annotation processing support, but it is not exposed yet through Gradle.
  • Lint detectors which operate on a Java bytecode level are not supported.
  • Jacoco is not supported - well, I personally find Jacoco questionable (it doesnt really show what you want to see), so can totally live without it
  • Dexguard - enterprise version of Proguard is not currently supported
Dhaval Jivani
  • 9,467
  • 2
  • 48
  • 42
  • does the 'Annotation processing is not currently supported by Jack' still holds as per September 2016? It seems like it is supported now... – ticofab Sep 08 '16 at 10:57
  • it is supported, but there are still bugs: e.g. data-binding does not work yet: see [android #210615](https://code.google.com/p/android/issues/detail?id=210615#c11) – TmTron Oct 25 '16 at 08:02
  • Note, that annotation processing IS NOT fully supported by Jack — it is in the same decrepit state as in Eclipse Compiler, which Jack is based on ([several methods are implemented as placeholders, that throw exceptions when called](https://eclipse.googlesource.com/jdt/eclipse.jdt.core/+/master/org.eclipse.jdt.compiler.apt/src/org/eclipse/jdt/internal/compiler/apt/model/TypesImpl.java#206), there are numerous unfixed bugs, filed on ECJ bugtracker). – user1643723 Nov 22 '16 at 09:48
7

UPDATE (03/16/2017)

Luckily, Jack is dead and so it won't affect Kotlin developers.

If Jack is the future then you will get stuck in the past with Kotlin. Currently Jack doesn't support plugins that can compile non-Java source into Dalvik bytecode. And even if it did JetBrains would need to add a new backend to the Kotlin compiler which is not a trivial task. So you will have to use Kotlin with Jill and it's going to be something very similar to the toolchain you use now.

As you can see in the image below even if it's impossible to explicitly turn off Jack you'll still be able to convert the project to a library project to use Jill. And the application project will just reference this library project.

Jack and Jill Application Build

The only way I see how Kotlin can work with Jack, which probably will not be implemented, is adding a Java backend to the Kotlin compiler, i.e. a backend that generates Java code like Xtend. In this case code generated by the Kotlin compiler can be processed by Jack as any other Java code.

But at the moment we don't know exactly what Jack will support when it's released. Maybe something will change dramatically and adding Kotlin support to Jack will become possible.

Michael
  • 53,859
  • 22
  • 133
  • 139
  • 7
    Actually Kotlin team has plans for supporting Jack & Jill, I heard about it at their live event, but I'd rather prefer an official post from JetBrains here, so I didn't answer the question. – hotkey Mar 10 '16 at 19:25
  • That would be great but the only support I heard of is via Jill. And as I mentioned in the answer there are not so many ways how to add this support. – Michael Mar 10 '16 at 19:30
  • In fact, there was something about in-memory code generation (and about much less realistic option, Kotlin -> dex), so that Kotlin Android build would also have significant speed-up. – hotkey Mar 10 '16 at 19:38
  • Don't understand how in-memory code generation relates to Jack integration. And Kotlin to dex compilation means that JetBrains needs to write and support their own toolchain similar to Jack. – Michael Mar 10 '16 at 20:13
  • 1
    Not sure anyone other than Kotlin team should say what they can and can't do, or what they might or might not do. They have talked about this before, and have plans that they can present. – Jayson Minard Mar 11 '16 at 13:44
  • No need to be a part of Kotlin team to make assumptions on how they can add support for the new toolchain. Taking into account the toolchain is being developed by another company JB doesn't have much impact on its functionality. – Michael Mar 11 '16 at 14:30
  • convert a .class to .dex is much simpler than the compiler itself - I mean javac/kotlink. IntelligIdea guys can make it with both hands tied and blindfolded – Alex Byrth May 20 '16 at 16:44
7

Google is not going to push Jack as the default tool, but Jack and Jill.
Compiling .class files to dex with Jill is here to stay. Otherwise, you can say goodbye to jar/aar libraries.

Whether Jack or Jill will be slower is still up for debate. The Android team hopes that jack will be faster than the current build process, but that's not the case right now

Furthermore, Jack and Dex are available in the open, nothing prevents the kotlin team from writing a tool emiting .jack or .dex files from kotlin sourcecode.

Teovald
  • 4,369
  • 4
  • 26
  • 45
5

As said in the blog post (Kotlin's Android Roadmap) that appeared today:

Right now there are some issues that prevent Jack from handling Kotlin-generated bytecode correctly (196084 and 203531), but we plan to work together with the Google team to either resolve the issues or provide workarounds on our side. Once this is done, we’ll be able to translate only changed class files using Jill during incremental compilation, as opposed to translating all class files every time (which is the only possible behavior in the old Android tooling).

So Kotlin will eventually support Jack & Jill and get benefits from it.

hotkey
  • 140,743
  • 39
  • 371
  • 326
2

As per latest google announcement -

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 new direction, existing tools and plugins dependent on the Java class file format should continue to work. Moving forward, Java 8 language features will be natively supported by the Android build system. We're aiming to launch this as part of Android Studio in the coming weeks, and we wanted to share this decision early with you.

We initially tested adding Java 8 support via the Jack toolchain. 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. Thank you for trying the Jack toolchain and giving us great feedback. You can continue using Jack to build your Java 8 code until we release the new support. Migrating from Jack should require little or no work.

So we need not worry about jack toolchain becoming default toolchain for android development. You can continue to use kotlin or use normal javac/dx set of tools.

Source : Future of Java 8 Language Feature Support on Android

Community
  • 1
  • 1
Aniket Thakur
  • 66,731
  • 38
  • 279
  • 289
1

I've already found this blog post from the official Kotlin's blog: : Kotlin’s Android Roadmap

There you would find a part which tells that:

The next thing we plan to do to improve Android build performance is providing an integration with Android’s new Jack and Jill toolchain. Right now there are some issues that prevent Jack from handling Kotlin-generated bytecode correctly (196084 and 203531), but we plan to work together with the Google team to either resolve the issues or provide workarounds on our side. Once this is done, we’ll be able to translate only changed class files using Jill during incremental compilation, as opposed to translating all class files every time (which is the only possible behavior in the old Android tooling).

So as @LukasBergstrom said, there won't be any problem with "stucking in the past" ;-)

You can also check Reddit discussion linked with this topic: What is the status of Kotlin with Jack and Jill?

Happy coding.

piotrek1543
  • 19,130
  • 7
  • 81
  • 94
0

According to the Kotlin blog, release 1.1-beta2 New Features section:

Support for building Android projects when the Jack toolchain is enabled (jackOptions { true });

David Kindred
  • 1
  • 2