Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/LWJGL/lwjgl3/llms.txt

Use this file to discover all available pages before exploring further.

Beyond graphics and audio, LWJGL 3 bundles bindings for a wide range of utility libraries: memory allocators, compression codecs, a high-speed database, developer profiling and debugging tools, and the LLVM compiler infrastructure. These bindings are individually optional and carry no mutual dependencies unless noted.
The current stable release is 3.4.2. Use the LWJGL build configurator to generate Maven or Gradle dependency declarations for the exact bindings you need.

Memory Allocators

LWJGL’s core module provides MemoryUtil and BufferUtils built on sun.misc.Unsafe / the FFM API, but these specialized allocators offer performance advantages for allocation-heavy workloads.

jemalloc

org.lwjgl:lwjgl-jemallocJEmalloc, JEmallocAllocatorA general-purpose malloc implementation that emphasizes fragmentation avoidance and scalable concurrency. Originally developed for FreeBSD, now used by Firefox and Meta’s production systems. Drop-in replacement for the system allocator with thread-local caching and low fragmentation.

rpmalloc

org.lwjgl:lwjgl-rpmallocRPmallocA public-domain, cross-platform, lock-free, thread-caching memory allocator with 16-byte alignment guarantees. Designed for high-throughput scenarios with many small, concurrent allocations. Particularly effective on multi-core hardware where per-thread caches eliminate most synchronization overhead.
Featurejemallocrpmalloc
LicenseBSD-2-ClausePublic domain
Thread cachingYesYes (lock-free)
Fragmentation controlExcellentGood
Alignment guaranteePlatform default16-byte minimum
Best forLong-running apps with mixed allocation sizesHigh-frequency small allocations on many threads
Both allocators expose malloc, calloc, realloc, and free equivalents that return ByteBuffer instances. You can pass them directly to LWJGL APIs that accept ByteBuffer parameters.

Compression

LZ4

org.lwjgl:lwjgl-lz4LZ4, LZ4Frame, LZ4HCAn extremely fast lossless compression algorithm focused on compression and decompression speed, not maximum ratio. LZ4 achieves decompression rates exceeding RAM bandwidth — ideal for real-time asset streaming, network packet compression, and in-memory caches where latency matters more than ratio.

Zstandard

org.lwjgl:lwjgl-zstdZstd, ZstdDecompressCtx, ZstdCompressCtxA fast lossless compression algorithm from Meta targeting real-time scenarios at zlib-level or better compression ratios. Zstandard supports dictionary compression (dramatically improving ratio for many small, similar assets) and a streaming API for large files.
MetricLZ4Zstandard
Compression speedExtremely fastFast
Decompression speedExtremely fastVery fast
Compression ratioModerateHigh (comparable to zlib or better)
Dictionary supportLimitedExcellent
Best forReal-time streaming, low-latency cachesAsset packing, network payloads, save files

Image Codecs

libspng

Maven artifact: org.lwjgl:lwjgl-spng
Key classes: LibSPNG, SpngCtx
libspng (simple PNG) is a C library for reading and writing PNG files with a strong focus on security and ease of use. It is significantly faster than libpng for decoding and passes the full PNG test suite.
// Decode a PNG file to raw RGBA pixels
long ctx = LibSPNG.spng_ctx_new(0);
try (MemoryStack stack = MemoryStack.stackPush()) {
    // set PNG data source (ByteBuffer), decode to SPNG_FMT_RGBA8
    IntBuffer widthBuf = stack.mallocInt(1);
    IntBuffer heightBuf = stack.mallocInt(1);
    // ... spng_set_png_buffer, spng_get_ihdr, spng_decode_image ...
} finally {
    LibSPNG.spng_ctx_free(ctx);
}
If you need to load multiple image formats (JPEG, BMP, TGA) in addition to PNG, prefer stb_image (org.lwjgl:lwjgl-stb) for its breadth. Use libspng when PNG decode performance or strict spec conformance is the priority.

