Hello,
I am facing the same problem a lot of other Android developers are facing.
ECJ Unable to resolve type android.content.ContentProvider
org.eclipse.jdt.internal.compiler.problem.AbortCompilation: Pb(347) The type java.lang.String cannot be resolved. It is indirectly referenced from required type android.content.ContentProvider
at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:162)
I was not able to find a proper solution the only workaround I found is to set sonar.java.jdkHome to a Java 8 JDK.
Is this a good practice?
Would I get the correct deprecation warnings?
My source code compatibility is iset to Java 11 and I am forced to that because of our business.
What really call my attention is I was using Java 11 and used to have the compatibility to Java 8 and everything worked correctly… moved to java 17 and set the compatibility to java 11 and everything went down hill.
is there any other workaround?
Are you planning any other solution?
Thanks!!!
There are several workarounds that may help you including setting sonar.java.jdkHome at the module’s build.gradle Please review that thread and let me know if you have further questions.
Hi,
Yes in build.gradle
Yes, it is the same problem. The workaround setting sonar.java.jdkHome to java 8, I read it in that thread.
about sourceCompatibility looks like is not that simple to roll back, there are more chances in the code and I can not just change the sourceCompatibility to java 8. Also because our business I am lock in Java 11 compatibility.
Yes, I do have further questions:
Is this a good practice?
Would I get the correct deprecation warnings?
is there any other workaround?
Are you planning any other solution?
This looks to be a very well documented problem because googling sonarclour/sonarqube android the first page is ppl asking about this.
Thanks
No, it is not good practice. Setting sonar.java.jdkHome to Java 8 is purely a workaround until we fix the issue in [SONARJAVA-4697] - Jira. The priority of this ticket is critical as you can see, so it is actively being worked on as we type.
Note that setting sonar.java.jdkHome won’t change the Java version of your project so you can use whatever Java version you want. Please see Java: Project’s Specific JDK for more info.
Joe, how are you?
Thank you very much for the update!!!
Went over the ticket, and it looks amazing. I have a question, it mentions it will be fixed in version 7.29, to what version of the Gradle plugin is this related? So I can keep an eye on it and update when this is released.
Thanks!!!
For SonarCloud, we perform new releases at least on a weekly basis, but I can’t tell when Sonar Java will be released. You can click on “Watch” and select releases from custom notifications so once 7.29 7.30 or greater is released, you’ll be notified and it should be released on SonarCloud subsequently.
Hello,
I saw the new Sonar Java was released with this fix inside. THANK!!!
Quick question: how do I know, or how can I make Sonarcloud use the latest version for the scan?
Is it automatic? Do I need a new version of Sonarcloud? Can I configure it somewhere?
Thanks a lot!
By default, SonarCloud will use the latest version in most cases. It is automatic. There is no version of SonarCloud that you can control. Sonar controls the version of the language analyzers. You cannot configure that.