Graal: svm.jar declares wrong module-info

[bdemers]

The svm-20.1.0.jar declares the wrong module-info metadata.

open module org.objectweb.asm {
    exports org.objectweb.asm;
    exports org.objectweb.asm.signature;
}

This means that annotations com.oracle.svm.core.annotate.* cannot be used via JPMS.

It looks like there are a couple problems with this:

1.) If objectweb is included (uberjar) into the svm jar it should be shaded into a sub-package (ideally just included as a transitive dependency instead)
2.) The annotations could be pulled out into a separate jar (#1005)
3.) The current module-info _should_ be replaced with the correct one for this project. com.oracle.svm?
4.) The Maven groupId and root package are a little miss leading org.graalvm.nativeimage vs com.oracle.svm (obviously, this is not a requirement)

NOTE: I browsed the decompiled module-info.java from Intellij, so this information may not be perfect.

History

After upgrading from 20.0.0 to 20.1.0 (JDK 11) I ran into an issue:

Error: com.oracle.svm.hosted.substitute.DeletedElementException: Unsupported type jdk.internal.reflect.MethodAccessorGenerator is reachable

After seeing a similar error:
https://github.com/quarkusio/quarkus/issues/9633/

I attempted to use the same solution:
https://github.com/quarkusio/quarkus/pull/9686/files#diff-53f95f6cd460a468fc1204e2e102d09eR8-R25

This resulted in the JPMS problems above.

Workaround

Along with adding the Target_java_io_ObjectStreamClass workaround above, I had to remove my project's module-info.

Version

OpenJDK Runtime Environment GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02)

OS name: "mac os x", version: "10.15.4", arch: "x86_64", family: "mac"

[olpaw]

This looks like a bug. We should not need this since we can use jdk.internal.org.objectweb. I will have a look.

[olpaw]

Ha! That's a fun one. We have

"com.oracle.svm.hosted": {
    "subDir": "src",
    "sourceDirs": ["src"],
    "dependencies": [
        "com.oracle.objectfile",
        "com.oracle.svm.core",
        "com.oracle.graal.pointsto",
        "mx:ASM_7.1",
    ],
    ...
],

in substratevm/mx.substratevm/suite.py which makes us take
asm-7.1.jar:/module-info.class and copy it into svm.jar which of course is utterly stupid.

@dougxc any recommendations how to deal with such annoyances?

[olpaw]

I consider this an mx bug. Having a library in dependencies of an mx.project embeds it. Thus the libraries module-info (that describes its boundaries when used standalone) must not be copied into the place where it gets embedded. @dougxc I will create PR for mx to fix this.

[dougxc]

That should definitely be fixed. However, can we not replace the dependency on mx:ASM_7.1 with a JDK dependency somehow?

[olpaw]

However, can we not replace the dependency on mx:ASM_7.1 with a JDK dependency somehow?

Since we have jdk.internal.org.objectweb we should. I will certainly give it a try.

[olpaw]

I consider this an mx bug. Having a library in dependencies of an mx.project embeds it. Thus the libraries module-info (that describes its boundaries when used standalone) must not be copied into the place where it gets embedded. @dougxc I will create PR for mx to fix this.

Fixed: https://github.com/graalvm/mx/commit/8ec263992c7bffd22ab4e4e781e11f701cef442d

[olpaw]

@bdemers this is fixed on master and the next snapshot release will contain the fix. It will be available at: https://github.com/graalvm/graalvm-ce-dev-builds/releases soon.