Graaljs: Using JS from SubstrateVM misses the type Java

[pmlopes]

When you build a native image with script support the type Java is missing. I'd like it to be there for classes that have been "whitelisted" on the reflection.json to be used as:

Java.type('MyClass')

[wirthi]

Hi Paulo,

yes, correct. Right now, Graal.js completely turns off Java interop when operating on SubstrateVM (native image). We are blocked by Truffle not providing any data for Java classes on SVM.

The Truffle team is working on a fix for this, i.e., allowing interop access to the classes that are in fact in the image (e.g., by whitelisting them). Once this feature becomes available, Graal.js will enable the parts of the Java builtin that we can support even in the native image (e.g., Java.type will be available with those limitations, but Java.extend won't).

Best,
Christian

[willr3]

Is Java Interop still off on SubstrateVM? A few hours getting native-image to build an image and I found Java bindings existed in the global scope but did not have methods despite using @Exportedon the methods.

[iamstolis]

Is Java Interop still off on SubstrateVM?

No, it is not. You can use Java interop in the image built using native-image.

I found Java bindings existed in the global scope but did not have methods despite using @Exported on the methods.

Note that Java interop is based on Java reflection. Java reflection in native-image requires some configuration. So, I guess that your methods cannot be called because they are not "exported" for the reflection in the image. Sure, it would be nice if there was a support for an easy/automatic reflection "export" of all @Exported members but I am not aware of such feature by now. Does explicit white-listing of your methods through -H:ReflectionConfigurationFiles resolve you troubles?

[willr3]

@iamstolis Thank you! Adding -H:ReflectionConfigurationFiles with all the classes that have @HostAccess.Export worked. Now to get myself a CPU with more cores to speed up builds :)