[GR-40187] Dectect invalid use of SVM specific classes on image class- or module-path.

[graalvmbot]

Sometimes projects falsely depend on svm.jar (or graal-sdk.jar) or transitively include svm classes in uber-jars. This also happens e.g. when a Maven projects depends on svm.jar but does not specify it as a dependency of type provided.

To better detect such misuse and to allow users to better understand what is wrong we make our com.oracle.svm.hosted.NativeImageSystemClassLoader able to detect such cases.

[olpaw]

@zakkak this PR will likely require changes on the quarkus side. We have identified quarkus examples that contain launcher jar files that put a graal-sdk on the classpath. This is why we have added workaround 7f83c75 in here. It runs those quarkus examples with -H:+TolerateBuilderClassesOnImageClasspath to make the builder tolerant towards having parts of the builder also on the image classpath. The correct fix though is to make sure quarkus does not create launchers that have graal-sdk on the classpath.

For example the tika-wrk benchmark that we download from https://lafo.ssw.uni-linz.ac.at/pub/graal-external-deps/tika-1.0.8.zip
embeds org.graalvm.sdk.graal-sdk-21.3.1.jar and puts it on the classpath via its MANIFEST.MF ClassPath: in tika-quickstart-1.0.8-runner.jar. This needs to be removed.

There must not be a graal-sdk.jar (or the classes contained in it) in the ClassPath: entries of the MANIFEST.MF of such launchers. Let me know if you want me to create a quarkus github issue for that.

[zakkak]

Thanks for the heads up @olpaw. I started a CI run with this branch to see how many of the integration tests it affects.

[zakkak]

@olpaw quarkusio/quarkus#28650 seems to do the trick for Quarkus.
It avoids adding svm.jar and graal-sdk.jar to the classpath for native builds.

Thanks again for the heads up.

[olpaw]

It avoids adding svm.jar and graal-sdk.jar to the classpath for native builds.

💯 Thanks a lot!