Data and Databases

LMDB

Maven artifact: org.lwjgl:lwjgl-lmdb
Key classes: LMDB, MDBEnv, MDBDbi, MDBTxn, MDBVal
LMDB (Lightning Memory-Mapped Database) is an extraordinarily fast, memory-efficient key-value database. By memory-mapping files, it achieves the read performance of a pure in-memory database while retaining the persistence of a disk-based store. It uses a copy-on-write B-tree with ACID transactions and MVCC (Multi-Version Concurrency Control). Key characteristics:
PropertyValue
Data modelOrdered key-value (B-tree)
TransactionsACID, MVCC (multiple concurrent readers, one writer)
API modelZero-copy — keys and values are pointers into the mmap
Max databases per environmentConfigurable (default 1)
Max readersConfigurable (default 126)
LicenseOpenLDAP Public License
// Open an environment and put/get a value
long env = LMDB.mdb_env_create();
LMDB.mdb_env_open(env, "/tmp/testdb", 0, 0664);

long txn = LMDB.mdb_txn_begin(env, NULL, 0);
IntBuffer dbi = stack.mallocInt(1);
LMDB.mdb_dbi_open(txn, (String) null, 0, dbi);

MDBVal key = MDBVal.malloc(stack).mv_data(stack.UTF8("hello"));
MDBVal val = MDBVal.malloc(stack).mv_data(stack.UTF8("world"));
LMDB.mdb_put(txn, dbi.get(0), key, val, 0);
LMDB.mdb_txn_commit(txn);

ODBC

Maven artifact: org.lwjgl:lwjgl-odbc
Key classes: SQL, SQLH, SQLTypes
ODBC (Open Database Connectivity) is the standard C-language interface for accessing relational databases. The LWJGL binding exposes the Windows ODBC API, enabling Java applications to connect to SQL Server, Oracle, PostgreSQL (via ODBC driver), and any other ODBC-compliant data source without a JDBC driver.
The LWJGL ODBC binding targets the native Windows ODBC Driver Manager. It is not available on macOS or Linux unless you install unixODBC and set up java.library.path accordingly. For cross-platform database access from Java, a JDBC driver is typically a simpler choice.

Developer Tools

Remotery

org.lwjgl:lwjgl-remoteryRemoteryA real-time CPU and GPU profiler implemented in a single C file. Remotery streams profiling data over WebSockets to a viewer running in any web browser — no installation required on the target machine. Supports OpenGL, Direct3D 11/12, Vulkan, and Metal GPU timers.

RenderDoc

org.lwjgl:lwjgl-renderdocRenderDocProgrammatic API for the RenderDoc GPU frame debugger. Lets your application trigger frame captures, set capture keys, and launch the RenderDoc replay UI from code — useful for automated graphics regression testing and in-app debugging shortcuts.
Remotery usage:
// Initialize and instrument CPU work
Remotery._rmt_Settings settings = Remotery._rmt_Settings.create();
long rmt = Remotery.rmt_CreateGlobalInstance();
// Wrap sections with rmt_BeginCPUSample / rmt_EndCPUSample
// Then open http://localhost:17815 in a browser to view the timeline
Remotery.rmt_DestroyGlobalInstance(rmt);
RenderDoc usage:
// Load the RenderDoc API at startup
RenderDocAPI api = RenderDoc.RENDERDOC_GetAPI();
// Trigger a frame capture programmatically
api.TriggerCapture();
// Launch the UI
api.LaunchReplayUI(1, null);
Both tools work best during development builds. Guard their initialization behind a debug flag so the profiling and capture overhead is absent in release builds.

Hash Algorithms

xxHash

