Status Update
No update yet.
Comments
ar...@google.com
je...@google.com
hu...@google.com
I can reproduce this (thanks for the repro project!)
It looks like the problem is that the desugared api list from r8 contains this entry:
java/util/Collection#removeIf(Ljava/util/function/Predicate;)Z
but the bytecode here doesn't match -- it's java/util/ArrayList. Collection isn't a directly implemented interface or a direct super class, it's an interface on the super super class. The most efficient thing runtime wise would be for the signature list to inline this method on all implemented subclasses. But I should probably at least for now go and make the desugared API lookup do something similar to what it does for API lookup -- search through all super classes and interfaces as well. This isn't a new problem, so I'm very surprised this hasn't come up before (or it has, and I've forgotten).
ma...@gmail.com
(I have a pending CL that was working to improve the handling of fields now that r8 handles desugaring fields, I'll try to dust that off and combine the fix in there.)
hu...@google.com
I went to implement this, and hooked up inheritance search when analyzing the source file containing the call.
However, lint also handles the case where the library being analyzed is not using core library desugaring (for example, it may be a plain Java library). But when that library is consumed in a downstream app module, where library desugaring is turned on, lint then processes the partial results from the library and filters each violation through the desugaring allowlist.
At this point, it's tricky to do the inheritance search -- this happens when we no longer have a compilation environment and can do class inheritance lookups. So there are three possible solutions.
First, we pay the cost up front -- even when you're not using core library desugaring, we record whether the method is potentially library desugared if turned on. (This is also tricky because at this point we don't know which exact desugaring library version is used, which determines the exact list of APIs).
Or, more expensively, for every API violation of this type we store all the potential super class and interface names for each result...
Or, we handle this in the code which generates the desugaring API list, inlining all subclasses affected. This could be quite a long list, but on the other hand this list is really only intended to be machine readable.
hu...@google.com
This is partially fixed now; it's fully fixed for the sample project, but in the scenario I described in comment 4, it works if you also configure library desugaring to be on in the library.
hu...@google.com
likely related:
Objects.requireNonNullElse
Objects.requireNonNullElseGet
are now also showing this same false positive warning.
Android Studio Koala | 2023.3.2 Canary 2 gradle 8.6 plugin: 8.3.1
an...@google.com
This seems unrelated. Can you file a new bug?
Specifically, for Objects.requireNonNullElse I am not seeing a lint API error, but I am seeing a warning from IntelliJ's built-in Java inspections. These should probably not show up in Android modules. I swear we've fixed that before but I'm assuming something changed to break that.
For Objects.requireNonNullElseGet I do see a lint API warning for that. But, that's not a recent change, right? I looked at R8's desugaring list and that method is not there. So that method does crash at runtime, right?
Description
STEPS TO REPRODUCE:
1. Have a custom Gradle plugin
2. Add
```kotlin
tasks.withType<JavaCompile>().configureEach {
options.release.set(11)
}
```
3. Apply the plugin to all projects (including `org.jetbrains.kotlin.jvm` and `com.android.library`
4. Compile the project `./gradlew assemble`
5. Console gets polluted with:
```
WARNING: Using '--release' option could cause issues when using Android Gradle Plugin to compile sources with Java 9+. Instead, please set 'sourceCompatibility' and 'targetCompatibility' to the desired Java version, and set 'compileSdkVersion' to 30 or above. See
```
And the problem is I do want to set `--release`, as I want all task in the project use the same java version. Regardles if it's an Android or kotlin-only module.
I do have `sourceCompatibility` set.
I do have `compileSdk` set to >30, but I still see an error.
I expected to see a link explaining how to disable the warning, but it turns out the link is dead already.
I expected to see clear message explaining what kind of "issues" current config may cause.
If I remove the `--release` then my Kotlin modules will target wrong java version and the build fails with:
```
'compileJava' task (current target is 17) and 'compileKotlin' task (current target is 11) jvm target compatibility should be set to the same Java version.
Consider using JVM toolchain:
```
I don't expect to see a warning if I have everything set properly, or at least have a way to disable the invalid warning
Can you please share how to remove that warning?
ATTACH SCREENSHOTS/RECORDINGS OF THE ISSUE
ATTACH LOG FILES (Select Help > Show Log in Files, or Show Log in Finder on a Mac)
------------------
IMPORTANT: Please read
all required information.
------------------
Studio Build: None
Version of Gradle Plugin: 8.0.0
Version of Gradle:
```
------------------------------------------------------------
Gradle 8.1
------------------------------------------------------------
Build time: 2023-04-12 12:07:45 UTC
Revision: 40ba32cde9d6daf2b92c39376d2758909dd6b813
Kotlin: 1.8.10
Groovy: 3.0.15
Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM: 20 (Homebrew 20)
OS: Mac OS X 13.3.1 x86_64
```
Version of Java:
```
openjdk version "20" 2023-03-21
OpenJDK Runtime Environment Homebrew (build 20)
OpenJDK 64-Bit Server VM Homebrew (build 20, mixed mode, sharing)
```
OS: All