Fixed
Status Update
No update yet.
Comments
mo...@gmail.com
I am seeing the same for HashMap get:
No get method providing array access
Overload resolution ambiguity:
@Nullable public open fun get(@Nullable key: String): String? defined in java.util.HashMap
@Nullable public open fun get(@Nullable key: String!): String? defined in java.util.HashMap
No get method providing array access
Overload resolution ambiguity:
@Nullable public open fun get(@Nullable key: String): String? defined in java.util.HashMap
@Nullable public open fun get(@Nullable key: String!): String? defined in java.util.HashMap
mo...@gmail.com
The problem is that unless you specify the type explicitly in any Java Collection calls
method<type>(args...)
the compiler will not resolve the method call to the appropriate kotlin-stdlib-common extension function (for example for the call Array)
/**
* Removes a single instance of the specified element from this
* collection, if it is present.
*
* Allows to overcome type-safety restriction of `remove` that requires to pass an element of type `E`.
*
* @return `true` if the element has been successfully removed; `false` if it was not present in the collection.
*/
@kotlin.internal.InlineOnly
public inline fun <@kotlin.internal.OnlyInputTypes T> MutableCollection<out T>.remove(element: T): Boolean =
@Suppress("UNCHECKED_CAST") (this as MutableCollection<T>).remove(element)
Instead, these method calls will be resolved directly to the standard Java Collections class method, for example
public ArrayList<E> extends ...
{
...
public boolean remove(@Nullable Object o) {
...
}
...
}
method<type>(args...)
the compiler will not resolve the method call to the appropriate kotlin-stdlib-common extension function (for example for the call Array)
/**
* Removes a single instance of the specified element from this
* collection, if it is present.
*
* Allows to overcome type-safety restriction of `remove` that requires to pass an element of type `E`.
*
* @return `true` if the element has been successfully removed; `false` if it was not present in the collection.
*/
@kotlin.internal.InlineOnly
public inline fun <@kotlin.internal.OnlyInputTypes T> MutableCollection<out T>.remove(element: T): Boolean =
@Suppress("UNCHECKED_CAST") (this as MutableCollection<T>).remove(element)
Instead, these method calls will be resolved directly to the standard Java Collections class method, for example
public ArrayList<E> extends ...
{
...
public boolean remove(@Nullable Object o) {
...
}
...
}
gr...@squareup.com
Happening to me as well. Pretty rough.
lo...@gmail.com
Might make sense to boost the priority of the following issue so any future problem like this one doesn't bring the pain of having to revert all code depending on new APIs or take unplanned vacations:
https://issuetracker.google.com/issues/38045649
sh...@pinterest.com
I got lucky because I was about to land the diff to set our compileSDKVersion to 29, which means our CI build would have broken with the v2 rollout.
xa...@google.com
ra...@google.com
se...@earnin.com
We fixed it on by utilizing the kotlin collections versus Java collections. Such as mapOf(), setOf() etc.
su...@gmail.com
Semaaa
em...@gmail.com
It is happening to me too for :
remove():
@Nullable public open fun remove(@Nullable key: String?): Example? defined in java.util.HashMap
@Nullable public open fun remove(@Nullable key: String?): Example? defined in java.util.HashMap
indexOf():
@Nullable public open fun indexOf(@Nullable element: String?): Example? defined in java.util.ArrayList
@Nullable public open fun indexOf(@Nullable element: String?): Example? defined in java.util.ArrayList
containsKey():
public open fun containsKey(@Nullable key: String): Boolean defined in java.util.HashMap
public open fun containsKey(@Nullable key: String!): Boolean defined in java.util.HashMap
contains():
public open fun contains(@Nullable element: Example): Boolean defined in java.util.ArrayList
public open fun contains(@Nullable element: Example!): Boolean defined in java.util.ArrayList
get():
@Nullable public open fun get(@Nullable key: Example): Example? defined in java.util.HashMap
@Nullable public open fun get(@Nullable key: Example!): Example? defined in java.util.HashMap
remove():
@Nullable public open fun remove(@Nullable key: String?): Example? defined in java.util.HashMap
@Nullable public open fun remove(@Nullable key: String?): Example? defined in java.util.HashMap
indexOf():
@Nullable public open fun indexOf(@Nullable element: String?): Example? defined in java.util.ArrayList
@Nullable public open fun indexOf(@Nullable element: String?): Example? defined in java.util.ArrayList
containsKey():
public open fun containsKey(@Nullable key: String): Boolean defined in java.util.HashMap
public open fun containsKey(@Nullable key: String!): Boolean defined in java.util.HashMap
contains():
public open fun contains(@Nullable element: Example): Boolean defined in java.util.ArrayList
public open fun contains(@Nullable element: Example!): Boolean defined in java.util.ArrayList
get():
@Nullable public open fun get(@Nullable key: Example): Example? defined in java.util.HashMap
@Nullable public open fun get(@Nullable key: Example!): Example? defined in java.util.HashMap
em...@gmail.com
KotlinVersion : "1.3.50-eap-54"
AGP : classpath 'com.android.tools.build:gradle:3.5.0-rc02'
AGP : classpath 'com.android.tools.build:gradle:3.5.0-rc02'
ja...@gmail.com
I posted a workaround at https://stackoverflow.com/a/57403743/204480 which downgrades your android-29 package back to the prior revision.
em...@gmail.com
No need to downgrade the SDK version, as another workaround we can use :
val map: MutableMap<String, String> = HashMap() // instead of val map = HashMap<String, String>()
val list: MutableList<String> = ArrayList() // instead of val list = ArrayList<String, String>()
val map: MutableMap<String, String> = HashMap() // instead of val map = HashMap<String, String>()
val list: MutableList<String> = ArrayList() // instead of val list = ArrayList<String, String>()
ra...@google.com
API 29 r2 has been rolled back from Studio SDK Manager for now until the root cause is identified and fixed.
sh...@gmail.com
Thank you for the quick response!
em...@gmail.com
So, the next API 29 will be "r3" ? How we will notified after it will be fixed, will uninstall the old one and get the new one?
Because as
Because as
mo...@gmail.com
em...@gmail.com,
This doesn't work for HashSet<E> which just gets type aliased to the regular Java HashSet. So if you declare
val set: HashSet<Long> = hashSetOf() // or val set = HashSet<Long>()
and then call
set.contains(1L)
the above line won't compile, but it used to compile with SDK 28 version 1.
This doesn't work for HashSet<E> which just gets type aliased to the regular Java HashSet. So if you declare
val set: HashSet<Long> = hashSetOf() // or val set = HashSet<Long>()
and then call
set.contains(1L)
the above line won't compile, but it used to compile with SDK 28 version 1.
mo...@gmail.com
Sorry, I meant it used to compile with SDK 29 version 1
lb...@gmail.com
wa...@gmail.com
got it, thanks
Description
Steps to reproduce:
1. Accepted latest Android Q SDK release (29 version 2) published on August 7, 2019
2. Compiled project (that compiled perfectly before the upgrade
3. Java Collections libraries (HashSet, and ArrayList) report "Overload resolution
ambiguity" errors (for ArrayList.contains() and HashSet.remove()).
These functions Collection method calls compiled without warning or error before the upgrade.
I've included screenshots of the exact errors for both cases that shows the code along with the error tip box.
I'm sure you'll tell me it's a caching issue and that I should either rebuild my project or if that fails, to clear caches and reload. I've done the clean/rebuild, but I haven't done the "Invalidate caches and restart" because I don't want to lose my local history at the current time.
I can fix the errors, strangely enough, by changing both Collections calls from
arrayList.contains(value) to arrayList.remove<type>(value)
and
hashSet.remove(value) to hashSet.remove<type>(value)
but I'm not comfortable with this solution since there should be no need to have to explicitly specify the type for each of these calls.