Is the routine "Class-Path attribute cleared for ..." expensive? (omit verification?)

I wonder if "clearing" the Class-Path attribute is expensive in some way? (re-reading the jar file)

Going by this PR there seems to be a re-read of the jar file?
https://github.com/AdoptOpenJDK/IcedTea-Web/commit/c7a6c2e35b303eab76cb8b225f9d23aa4a0b8107
here is the current source for better readability.
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/core/src/main/java/net/sourceforge/jnlp/runtime/CachedJarFileCallback.java#L87

The reason why this occurred to me was that start of our OSGI application is rather slow.
Our Eclipse Applications consists of 317 Bundles.
Grepping for "Class-Path attribute cleared for" in the stage2 log (OpenWebStart) gives us a count of 695 occurences.
Routine for extracting that log (Bash under Cygwin)
```
grep 'Class-Path attribute cleared for ' $(ls -rt $(cygpath 'C:\Users\NNN\.config\icedtea-web\log\')*stage2.log | tail -1) | sed -e 's/.*Class-Path attribute cleared for \(.*\)/\1/' | sort
```

shows us, that - probably due to OSGI or Eclipse mechanics - each bundle is "touched" at least twice this way, which would give us 634 occurrences. The remaining multiple occurrences come from bundles, which probably have special OSGI awareness.

- org.apache.logging.log4j.api 36 times, see [Logging Separation](https://logging.apache.org/log4j/log4j-2.17.1/manual/logsep.html)
- org.apache.xerces 30 times - haven't looked into that
- org.glassfish.jersey.core.jersey-common 3 times

To not just "cling" the only log output I have (from CachedJarFileCallback.java) I tried to activate some OSGI logging but could not manage.

Anyway, I was wondering if it would be worth "boosting" that routine, e.g. the "retrieve()" method could cache that "returnFile" ?
This would only be worth it, I guess, if we measure the timings of:
- CTOR for [JarFile](https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/core/src/main/java/net/sourceforge/jnlp/util/JarFile.java)
- timing of getManifest()

Another means could be opening the Jar file (in this case) **without verification**?
`public JarFile(File file, boolean verify, int mode)`

Or who is the caller of `retrieve()` and would the expect the Jar to be verified?

Alternatively, leave on verification but cache the result of `retrieve()` ? Not sure how cacheJarFile() works though (does not remove the Class-Path entry?).

**Is removing the Class-Path entry still necessary at all?**

related: https://github.com/spring-projects/spring-framework/issues/9371