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

[in-fke]

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
• 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
• 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

[in-fke]

Come to think of it, if you ever wonder how one could run in the "could not find mapping for ..." and cacheJarFile() case, I had one: https://github.com/karakun/OpenWebStart/issues/385#issuecomment-1333008592

[anudeepg]

We are facing same issue, do we have any update on this ?

[janakmulani]

@anudeepg please can you describe what is your situation/use case and what issue are you facing

[anudeepg]

Thanks @janakmulani for reply.

We have a JavaFX app that is using spring component scanning at startup that is loading many classes & jars are signed. As a result. Openwebstart seems invoked during this scanning time and its very slow as same JAR seems loaded many times with log below ( As reported above, is there any possibility to cache this method to don't revisit same jar here if its already visited , this would greatly optimize , May be Oracle webstart does that already hence we are not seeing this with oracle =

Does openwebstart below code is invoked for each class inside same jar example : if we have 100 classes in 1 jar that is used by spring component scanning , will it call below code 100 times and loads/logs 100 times same JAR name ? This seems like the current issue as from logs as we see same JAR name printed several times, hence the reason of asking for caching feature even if by any feature toggle that would greatly help us ?

[ITW-CORE][net.sourceforge.jnlp.runtime.CachedJarFileCallback][JavaFX Application Thread#23b3f190]: Class-Path attribute cleared for Cached Jar <jarname>

[ITW-APP ][java.io.FilterOutputStream.write(FilterOutputStream.java:97)][JavaFX Application Thread#23b3f190]: 2025-05-01 10:46:08,602 [ INFO] [CorrelationID=] [User=] [org.springframework.context.annotation.AnnotationConfigApplicationContext] Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@71edcad6: startup date [Thu May 01 10:46:08 CEST 2025]; root of context hierarchy