[GR-52515] META-INF/native-image/... files are ignored in some JARs (large, zip64, self-extracting)

[nreid260]

Describe the issue Running native-image -jar my_strange.jar doesn't detect or use any of the META-INF/native-image/... files inside, but a native image is generated. The internal META-INF/MENIFEST.MF is found to correctly identify the main class.

The particular JAR I'm using is very large, in zip64 format, and self-extracting. It's a fat JAR of the Kotlin-JVM compiler, plus some wrapper code that acts as the main entry point.

The config files themselves are valid. They work if extracted from the main JAR into a second JAR, passed using -cp.

Steps to reproduce the issue Unfortunately, I observe this using a propriety build system. I know no way to repro it externally.

Describe GraalVM and your environment: native-image 21 2023-09-19 OpenJDK Runtime Environment GraalVM CE 21+35.1 (build 21+35-jvmci-23.1-b15) OpenJDK 64-Bit Server VM GraalVM CE 21+35.1 (build 21+35-jvmci-23.1-b15, mixed mode, sharing)

More details The --verbose flag does not list the relevant config files as Apply ...

[mukel]

~Shouldn't it be META-INF/native-image/... ?~

[nreid260]

I have confirmed that running unzip -> zip fixes this issue, so there's definitely some part of the ZIP format that native-image doesn't support.

I also noticed that resource-config.json matching fails in the original JAR. Probably the same underlying cause.

[fernando-valdez]

You can manually include resources using the -H:IncludeResources flag when running native-image. This can be a workaround if automatic detection fails:

native-image -jar my_strange.jar -H:IncludeResources="META-INF/native-image/.*"

As a diagnostic step, try creating a simpler version of the JAR without the self-extracting feature and in standard zip format, if possible. This can help isolate the issue to the zip64 or self-extracting features.

Finally, can you please use the latest version of Oracle GraalVM instead of GraalVM CE and share your results?

[nreid260]

I have confirmed that the issue is with self-extracting JARs.

[fniephaus]

Thanks for the report, @nreid260. We understand you can't share your application, but is there any way you could put together a self-extracting JAR, or instructions for creating one, for a simple example that we can use to reproduce this?

[fernando-valdez]

Internal ticket created: GR-52515

[Mohamed-Hammada]

I've also observed that this issue arises when I utilize the useFatJar = true option. It's worth noting that my monolithic application has approximately 70 dependencies.

graalvmNative {
    binaries {
        main {
            imageName = "my-app"
            mainClass = "com.company.MainApplication"
            useFatJar = true
        }
    }
}