 So, I am Chaitanya. I will be talking about Jack and Jill. So, I do Android development and Python development professionally. Jack and Jill are the new Java toolchain that Google has introduced. Basically, they give you Java 8 support in limited fashion if you are using Android M or below. Basically, you get lambda expressions and you get method differences. So, we will go over what the existing toolchain is like and what the new toolchain is like and why you might or might not want to use them. So, Jack stands for Java Android Compilocate and Jill is the intermediate library linker. Jack basically takes your Java source code in your Android app and converts it directly into the DEX files that are there in your Android app. Jill is responsible for taking any external libraries that you are using and converting them into a format that Jack can understand. There is a special format that it converts it into called .jack. We will go over what that is and why it does that. So, it was introduced by Google in 2014. It is officially supported by Google. It is the only way to get Java 8 in your Android apps and they have been working hard on it for some time now. However, there are some drawbacks still. The stated objective is to improve build times and to simplify development by reducing the number of tools involved in taking your Java source and converting it into the Android app. They are the future and if you are doing any AOSP development, then you must have already seen the use of Jack for compiling the Android source. Like I said, it is the only way to use Java 8 features. So, what are the benefits of using Jack and Jill? If you are at API 24 or below, as in API 23 or below, which is Android Marshmallow, you get lambdas and method references. So, if you are using retro lambdas right now for getting lambdas, then you could stop using that with this. If you are in the magical land of Android N and above where your minimum SDK is Android N, then I would like to join your company and you would get stream APIs, default and static interface methods and functional interfaces. Stream APIs are quite awesome. Anup actually went a little over them. We will go over them also. This is the current build process. You have your Java source. The Java compiler converts it into Java byte code. If you are using ProGuard or JCoco or whatever intermediate byte code tools, this is where they come in after the Java byte code has been generated. They convert the Java byte code into this modified form, which is then passed on to the DX tool, which gives you your Android byte code. Any third party libraries that you are using would also come in at this point, and they would be passed along with your main classes to the DX tool. As you can see, there are multiple tools involved. There is the Java C compiler, there is ProGuard and JCoco or whatever else you are using, and then there is DX. Google wanted to reduce that and reduce the number of dependencies involved here. In Jack and Jill, you have the Java source code and you directly get Android byte code. There is no intermediate step involved. But if you are using any third party libraries, then you need an intermediate step to make Jack understand what the third party library is. There is this external .jack format. This is the entire build process in simple terms. This is also the entire build process, but not in simple terms. Essentially, Google wanted to make it look complex, but it is the same thing. You have the application module, which is your Java source code, and you have your third party libraries, and all of them are converted through the Jill into this .jack library file and passed on to Jack. If you are using Kotlin or any other JVM language like Scala, then it would also pass through Jill. There is a cost involved in using a third party library, because it is not directly passed on to the compiler. There is an intermediate step involved. This is the .jack format. This is what it comprises of. There is a special format of the code called JS, which is separate from the Java byte code, intermediate byte code. It looks different if you look at it. We will look at it in a little while. The code is also pre-dext in order to bring some optimizations, and any resources or meta information that your library has, they would also be packaged in here. This is a simple for loop. This is what it would look like in a class file, and this is what it would look like in a .dex file. You can see that the class file and the .dex file are relatively similar. This is because they are optimized for not for processing, but for storage, whereas JS is optimized for processing. Class and Dex are optimized for storage because essentially the Android environment is such that you have limited storage, so that is what they are optimized for. JS is at the intermediate step. You can see it looks very, very dissimilar. Google says that it helps with processing, but whatever. Assuming that I have convinced you to at least try it out, this is how you would do it. In your Gradle build file, you would say jack options, and you would say enable to do. That is about it. Essentially, if you just want to try it out, you can put it in one of your product layers. Just call it experimental. If you want to minify it, you can set minify enable, and if you want to use ProGuard, this is where it would come in. Like I said, jack does all the things that any external library, any external tool that you might be using would do. Any minification, obfuscation, repackaging, all of that would be done by jack. So your ProGuard files would be read by jack, and the obfuscation would be done by jack. So ProGuard doesn't really come into the picture here. If you want to set any additional parameters, that is also here. So this jack.incremental sets the incremental build to true, so it would do incremental builds. You can check out what the different properties available are, like the incremental build property. So you can check out what different parameters are available by running the jack.jar file. It is there in your build tools version folder. You could pass the help properties. You could pass your help properties flag and it would return all the different available parameters. For instance, the assert policy parameter would allow you to set what the assert policy is. So when do you want the asserts to run? Do you want them to run all-base or just at runtime or never? So there are different parameters available. So what are the different implications of running this? Any annotation processors that you might be using, like dagger or button knife, they would still run. Any bytecode processors would also run, like jaco core retro lambda. However, you would probably not use retro lambda if you're using jack and jill. Like I said, any JVM languages that you're using would be supported via jill. Instant run is not yet supported. That is one big negative. Your build times would be slightly or very highly slower depending on whether it is a clean build or an incremental build. So this is a test I ran with an app I was making. So the yellow bar represents the current build process and the blue bar represents jack and jill. For a clean build, you can see there is about 20 seconds of difference. Whereas for an incremental build, the difference is wider. The difference varies based on how incremental the build is, how many classes you might have changed. So this is one major negative of using jack and jill. Bitecode-based linked tools won't work. However, there aren't really many bytecode-based linked tools. So that is a minor negative. So transform API is not supported. Transform API is used for rel. So rel is essentially not working for jack and jill. The transform API essentially tells your any third-party libraries that you might be using that a graded build has been performed. But the final build has not completed. So it informs the third-party library that intermediate bytecode is available. So since intermediate bytecode is not really made, therefore the transform API is not supported. I don't know how they'll end up supporting it, but there are a couple of bugs filed in the rel bug tracker as well as the jack and jill bug tracker. Application performance and app sizes are comparable. There was no real difference. So the big thing like I said that you get is Java 8 language features. In order to use the Java 8 language features, you have to add a couple of other lines, source compatibility and target compatibility. You are essentially setting it to Java version 1.8. So if you're using API 23 or lower, your minimum SDK is API 23 or lower, then you get method references, lambda expressions and type annotations. So we'll just go with lambda expressions and method references right now because those are the major positives. So how many of you know what lambda expressions are? Okay, you guys know. So essentially you can replace your onclick listeners by the lambda expressions. Your boilerplate will reduce. It is good all around. It looks nice to read. If you have, basically lambda expressions are used for replacing any anonymous classes that you might be using which have a single function. So for instance, the onclick listener here has been replaced with just the activate view call. And if you just have a single instruction in the lambda expression, then you can just reduce it to one line. Method references allow you to use, to make it even shorter, allow you to call a method within the lambda expression. So for instance, this lambda expression you can just call the activate method instead of just writing the call. So if you are in the magical land, like I said, you get all of these things. You get utility APIs, stream APIs, and a lot of other things. So we'll just go with the stream API for now because we have limited time. Stream APIs are quite wonderful because they let you chain a set of commands together and run them on a single object. So if you want to, for instance, say filter run filters. Yeah. So for instance, if you want to filter a list and then check for different words that contain droid and then sort them and then limit it to 10. And you want to run all of these things together. Then you would call this stream APIs. Essentially, they run in multiple threads out of the box. So if you want to do multi-threading, then this is perfect for you. And this is the biggest positive, I would say, that comes with Jack and Jill. So in conclusion, it is very easy to enable a tryout. You can do it in a couple of minutes. You get some Java features if you are, if you are at minimum SDK, less than 23 as in March or below, you get a lot more Java features, Java features if you are at SDK 24 or above. And for now it is slower than the existing tool chain. However, Google says that they are working on it. So hopefully that will change. There are a few resources here that you might want to check out. And thank you. If you have any questions, now would be the time. There is a question there. So do you know any of the Java APIs are probably coming in support library? Probably any word from Google that they might include some of them like utility functions and all that in support library because they used to do it and they still do it for some APIs. So they have said that they are working on it but there has been no release from them. Even the, I should have mentioned this in the talk, but even the lambda expressions and method references that you get for API 23 and below, those are essentially syntactic sugar. So they are, in the background, they are making anonymous classes as well. It is not real lambdas. It is essentially replicating retro lambdas. So if there are any features that work like that, then Google has said that they would work with Jack and Jill or the support libraries to include them. But nothing as of now apart from this. Okay, thanks. Are there any specific pain points if we want to migrate an old app with this? I don't see. Oh, yeah. Okay. Are there any pain points? Not really. It works out of the box. Whatever the, if you are at, what, what API are you using? Like 23. 23. So it will work right out of the box. Lambdas and method references will work. There is not really any. Any issue with data binding? No. There were actually a couple of issues until three months ago, but they have resolved any bugs that are outstanding. So right now there are no bugs. Okay, thanks. Hey man. So Jack sort of skips the dot plus part of it and directly dexes. Yes. So have you noticed any performance gains by this during build time? No, there are no performance gains as yet. It is my heart. I was counting. Okay, thanks. Any more questions? Thank you. Thank you.