Graal: Creating native image for HelloWorld fails for Java 11 on Windows

[tiainen]

Creating a native image for HelloWorld fails on Windows using Java 11. The following exception is thrown when running mx native-image HelloWorld

Exception in thread "main" java.lang.IllegalAccessError: class com.oracle.svm.util.ModuleSupport (in unnamed module @0x4f023edb) cannot access class jdk.internal.module.Modules (in module java.base) because module java.base does not export jdk.internal.module to unnamed module @0x4f023edb
        at com.oracle.svm.util.ModuleSupport.exportAndOpenAllPackagesToUnnamed(ModuleSupport.java:93)
        at com.oracle.svm.driver.NativeImage$JDK9Plus.main(NativeImage.java:1665)

[pquiring]

You need to use labsjdk available here:

https://github.com/graalvm/labs-openjdk-11/

Then is will work. I had the same problem.

[adinn]

That's rather inadequate as a resolution of the original query. Could you or someone else from Oracle attach (or reference, if it already exists):

1) some sort of explanation as to why Graal-supplied 'magic' builds work and standard OpenJDK builds are currently breaking (or, if any of them do work, which ones do so)

2) a schedule for remedying this very unfortunate situation, detailing, at least, the steps that will be taken to do so and, preferably, expected time to completion of each such step.

Thanks.

[dougxc]

I don't know much about the original error reported here, but to answer your first question, the issue is that the standard JDK binaries do not include the static libraries needed by Native Image ever since 9df8ca97ca95b14900be534b42a49d011049af93 and 35da937343d4b2b61b0df7ec2ee762881575bf85.

If you try to run mx native-image HelloWorld now with a standard JDK 11 binary, you will get the following:

> mx native-image HelloWorld
[helloworld:8563]    classlist:   2,682.95 ms
[helloworld:8563]        (cap):      15.72 ms
[helloworld:8563]        setup:     532.53 ms
Error: Building images for org.graalvm.nativeimage.Platform$DARWIN_AMD64 requires static JDK libraries.
Use JDK from https://github.com/graalvm/openjdk8-jvmci-builder/releases or https://github.com/graalvm/labs-openjdk-11/releases
Missing libraries:java, nio, net, zip
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Error: Image build request failed with exit status 1

Fixing this for OpenJDK will require back-porting https://bugs.openjdk.java.net/browse/JDK-8232118. There are a number of other changes related to this that also allow libgraal to be built:
https://bugs.openjdk.java.net/issues/?jql=labels+%3D+jdk11-graalvm

[adinn]

That is very interesting. So, you appear to have been backporting all these changes to Oracle's own builds of JDK11 but ignoring the upstream, shared OpenJDK 11u repo. It is not clear to me from the backport tags whether these changes are going into Oracle jdk11 product releases and GraalVM releases or just into the special builds the Graal team is distributing. Can you clarify that?

I am involved in backporting upstream changes to the shared jdk11u repo but this is the first I have heard of these backports. Would it not be a good idea to discuss the need for these backports on the jdk11u project mailing list? If that were done then there would be no need for users to keep downloading your 'magic' binaries. Is there a reason for not doing that? i.e. do you not want them to go into the jdk11u shared repo?

As it stands, the path you are following seems to be one that locks Graal CE users into having to rely on your tech, downloading your 'magic' binaries, rather than using whatever jdk11 they are using in development and production. That is certainly not what I would consider to be the the best way to grow a community of users and contributors who might, eventually, be willing to pay for for your supported product. Indeed, I think it is very likely to demotivate users from doing so.

[thomaswue]

We welcome efforts to backport those changes into the OpenJDK 11u repository. The tags on the issues in the public OpenJDK JIRA system should typically show the specific versions where they are landing.

We generally encourage users of GraalVM to get the canonical GraalVM CE or GraalVM EE binaries as available from: https://www.graalvm.org/downloads/

These are the binaries that undergo our extensive testing before released and make all GraalVM features available.

We can put this topic on the agenda of the community workshop. I believe there are some misunderstandings that are most effectively discussed in person.

[adinn]

Hi Thomas,

Thanks for your follow-up.

Of course, Red Hat are very happy to help with/do the backports to jdk11u. I cannot speak authoritatively for other jdk11u contributors like SAP, Azul etc. but I don't doubt they will also want to contribute.

The point I was making was that we need to know about what you are doing if we are to be able to help. I would really like to improve on the current position where we can only find out that you have backported a fix by searching the JIRA issues for the relevant tags. As it stands we don't know whether or not you would want all these changes in jdk11u -- it looks like some have been applied to an Oracle-internal graal jdk11u tree but not migrated to the mainline oracle jdk11u repo. Is there an important reason to keep some of these backports separate in your Graal builds only. We also don't know if you had to make changes to the original patches to make them work in jdk11u and, if so, whether that was due to the usual issues that arise in fitting a new patch to an old release or caused by extra, special disparities that apply to Graal backports in particular.

I am sure it would be easier all round if this work could be done collaboratively in upstream jdk11u rather than in your own private builds and then replicated blindly by us. For a start, we could we share the load when it comes to backporting. Also, we could ensure that your patches and other backports we are responsible for do not suffer from source incompatibilities that break the Graal compile or runtime incompatibilities that break Graal native builds or cause native images to behave differently.

I'll be very happy to talk about this at the upcoming workshop and also to try to make this work more efficiently and effectively both for us and for Graal users.