[GR-30247] Footprint optimization: JarVerifier is transitively including a lot of crypto classes

[sdeleuze]

In our journey to optimize the footprint of Spring Boot native images (but that issue is not Spring Boot specific), we have found that JarVerifier is transitively including a lot of crypto classes in the native image. In practice loading a JAR and verifying their signature is not used in native images but they are on the code path analyzed by the static analysis, mostly for Manifest parsing and verification.

An experiment I did with this experimental substitution shows a 2M image size and related memory consumption reduction. I am wondering if we could find a global optimization that could solve that issue for most native use cases.

Tested with GraalVM 21.0.0 - Java 11.

[munishchouhan]

@sdeleuze Thanks for reporting the Issue We will check it out and come back to you

[wirthi]

Quick update: This item is still on our roadmap, with rather low priority though. If anyone wants to tackle it, we are happy to accept contributions that solve this problem.