Java Hello World, LLVM Edition

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?

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.

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

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

people still use make for things. how many stand-alone utilities require npm?

i don't know graalvm, but I've used too much ant, buldr, gradle and maven. I'm not really convinced Graal VM would make anything better just because you are more familiar with it.

The author even says to just use what you like because that part doesn't matter.

ant, buldr, gradle and maven - are build tools

we're talking about native code here

Don't we have JNI for that?