Custom bindings

[kenwenzel]

Hello,

is it somehow possible to create custom bindings for LWJGL which do not need to be directly integrated into the modules directory?

We are using LMDB as database backend for https://github.com/eclipse-rdf4j/rdf4j and I want to investigate if https://github.com/datalevin/dlmdb/ is a better alternative for our usage scenario.

Thank you and best regards,
Ken

[cookesan]

For LMDB specifically, LWJGL already ships an lwjgl-lmdb module.

The normal LWJGL distribution is module-based: core is required and bindings are optional modules. In this repo, LMDB is listed as lwjgl-lmdb in the Gradle module list, enabled in the binding config, and has generated/native sources under modules/lwjgl/lmdb.

If you want to use LMDB from Java, the simplest path is to depend on the existing org.lwjgl:lwjgl-lmdb artifact plus the matching native artifact for your platform.

If you mean "can I use LWJGL's generator for my own external binding without adding a module under modules/?", I would not assume that is a supported workflow. The repo's generator/build layout is organized around modules. For an out-of-tree experiment, maintaining a separate JNI/JNA/FFM wrapper is likely simpler than trying to make LWJGL's build produce a non-module binding.

[kenwenzel]

Thank you for the reply. We are already using the lwjgl-lmdb artifacts as mentioned by you. It seems that the only way for compiling a custom module is a fork and rebiuid of LWJGL with the additional module.
We heavily rely on LWJGL memory Management and APIs (like MemoryStack) that's why it is hard to use another JNI/FFM wrapper just for experimenting.

[Spasi]

Hey @kenwenzel,

LWJGL builds LMDB into a JNI library with dedicated native methods. Even if the dlmdb API is compatible, there's no way to replace the lwjgl_lmdb binary with another build, because it will be lacking the JNI functions that Java needs.

If datalevin can afford to require JDK 25 or newer, my recommendation would be: build dlmdb into a standard .so and use the org.lwjgl.system.ffm API in LWJGL 3.4.0+ to create custom FFM-based bindings. SegmentStack provides the equivalent MemoryStack functionality for FFM segments, however it is trivial to convert between NIO buffers and MemorySegment if necessary.

Otherwise, it's either a new module in LWJGL as you said, or you can get creative with the existing lmdb module (replace the C source with dlmdb and add any new API in the existing bindings).

[kenwenzel]

Thank you for the pointer to the FFM-based API. We're currently using LWJGL+LMDB due to its good performance. Do you have some information if we need to expect some slow downs?

[Spasi]

The runtime-generated bindings optimize to equivalent FFM downcalls, which are generally slightly faster than JNI and you have the option to make some critical (see the @FFMCritical annotation). Upcalls are much faster than JNI.

Off-heap memory access via MemorySegment is mostly equivalent to access via NIO buffers but, depending on the application, there are some problematic cases. However, 3.4.2 snapshots include configurable memory access backends (see Configuration#MEMORY_BACKEND). The two Unsafe-based backends eliminate any issues you may face in performance-sensitive code.