3 ms·

I hadn't heard of Vertx until my most recent job where we use it for our platform. We currently deploy in openjdk docker containers. This seems neat, but I'm w

I hadn't heard of Vertx until my most recent job where we use it for our platform. We currently deploy in openjdk docker containers. This seems neat, but I'm wondering about dependencies. Does Graal rebuild all your dependent jars to be native? What if you have unsupported things like reflection in a dependency? I'm looking through their website and can't seem to find any answers. We've already run into dependencies for Vertx that puke on Java 9 (depreciated/removed API) and are currently still on Java 8. This seems nice, but I have a feeling that, for production, you'd end up writing a lot around GraalVM.

nwatson 8y ago
The "limitations" link in the posted page has a section on "Reflection", [1]. It says: "Support Status: Mostly supported ... Individual classes, methods, and fields that should be accessible via reflection must be specified during native image generation in a configuration file ..." I'd assume libraries your app depends on should be usable via Reflection as well, and that their own calls to reflection APIs should work as well, as long as the classes your code, or the library codes, want to reach are somehow included in the Java --> Native conversion configuration files. [1] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#reflection https://github.com/oracle/graal/blob/master/substratevm/LIMI...
shellac 8y ago
My understanding is that Graal is doing whole-application compilation, so the dependent jars will be compiled. Reflection is an issue that they have a work around for. There's a good article illustrating various issues [1] in the case of netty written by one of the graal team. (There you'll see an example of a reflection configuration file) [1] https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692 https://medium.com/graalvm/instant-netty-startup-using-graal...

nwatson 8y ago

The "limitations" link in the posted page has a section on "Reflection", [1]. It says: "Support Status: Mostly supported ... Individual classes, methods, and fields that should be accessible via reflection must be specified during native image generation in a configuration file ..." I'd assume libraries your app depends on should be usable via Reflection as well, and that their own calls to reflection APIs should work as well, as long as the classes your code, or the library codes, want to reach are somehow included in the Java --> Native conversion configuration files. [1] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#reflection https://github.com/oracle/graal/blob/master/substratevm/LIMI...

shellac 8y ago

My understanding is that Graal is doing whole-application compilation, so the dependent jars will be compiled. Reflection is an issue that they have a work around for. There's a good article illustrating various issues [1] in the case of netty written by one of the graal team. (There you'll see an example of a reflection configuration file) [1] https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692 https://medium.com/graalvm/instant-netty-startup-using-graal...