←back to thread

Java Hello World, LLVM Edition

(www.javaadvent.com)
200 points ingve | 2 comments | 07 Dec 25 11:51 UTC | HN request time: 0s | source
Show context
namegulf ◴[07 Dec 25 19:54 UTC] No.46184561[source]▶
Wondering the benefits and how is this different from using GraalVM to build native images?

For eg. we could use Spring + Graal VM and get the application into native binaries without worrying too much about the low level stuff.

What are we missing?

replies(2): >>46184665 #>>46186816 #
gavinray ◴[07 Dec 25 20:08 UTC] No.46184665[source]▶
This article specifically discusses calling external C ABI libraries via the FFM API.

GraalVM is for compiling JVM bytecode to native, architecture-specific binaries.

FFM is like "[DllImport]" in .NET, or "extern" definitions in other languages.

The article shows how to auto-generate JVM bindings from C headers, and then allocate managed memory + interact with externally linked libs via the FFM API passing along said managed memory.

replies(2): >>46185022 #>>46187548 #
1. fniephaus ◴[07 Dec 25 20:50 UTC] No.46185022[source]▶
BTW: We (the GraalVM team) maintain a full-blown LLVM bitcode runtime that can be embedded in Spring or any other JVM application and compiled to native: https://github.com/oracle/graal/tree/master/sulong
replies(1): >>46185155 #
2. gavinray ◴[07 Dec 25 21:07 UTC] No.46185155[source]▶
May as well throw the Native Image C API for FFM-like capabilities out there too

https://www.graalvm.org/latest/reference-manual/native-image...

One of the neatest things I've been able to do is compile a .dll library "plugin" for an application which loads plug-ins by invoking a special exported symbol name like "int plugin_main()" using GraalVM and @CEntryPoint

The entrypoint function starts a Graal isolate via annotation params and no native code was needed