Status Update
Comments
vi...@google.com <vi...@google.com>
je...@google.com <je...@google.com>
cm...@google.com <cm...@google.com> #2
Yeah, I'm aware of this one internally, but I'll use this one to track externally.
You've systemized this very well, and I'm actually planning to go for option 1, as it allows arguments["key"] = "value" which seems neater in this case.
This particular case is already fixed in
cm...@google.com <cm...@google.com> #3
but I'll use this issue to track all the rest.
lo...@gmail.com <lo...@gmail.com> #4
Option 1 seems neater, but it also seems more likely to break users on upgrade to me.
Option 2 is what the Kotlin Gradle plugin is using for kotlinOptions.freeCompilerArgs FYI, maybe it'd be a win for consistency to pick that?
cm...@google.com <cm...@google.com> #5
In many cases AGP has setters that the kotlin compiler didn't consider as matching the getters (e.g. non void setter methods, taking iterable to set a collection), so for them mutableX will preserve what worked when all this was in Java.
It is unfortunate that this makes it inconsistent with freeCompilerArgs, which is a var List<String>.
Description
There's multiple declarations in the public API of the Android Gradle plugin that changed as of version 4.1.0-alpha09 in a way that source compatibility is broken.
The common issue that these declarations have is being both a mutable collection (e.g.
MutableList
orMutableMap
), and being exposed as avar
.(Note that this issue is similar to that one that has a fix that should be released in AGP 4.1.0-alpha10, and it is possible that this issue got fixed in the way.)
Previously, they were declared as a java collection, so assigning a non mutable collection was possible was possible as shown below:
On AGP 4.1.0-alpha09, this fails because you're assigning a non mutable collection instance to a mutable collection type.
Instinctively, you add a
+
sign before the assignment operator (=
), but that fails too as the declaration is both variable and mutable, which is also dangerous in case multiple parts in code want to change it.It seems breaking no one is impossible there, so a choice needs to be made.
Here are 2 solutions:
val
)var
)The option 1 is slightly safer because you can add without unintentionally clear content previously added. The option 2 can allow adding without removing any previous content if
+=
is used instead of=
, and is maybe more likely to break less users as the snippet shown above would keep working, and similar code in Groovy DSL would work as well.I think I'd vote more for option 2, but please, pick one of these so we can use
+=
.Tip: You can perform a "Find in Path" (ctrl/cmd + shift + F) in the IDE in the
com.android.build.api
package, looking forMutable
, display them in a tool window, and fix them all to option 1 or 2.