Since 3.0, classpath order of Android project isn't consistent

android

(Kirill Rakhman) #1

Gradle Version: 3.0
Operating System and JVM version: Windows 10 64 Bit, 1.8.0_60 64 bit

AFAIK, Gradle guarantees that the compilation classpath will have a consistent (while arbitrary in regards to transitive dependencies) order.

It seems that starting with Gradle version 3.0, the order of the classpath entries of an Android project isn’t consistent anymore. This is a problem when using the Kotlin plugin because it breaks incremental compilation. I summarized the problem in https://code.google.com/p/android/issues/detail?id=221007.

Basicly, depending on whether you launch the build from Android Studio or from JRebel for Android, the compilation classpath will have two entries swapped.

When I reverted to Gradle 2.14.1, the problem seemingly disappeared.


Classpath order is not deterministic with Gradle 3.1 RC1
(Stefan Wolf) #2

Hi Kirill,

thank you for reporting this. Could you provide some example project to reproduce this? Do you think that the order of the classpath entries change between Gradle runs - i.e. can we reproduce the problem without using Android Studio or JRebel?

Regards,
Stefan


(Kirill Rakhman) #3

Thanks for your answer. I created a repo here: https://github.com/cypressious/Bandhook-Kotlin/tree/classpath (please use the branch “classpath”).

When you configure the project, it writes the classpath to build/classpath/<timestamp>.txt

I noticed something new. It seems the classpath is different based on whether the daemon was running or not. When you kill the daemon and then call gradlew help, you get classpath A. On all subsequent runs, you’ll get classpath B. Until you kill the daemon and try again.


(Kirill Rakhman) #4

It seems the problem is not exclusive to 3.0. The same happens with 2.14.1.


(Stefan Wolf) #5

Thanks for the repo. I can reproduce the problem. Do you have an example where the problem does not occur for some Gradle version? It seems to me that it is actually a Bug on the Android/Kotlin plugin side. While debugging I found https://android.googlesource.com/platform/tools/base/+/1cb9df6e3a9999cbf71e45b17daa4cc01a894b3c/build-system/builder/src/main/java/com/android/builder/core/AndroidBuilder.java#308 - here the dependencies would be added into a HashSet - which does not give any order guarantee.


(Scott) #6

Has a bug been filed with Google for this that I can track?


(Stefan Wolf) #7

Hi Scott,

@Kirill_Rakhman already filed a bug: https://code.google.com/p/android/issues/detail?id=221007

It has been fixed in 2.3.

Cheers,
Stefan


(Kirill Rakhman) #8

Yes, here https://code.google.com/p/android/issues/detail?id=221007

Kirill Rakhman


(Lóránt Pintér) #9

@Kirill_Rakhman: could you try this again with the freshly released Android Gradle plugin 2.2.2? My tests show that the classpaths are now produced in a stable order.