IntelliJ doesn't see classes in dependency JAR

Even so File \ Invalidate caches and restart did not fix the issue, deleting USER_HOME\AppData\Local\JetBrains\IdeaIC2020.2\caches (i.e. %AppData%\..\Local\JetBrains\IdeaIC2020.2\caches) did work.

I had the same problem and can confirm, that manually deleting the caches folder worked, after Invalidate caches and restart  was ineffective.

I recently had the problem again with a few sub-packages (e.g. java.util.function and java.util.regex) in java.base. So it doesn't always affect a whole JAR but might only affect a few packages.

Hi. Does turning off shared indexes (https://www.jetbrains.com/help/idea/shared-indexes.html) resolves the problem? 

I don't use shared indexes. I always denied the popup for the time being. Both options are set to "Don't download, use local indexes". My problems doesn't seem to be related to this feature.

@Johanness does invalidate caches (File | Invalidate cache...) helps?

@... as was already stated in the original post, invalidating didn't fix the problem, only manually deleting the caches folder solved the problem. Fortunately, it has only happened once for me.

@Johanness,  We have a related issue: https://youtrack.jetbrains.com/issue/WI-54626, could you please clarify, how often does the problem reoccurs?

Sorry for the late response. I was able to observe the issue two times for now. The first time I created this ticket (October 2020). The second time I wrote the replay above (March 2021). The account which created this thread also belongs to me.

Thank you for the information. Unfortunately we still cannot repeat this problem and are looking for the reproducible scenario. And would be grateful if anyone could provide the steps.

Also it would be helpful to have the logs with debug enabled (added com.intellij.openapi.vfs.newvfs.persistent.FSRecords line into Help | Diagnostic Tools | Debug Log Settings... dialog) after this problem has occurred. Ideally after it has been reproduced with clean caches (removed IDE caches directory).

I will add this line to my diagnostic options. However, since the problem occurs very infrequently, I cannot tell when I will run into it again. Even if I notice the problem again, the actual error might have happend multiple days in the past before I try to access the affected packages. Unfortunately, I also don't know how to reproduce this problem. :/

Thank you! When it occurs would you please attach IDE IDE logs (you can upload them at https://uploads.jetbrains.com or in YouTrack issue) and indicate when issue has happened. Thanks!

Hello  , 
I have exactly the same issue .
Intellij can't find the class from a custom dependency that I already developed and installed in my local maven repository 


I ve already tried to delete cache manually from %Appdata% and with intellij (invalidate and restart) but the issue still the same.

Can you help me please ? 
Thank you

Sifokl, your problem seems to be different, since for us the referenced classes were not visible in the project view on the left. Is the module com.sifoklus:scheduler correctly added as compile dependency to your module? And if you are using a module-info, does it declare that you require it?

Sifokl

What does IDEA say in the Problems Tool Window? Can you share the exact error message it is giving you?

Would it be possible to share the "scheduler" artifact or a screenshot/code of how the "IRunnableTask" Interface is declared?

Hello Johannes Spangenberg and Roman Vatagin , thnak you for your comments and sorry for this late answer , it's indeed  problem not related to intellij (my bad) .It s resolved now on this thread (if it eventually can help other people who face the same issue)
https://stackoverflow.com/questions/76622238/my-java-project-cant-recognize-a-class-from-my-other-custom-maven-dependency-fr

The problem can be reproduced consistently on JAR files that have some file header errors. The source of header error can be - Corrupted File, Unsupported Compression, etc. By changing the JAR library to be downloaded from different source that is not corrupted solves the issue. 

I believe IntelliJ doesn't read any library archive that have any type of warning in them. Some tools(7-Zip or Javas `ZipFile` API) can extract archives that have warnings in them and the archive can be considered healthy by library developers and “corrupted” archive version ends up on repository server which Maven, Gradle or other tools download from. If you need exactly the version of the archive that IntelliJ considers corrupted, there is no other way but create own fork of that version with correct JAR compression and file without header warning and make Gradle, Maven or other tool to consume it. If the library at the repository has the latest version that suffice your project and IntelliJ considers it valid,  just try to use that version instead, which will be the fastest fix.

IntelliJ can improve user interface of the “Project” navigator window to mark libraries that doesn't show contents in them as “Failed to read” with a more pronounced warning so it is easier to find and fix the problem. The other alternative is to use less strict JAR archives validation when reading those.

Zacorich In my case it was not a problem of the JAR. I know that because it worked with the exact same JAR after clearing all caches in USER_HOME/AppData (see above). I also doubt that OpenJDK ships with invalid JAR files as I had the same problem with java.base as well. Reading the JAR failed for some other reason. Maybe the process run out of memory, or maybe the operating system reported some IO error. The problem was that the error was not reported, and that there was no other way to invalidate the cache besides deleting the corresponding directory. (Or rather, when such a error happens, the cache should probably not be populated in the first place.) Anyway, if there is a similar issue when the JAR is invalid, maybe that could be useful to debug the issue and find a solution. I also did not run into the issue for quite some time, so maybe the issue regarding the cache is already fixed.

Johanness , I can consistently reproduce the problem by just changing the versions of dependencies I know have some warnings in their JARs on public repos as of today. I won't be that sure about OpenJDK too as its Jar compression tool might behave differently from version to version. Different Intellij versions also can have different Jar archive validation rules. I believe the latest version of IntelliJ has a very strict JAR extraction validation that might fail even for completely healthy archives. It was surprising to me that I didn't have the problem for the same codebase ever until I re-synched libraries from public repo which ended up downloading that slightly uncommon Jar that I can extract with everything else but not IntelliJ. Long story short for everyone out there that can't see parts or whole jar contents in their Project window it is most likely the underlying libraries archives on the repo server were changed or somehow corrupted . As the repo servers change files you depend on without asking you at any point in time, it is clear to me now why this bug is so hard to catch, as one day downloaded files are fine and the other day they are what they are and make IntelliJ unhappy. I scratched my head about this all morning, too lazy though to do the diff on the JAR libraries I can reproduce it on:) I believe it has to do with the tool they used to compress it that produced some unconventional JAR or some JDK version did it differently in the past. Maven central in my case could just run their JAR compression at any stage producing those files with any algorithm they like, which makes me question my project dependencies source and switch towards private repos as a 100% working alternative where you control compression and make sure IntelliJ is always happy ;)

Zacorich First of all, I think it is good that you mention your case here, as it might help other people finding the thread. Both of our problems are related after all. Anyway, I still think that it was not an issue of the JAR in my case.

As I said, it worked again after deleting the cache directory while using the exact same JAR. In one case it was a JAR from our own company owned Antifactory and I know that the JAR was not modified on the Artifactory. I actually also checked the JAR within the Gradle cache (to where it is downloaded) and verified that it did not change. (I also doubt that I would have re-imported the Gradle project at that moment, so Gradle probably did not have a chance to replace the Jar file in the first place, but I cannot say that I remember this detail by now.) In the second case, it was a JDK installed on my machine, so there was no remote-system involved which could have replaced the JAR file. So, I am pretty sure that it was the exact same JAR in both cases as I actually took steps to verify that. Anyway, the problem with the cache might have been resolved by now since I haven't observed the issue again.

Johanness , thank you for supporting my typing efforts :) It is very possible that IntelliJ caching had a bug when you experienced your problem. I just wanted to add that yesterday I did compare JARs I had issue with. One of them had one file deep inside the archive being corrupted what produced a file header error as a warning with the 7zip tool when extracting the JAR, but it did extract all the good remaining class files anyways, so it looks like you have a healthy JAR, if you ignore the warning. Where IntelliJ as of today just completely invalidates the contents of that “one class deep inside corrupted” JAR and doesn't show any files even those that can be extracted. Again some warning on those JARs would be really appreciated in the Project window as the only way to figure out that something is wrong is to experience missing classes when IntelliJ builds the project.