Well, I assure you that I have switched many JDKs and the bug was never solved.
this time I choose GraalVM with JDK8, reboot the computer and it stopped complaining, deleting .idea was not necessary.
I believe that the issue may appear again. If so I’ll update the post!
Thank you tho
Thank you for the suggestion.
Indeed there were some empty JDK-s in the Idea.
But who produced these invalid JDKs?
IMPO there is still an issue in there.
I use the Jetbrains Toolbox for the Jetbrains IDEs installation.
And noticed that (some or all of) the invalid paths of the empty JDKs pointed to subdirectories of the Jetbrains toolbox installation root.
What do you think?
Could it be an issue in there?
In Android Studio Arctic Fox | 2020.3.1 Canary 2 I have to configure the same SDK and Project language level.
deleting .idea & .gradle folders didn’t work.
This is a recurring annoyance for me: every time I update JDKs, all my idea projects break and there is no other solution than nuking and reimporting each project.
I use sdkman and jenv to manage JDKs on my system. I routinely have LTS and development versions of JDKs and I want to be able to replace these JDKs easily without intellij freaking out.
In this case, Intellij restored broken cached values for JDKs after I deleted the .idea, .gradle and build directories of my project and reimported this.
Please consider making this less painful/tedious as this should not be this hard.
Available system JDKs should be a a system wide preference and not a per project thing. Consider having a central place to manage system JDKs. Making this per project is super tedious.
Projects must be linked to a valid JDK. When a JDK they are linked to disappears (which should be expected), it should fallback to whatever is the default JDK on the system. In case there is none, use the one that runs Intellij.
If you want a different JDK, select one from the list of configured system JDKs. That list should only contain valid JDKs.
I ran into this same thing today, and it took me about an hour to realize it was because I was editing a Groovy build.gradle file, and not a Kotlin build.gradle.kts file.