Maven artifact: org.lwjgl:lwjgl-xxhash
Key classes: XXHash, XXH32State, XXH64State, XXH3State
xxHash is an extremely fast, non-cryptographic hash algorithm that runs at RAM speed limits. It is significantly faster than CRC32, MurmurHash, and FNV while maintaining excellent distribution quality.
VariantWidthNotes
XXHash.XXH3232-bitFastest on 32-bit targets
XXHash.XXH6464-bitFastest on 64-bit targets
XXHash.XXH3_64bits64-bitBest overall: faster than XXH64 with better avalanche
XXHash.XXH3_128bits128-bitHighest quality; same speed as XXH3_64
Use cases: asset fingerprinting, hash-map keys for large buffers, change detection for scene graphs, integrity checks on compressed asset bundles.

System Information

hwloc

Maven artifact: org.lwjgl:lwjgl-hwloc
Key classes: HWLoc, HWLocTopology, HWLocObject
hwloc (Portable Hardware Locality) provides a portable abstraction of the hierarchical topology of modern hardware: NUMA memory nodes, CPU sockets, shared L1/L2/L3 caches, cores, and hardware threads (SMT). It can also query PCI devices, GPUs, and network interfaces. Use cases:
  • Binding threads to specific cores or NUMA nodes for cache-aware parallelism
  • Determining the number of physical cores versus logical threads
  • Querying GPU/CPU proximity for optimal OpenCL or CUDA device selection
  • Building topology-aware work-stealing thread pools
long topology = HWLoc.hwloc_topology_init();
HWLoc.hwloc_topology_load(topology);

// Walk the topology tree
long root = HWLoc.hwloc_get_root_obj(topology);
int depth = HWLoc.hwloc_get_type_depth(topology, HWLoc.HWLOC_OBJ_CORE);
int nCores = HWLoc.hwloc_get_nbobjs_by_depth(topology, depth);
System.out.println("Physical cores: " + nCores);

HWLoc.hwloc_topology_destroy(topology);

Compiler Infrastructure

LLVM

Maven artifact: org.lwjgl:lwjgl-llvm
Key classes: LLVM, LLVMCore, LLVMBitReader, LLVMBitWriter, LLVMExecutionEngine, LLVMOrcJIT
LLVM is a collection of modular and reusable compiler and toolchain technologies. The LWJGL binding exposes the LLVM C API, covering IR construction, optimization passes, bitcode reading/writing, and JIT compilation via the ORC JIT engine. Capabilities exposed:
ModuleDescription
LLVMCoreIR builder: modules, functions, basic blocks, instructions
LLVMBitReader / LLVMBitWriterRead and write LLVM bitcode (.bc) files
LLVMAnalysisVerifier and analysis passes
LLVMTransforms*Optimization passes (instcombine, mem2reg, vectorize, etc.)
LLVMExecutionEngineMCJIT-based JIT compilation
LLVMOrcJITModern ORC JIT v2 — lazy compilation, symbol linking
LLVMTarget*Code generation for x86, ARM, AArch64, RISC-V, WebAssembly
The LLVM binding requires a matching LLVM native library. LWJGL does not bundle a pre-built LLVM native JAR — you must supply libLLVM.so / LLVM.dll / libLLVM.dylib built for your target platform and version. Check the LWJGL wiki for build instructions.

Foreign Function Interface

libffi

Maven artifact: org.lwjgl:lwjgl-libffi
Key classes: LibFFI, FFICIF, FFIType, FFIClosure
libffi provides a portable, high-level interface to various C calling conventions. It lets you call arbitrary C functions described at runtime (without compile-time bindings) and create “closures” — native function pointers that, when called from C, invoke Java code. Primary use cases in LWJGL:
  • Implementing runtime-defined callbacks for C libraries that require function pointer parameters
  • Calling native APIs that are not yet covered by an LWJGL binding, without writing JNI
  • Building dynamic language runtimes or plugin systems that call native code
libffi is a building block for LWJGL’s own callback infrastructure. For most use cases, the higher-level callback classes generated per-binding (e.g., GLFWKeyCallbackI, ALCErrorCallback) are easier to use than raw libffi closures.

Build docs developers (and LLMs) love