Remove ZipError usage which is dead code since JDK 9 (JDK-8336843).

[mbien]

• CachingArchive catches Exception from now on which seems to be the safest approach
• removed the ZipError handler from NexusRepositoryIndexerImpl since the section is inside a repo mutex
• JDK might remove the class itself at some point, see https://bugs.openjdk.org/browse/JDK-8336843 or the linked issue

closes #7818

[matthiasblaesing]

In general I agree with the direction. For the NexusRepositoryIndexerImpl, it might be better to also catch Exception. Reasoning: I don't see how the code could have raised an ZipError from the storage operation, but it could raised because the maven indexer fails to index the ZIP/JAR. That could happen independently from holding the repository mutex.

[mbien]

I take a look if I can improve the exception handling there. The MutexException, which represents all exceptions which can occur inside the mutex, is already caught a few lines later and directly sent to the exception window. The block inside the mutex doesn't really handle any Exception, even though everything inside of maven-indexer is mapped to IOEs.

The ZipError had to be caught separately, since my guess is that errors might not be mapped to MutexException.

[matthiasblaesing]

Ah I see now. The magic is in org.openide.util.Mutex#writeAccess which catches the orignal exception and wraps it into a MutexException, that is then caught.

If I'm not totally misreading the JDK (or my grep skills went into the weekend before me) ZipError was already not thrown anymore since at least JDK 11, so this should be safe.

[mbien]

If I'm not totally misreading the JDK (or my grep skills went into the weekend before me) ZipError was already not thrown anymore since at least JDK 11, so this should be safe.

yep, since the point when the zip impl switched from native to java which was JDK 9, see JDK-8145260, JDK-8336843

thanks for the review, merging