Votes

Share

I am finding the same thing with IU-90.94.I just added a new module library (jar directory) as a dependency to the project and the JDK got scanned as well.As a test I then removed said module library and AGAIN the JDK got scanned!

Something weird going on here.Surely the JDK only needs to be scanned once when it is added to the env.

IDEA has always done this for me, even with 8.x. If there's something that keeps this from happening, I'd love to be able to, and I'm all ears. I think it is ridiculous that the JDK and all my third-party libraries are re-indexed each time I start the environment, especially since this represents the majority of the time spent indexing. It seems like a massive bug.

Some thoughts on the subject:1) There could be software bugs that could yield invalid caches. In this case some consistency check could be run on startup (asynchronously) to verify it. This could include forcing cache rebuild in case the next version knows it won't play nicely with the previous one's caches.2) Since the data is never updated in the immutable case, the corruption chance is extremely low, equal to physical corruption due to the disk damage, in which case the user should be better off to the store to buy a new disk:) So indeed it would be sufficient to check the consistency of the cache and its uptodateness wrt to jar mtime.3) In mutable case some more precise check is needed. In general since the corruption means the difference between the index and the source file, the validation requires the comparison, which is not much cheaper than rebuilding from scratch. However for particular cases the corruption detection code might see an algorithm to check the file for corruption and force its execution next time. This of course only refers to file-level indices.