3.1.2

Released 2017 May 15

This build includes the following changes:

Bindings

• Added OpenVR bindings.
• Added Tiny OpenEXR bindings.
• Added Yoga bindings.
• bgfx: Updated to API version 41 (up from 34)
• glfw: Updated to pre-release 3.3.0 version (up from 3.2.1). Includes many fixes and new features:
  • Last error code query (glfwGetError)
  • Requesting attention from the user (glfwRequestWindowAttention)
  • Platform dependent scancodes for keys (glfwGetKeyScancode)
  • Window maximization events (glfwSetWindowMaximizeCallback)
  • Window attribute modification (glfwSetWindowAttrib)
  • Joystick hats (glfwGetJoystickHats)
  • Library initialization hints (glfwInitHint)
  • Headless OSMesa backend
  • Cursor centering control (GLFW_CENTER_CURSOR)
  • macOS: Cocoa hints (GLFW_COCOA_RETINA_FRAMEBUFFER, GLFW_COCOA_FRAME_AUTOSAVE, GLFW_COCOA_GRAPHICS_SWITCHING, GLFW_COCOA_CHDIR_RESOURCES, GLFW_COCOA_MENUBAR)
  • macOS: Vulkan support via MoltenVK
  • X11: Moved to XI2 XI_RawMotion for disabled cursor mode motion input
  • EGL: Added support for EGL_KHR_get_all_proc_addresses and EGL_KHR_context_flush_control
• jemalloc: Updated to 4.5.0 (up from 4.4.0)
• LibOVR: Update to 1.14.0 (up from 1.10.0)
• lmdb: Updated to 0.9.20 (up from 0.9.18)
• NanoVG: Added support for fallback fonts.
• nuklear: Updated to 1.37.0 (up from 1.29.1, with the new versioning)
• OpenAL: Added AL_SOFT_source_resampler extension.
• stb
  • Updated stb_dxt to 1.0.6 (up from 1.0.4)
  • Updated stb_easy_font to 1.0 (up from 0.7)
  • Updated stb_image to 2.15 (up from 2.13)
  • Updated stb_image_resize to 0.94 (up from 0.91)
  • Updated stb_image_write to 1.05 (up from 1.02)
  • Updated stb_perlin to 0.3 (up from 0.2)
  • Updated stb_rect_pack to 0.11 (up from 0.10)
  • Updated stb_truetype to 1.15 (up from 1.12)
  • Updated stb_vorbis to 1.10 (up from 1.09)
• tinyfiledialogs: Updated to 2.8.3 (up from 2.7.2)
• Vulkan: Updated to 1.0.49 (up from 1.0.38)

Improvements

• MemoryStack: Increased default stack size to 64kb (up from 32kb)
• Shared library loading can now utilize a ClassLoader specified by the caller. (#277)
• Significantly reduced DEBUG_MEMORY_ALLOCATOR and DEBUG_STACK overhead in Java 9 using the new StackWalker API.
• Migrated windows builds to appveyor and updated to Visual Studio 2017 (up from 2015)
• EGL: The core API now includes javadoc links to the Khronos references pages
• OpenGL ES: The core API now includes javadoc links to the Khronos references pages

Fixes

• Assimp: Struct member nullability fixes
• Linux: Removed dependencies to newer GLIBC versions.
• LibOVR: Fixed layout of the ovrInputState struct.
• OpenAL: Removed buffer auto-sizing from alcCaptureSamples. The number of samples must now be specified explicitly, similar to alcRenderSamplesSOFT.
• Vulkan: Function addresses are now retrieved only once, using the optimal method for each function type.
  • This avoids warnings on pedantic validation layers.
• Fixed callback invocation bugs on 32-bit architectures.
• Fixed various javadoc formatting issues (#308)

Breaking Changes

• Mapped more integer parameters and return values to Java boolean, that were missed while working on #181.
  • Xlib's Bool
  • OpenCL's cl_bool
  • DynCall's DCbool
• Moved JNI global reference functions from MemoryUtil to the generated org.lwjgl.system.jni.JNINativeInterface.
• The Vulkan capabilities have been split into two classes: VKCapabilitiesInstance and VKCapabilitiesDevice.
  • Flags for core Vulkan versions exist in both classes.
  • Flags for instance extensions exist only in VKCapabilitiesInstance.
  • Flags for device extensions exist only in VKCapabilitiesDevice.
  • Functions that dispatch on VkInstance or VkPhysicalDevice exist only in VKCapabilitiesInstance.
  • Functions that dispatch on VkDevice and device-derived handles exist only in VKCapabilitiesDevice.
  • Bootstrapping functions can be retrieved with VK.getFunctionProvider().

Download

Full change log since the last release can be found here.

You can download LWJGL from the download page at lwjgl.org/download

After hundreds of commits including additions, updates, performance improvements and bug fixes, we are proud to announce the release of LWJGL 3.1.0.

The significant updates include a new module distribution structure and new bindings for:

• BGFX (special thanks to @code_disaster)
• LMDB
• Tiny File Dialogs
• Nuklear

A more detailed change log since the last release can be found here.

You can download LWJGL from the really cool new download page at lwjgl.org/download

The download page now includes the ability to generate custom download builds of LWJGL (meaning a build that includes only the bindings you need), special thanks to @apostolos for the nice build configurator.

Java 1.4 was released in early 2002. LWJGL was created a few months later.

This was not a coincidence. Java 1.4 finally made it possible to access off-heap memory from Java and efficiently inter-operate with native code. Using java.nio and direct ByteBuffer instances, Java developers could:

• Allocate off-heap memory.
• Fill buffers with data and pass them down to native code, without expensive copies.
• Access the contents of buffers managed by external libraries.

LWJGL 3 was born in late 2012. It is a clean rewrite of LWJGL, officially released on June 2016. Like its predecessor, it provides bindings to popular native libraries via JNI and uses NIO buffers to pass data around. The primary goal of the library is to provide the best performance/usability/safety balance possible, at least until Project Panama is released (hopefully) in Java 10.

In the meantime, NIO buffers have been getting a lot of bad rep, which is mostly justified. There are a lot of complains about how they're designed, how they're used (or not used) in various APIs, how they perform. The purpose of this post is to explain how LWJGL 3 addresses these issues.

Disclaimer:

The following applies to the platforms LWJGL supports: Linux, MacOS, Windows. LWJGL requires Java 8 and we have tested with OpenJDK, Oracle JDK, Azul Zulu, IBM JDK. Decisions made may or may not be optimal on other JDKs/JVMs. LWJGL does not support (or even work on) Android yet, but it's almost certain that different strategies will have to be used there.

Strategy #1

Heap buffers are strictly forbidden. All buffers must be off-heap (DirectByteBuffer and derivatives) to be accepted by the LWJGL API.

Heap buffers might be cheap to allocate and trivial to cleanup (via standard GC), but they force data copies when passed to native code.

They needlessly complicate all code paths that accept NIO buffers.

They make a lot of call sites bimorphic or even megamorphic. An application that uses direct buffers exclusively can do anything. An application that allows heap buffers cannot avoid direct buffers (e.g. when dealing with data managed by native libraries). This mix of concrete types means the JVM will have a harder job optimizing code.

All ByteBuffer instances created by LWJGL are in the native byte order. Views are always naturally aligned to the element type. If users are also careful with alignment, all buffers will be instantiated from the same concrete class on all platforms (e.g. DirectIntBufferU for the IntBuffer abstract class). You can easily have an application where all buffer call sites are monomorphic.

Strategy #2

Buffer instances passed to LWJGL APIs are never mutated.

This applies to the POJO wrappers themselves, not the off-heap memory they point to. In C terms, we treat e.g. an IntBuffer argument as a const pointer to int, not as a pointer to const int.

Standard NIO code typically changes the position of buffers it consumes, up to the point where data reads or writes occurred. This causes redundant (heap) mutations and requires a lot of flip(), reset() and clear() calls in user code.

Buffers passed to LWJGL APIs are never mutated. The values returned by position() and limit() after an LWJGL call are exactly the same as before. This leads to cleaner, easier to understand, code.

For the same reason, the use of absolute gets and puts is encouraged when writing LWJGL code.

Strategy #3

The JNI functions NewDirectByteBuffer, GetDirectBufferAddress and GetDirectBufferCapacity are never used.

In pure Java, you cannot:

• create direct ByteBuffer instances at arbitrary memory addresses and
• retrieve the memory address of a direct buffer instance.

The officially supported way to do this is in JNI code, using the above functions. This is a serious problem.

In LWJGL, buffer instances are never passed to or from native code:

• The address of a buffer at its current position() is extracted using Unsafe and passed to JNI code as a jlong, not as a jobject. Then it is cast to the appropriate pointer type and used directly.
• The address of buffers managed by native libraries is returned to Java code as jlong values, not as jobject. In Java, it is wrapped into the appropriate buffer instance (using Unsafe) and used directly.

First, lets address the elephant in the room. Yes, we do use Unsafe for this. We're not happy about it either, but there is no alternative. VarHandles in Java 9 will not help, because we're accessing private implementation details. Unless a pure Java alternative is provided in Java 9, this is the best we can do until Java 10 and Project Panama (looks like we'll stop using NIO buffers then anyway).

So, why go through all this trouble? Well, actually it's no trouble at all, because it greatly reduces the amount of JNI code required. Not only because the above functions are never called, but it also moves all pointer arithmetic to Java code (GetDirectBufferAddress returns the base buffer address, regardless of current position() and buffer element type). In addition to smaller JNI functions, LWJGL is able to generate Java method overloads with different buffer types, all reusing the same native method. Fixing bugs is also easier. Using standard Java tools and debuggers you can easily identify issues since the native code basically does nothing and all the relevant information is on the Java side.

But the greatest benefit is another and it is what differentiates LWJGL from other libraries. Passing Java objects to and from native code makes them escape, by definition. This means that escape analysis can never eliminate allocations of such objects when dealing with standard JNI code.

LWJGL's approach on the other hand lets escape analysis do its job. In the vast majority of cases, where buffers are allocated locally, used in native methods, then discarded, EA works great and eliminates the Java-side allocations. When it doesn't work, the JVM provides sufficient diagnostic flags (e.g. -XX:+PrintEscapeAnalysis) that enable troubleshooting. Usually a little bit of refactoring and writing cleaner code resolves the issue.

Strategy #4

Use of ByteBuffer.allocateDirect() is highly discouraged.

LWJGL versions before 3 relied exclusively on allocateDirect(), via the org.lwjgl.BufferUtils class. This class is still there in 3, for backwards-compatibility, but its use is highly discouraged. The reason is simple, allocateDirect() is horrible:

• It is slow, much slower than the raw malloc() call. A lot of overhead on top of a function that is already slow.
• It scales badly under contention.
• It arbitrarily limits the amount of allocated memory (-XX:MaxDirectMemorySize).
• Like Java arrays, the allocated memory is always zeroed-out. This is not necessarily bad, but having the option would be better.
• There's no way to deallocate the allocated memory on demand (without JDK-specific reflection hacks). Instead, a reference queue is used that usually requires two GC cycles to free the native memory. This quite often leads to OOM errors under pressure.

All of that contributed to users adopting one or more bad practices when dealing with LWJGL code:

• Using buffer instance pools.
• Using global buffer instances, often not in a concurrent-safe way.
• Allocating big buffers and writing their own "memory allocator" on top, often with far from optimal results with respect to performance, memory utilization & fragmentation, etc.

The recommended way to deal with these issues in LWJGL 3 is via explicit memory management. We have the org.lwjgl.system.MemoryUtil class that uses a configurable memory allocator and exposes a user-friendly API, but other allocators can be used directly, as dictated by application requirements.

We have the org.lwjgl.system.libc.Stdlib class that basically exposes the system default memory allocator. It provides the functions you would expect: malloc, calloc, realloc, free, aligned_alloc, aligned_free.

We also bundle the jemalloc library with LWJGL. It provides the same functions as above and many more for specialized use-cases. This is the default allocator used in MemoryUtil (when available and not overridden), because:

• It is generally faster than the system default.
• It scales better under concurrent allocations.
• It is highly configurable and tunable for specific applications.
• The build that comes with LWJGL is tuned for performance, but it can easily be replaced with a custom build that enables more features: statistics, debugging, leak detection, etc.

I will not discuss here how explicit memory management is not the "Java way", it's a topic for another post. Hint: I mostly agree, but not in the context of inter-operating with native systems.

Strategy #5

Always prefer stack allocation.

As fast as jemalloc is, stack allocation is always faster. This has always been an aspect in which Java could never compete with C code. Fortunately, LWJGL offers a solution for that too.

The solution is the org.lwjgl.system.MemoryStack class that exposes an API for stack allocations. The recommendation is that any small buffer/struct allocation that is shortly-lived, should happen via the stack API. This approach shines even in tight loops and shows how important strategy #3 is. Example code (using try-with-resources, one of the possible code styles):

// OpenGL code
try ( MemoryStack stack = stackPush() ) { // thread-local lookup
    IntBuffer ip = stack.mallocInt(1); // ip instance eliminated
    glGetIntegerv(GL_NUM_COMPRESSED_TEXTURE_FORMATS, ip);

    IntBuffer formats = stack.mallocInt(ip.get(0)); // formats instance eliminated
    glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, formats);

    // ...
} // stack is automatically popped, buffers are freed

Applicable to structs as well:

// Vulkan code
try ( MemoryStack stack = stackPush() ) {
    VkCommandBufferBeginInfo cbi = VkCommandBufferBeginInfo.mallocStack(stack)
        .sType(VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO)
        .pNext(NULL)
        .flags(0)
        .pInheritanceInfo(
            VkCommandBufferInheritanceInfo.mallocStack(stack) // nested struct
                .sType(VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO)
                .pNext(NULL)
                .renderPass(VK_NULL_HANDLE)
                .subpass(0)
                .framebuffer(VK_NULL_HANDLE)
                .occlusionQueryEnable(false)
                .queryFlags(0)
                .pipelineStatistics(0)
        );

    int err = vkBeginCommandBuffer(cmd, cbi);
    check(err);

    // ...
} // structs are automatically freed

Strategy #6

Offer tools for debugging.

Having great performance is nice, but bugs related to explicit memory management can be hard to track down. LWJGL helps with:

• Basic checks. These are enabled by default and ensure basic invariants with respect to API usage. The most important are related to buffers that cannot be NULL and buffer sizes that must be within certain ranges. This applies to both method parameters and struct members.
• A debug mode. When enabled, LWJGL performs additional checks, that may be too expensive to perform by default.
• A debug memory allocator. When enabled, all allocations are tracked and any leaks are reported when the JVM process ends. Each leak includes how many bytes where allocated and where exactly (with a full stack trace). Tracking is enabled for allocations via MemoryUtil as well as native-to-Java callback instances.
• A stack allocation debugger. When enabled, LWJGL reports methods that have a broken symmetry between stack push & pop.

Summary

All of the above strategies contribute to the final "look and feel" of writing code for LWJGL, which can be summed up as: clean and efficient.

The greatest insight we gained while working on LWJGL 3 is that escape analysis works fantastically well in Java 8+. After several iterations, the final API does very little to encourage buffer instance reuse; it's simply not needed. Writing clean Java code, short and simple, does wonders not only for pure Java, but also when interacting with native libraries.

There are several, very useful native libraries out there. Waiting for a pure Java port or an abstraction in the JDK just because of how ugly and inefficient JNI code usually is, should be a thing of the past. LWJGL's approach works right now. Soon, Project Panama will eliminate most (if not all) remaining overhead and together with value types and any-generics will provide an extra level of type safety, bringing to Java a very strong FFI solution.

After more than 3 years of development, the LWJGL team is proud to announce the official release of LWJGL 3.0.0.

It contains bindings for the following libraries:

• EGL - An interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system.

• OpenCL - An open, royalty-free standard for cross-platform, parallel programming of diverse processors found in personal computers, servers, mobile devices and embedded platforms.

• OpenGL - The most widely adopted 2D and 3D graphics API in the industry, bringing thousands of applications to a wide variety of computer platforms.

• OpenGL ES - A royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems - including consoles, phones, appliances and vehicles.

• Vulkan - A new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms.

• GLFW - Create multiple windows, handle user input (keyboard, mouse, gaming peripherals) and manage contexts. Also features multi-monitor support, clipboard access, file drag-n-drop, and much more.

• JAWT - The AWT native interface.

• LibOVR - The API of the Oculus SDK.

• nfd - A tiny, neat C library that portably invokes native file open and save dialogs.

• OpenAL - A cross-platform 3D audio API appropriate for use with gaming applications and many other types of audio applications.
  OpenAL Soft An LGPL-licensed, cross-platform, software implementation of the OpenAL 3D audio API.

• NanoVG - A small antialiased vector graphics rendering library for OpenGL.

• par_shapes - Generate parametric surfaces and other simple shapes.

• stb - single-file public domain libraries for C/C++

• stb_easy_font - Quick-and-dirty easy-to-deploy bitmap font for printing frame rate, etc.

• stb_image - Image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC

• stb_image_resize - Resize images larger/smaller with good quality.

• stb_image_write - Image writing to disk: PNG, TGA, BMP

• stb_perlin - Revised Perlin noise (3D input, 1D output).

• stb_rect_pack - Simple 2D rectangle packer with decent quality.

• stb_truetype - Parse, decode, and rasterize characters from truetype fonts.

• stb_vorbis Decode ogg vorbis files from file/memory to float/16-bit signed output.

• dyncall - Encapsulates architecture-, OS- and compiler-specific function call semantics in a virtual bind argument parameters from left to right and then call interface allowing programmers to call C functions in a completely dynamic manner.

• jemalloc - A general purpose malloc implementation that emphasizes fragmentation avoidance and scalable concurrency support.

• xxHash - An Extremely fast Hash algorithm, running at RAM speed limits.

A full change log since the LWJGL 3 beta can be found here.

Visit the download page to get LWJGL 3.0.0. You can also grab it from Maven Central or this direct link.

In time for the LWJGL3 release, version 1.8.0 of JOML (Java OpenGL Math Library) has been released.

There have been a lot of improvements since we last covered it in a previous blog post here.

Check out the change log and grab it here

I recently came across a really well written and free guide/book for using LWJGL 3 titled 3D Game Development with LWJGL 3. It's a good read, especially for new users who want to get up to speed quickly.

It covers a number of topics including:

1 First steps
2 The Game Loop
3 A brief about coordinates
4 Rendering
5 More on Rendering
6 Transformations
7 Textures
8 Camera
9 Loading more complex models
10 Let there be light
11 Let there be even more light
12 HUD
13 Sky Box and some optimizations
14 Height Maps
15 Terrain Collisions
16 Fog
17 Normal Mapping
18 Shadows
19 Animations

The book can be found here.

It can be read online or downloaded in one of the several available formats (.pdf, .epub, .mobi).

A common question being asked by many people who are moving from LWJGL2 to LWJGL3 is what they should use as a math library for their project as the old lwjgl_util.jar is no longer part of LWJGL3.

A rather good solution is the Java OpenGL Math Library (aka JOML). Its small, fast, supports NIO buffers (compatible with how LWJGL handles buffer arguments), multi-threading and is allocation free (i.e. will not allocate any memory unless specifically requested to do so).

It can be found at https://github.com/JOML-CI/JOML

The latest release can be downloaded from here

The LWJGL native libraries for Windows and Linux are now compressed using UPX, making the binary distributable about 2 MB (or 33%) smaller.

The LWJGL 3.0.0a release has been updated with the compressed binaries. In the near future, we will also provide separate downloads for binaries, source and documentation.

The LWJGL team is proud to announce the first official release of LWJGL 3!

Many thanks to all the enthusiastic LWJGL users that have been trying the nightly builds since last November, it helped us immensely with improving the quality of the library. Keep the feedback coming!

The 3.0.0a release includes the following changes:

• Updated GLFW to 3.1.1
• Updated OpenAL Soft with the latest changes
• Added Objective-C Runtime bindings
  Used together with the LibFFI bindings, the Objective-C Runtime enables you to interface JVM applications with Cocoa APIs on Mac OS X.
• Added LibOVR bindings
  Got a Rift? Download the Oculus VR SDK, build LWJGL on your favorite platform and you're ready to design wonderful virtual reality experiences!
• Restored type postfixes in Java method names, so that they always match with the corresponding native function. This change breaks compatibility with LWJGL 2 in several places, but it's trivial to fix existing code. See this thread for details.
• Cleaned-up the build scripts and made them more robust. Also, the included IntelliJ project now works almost out of the box, with minimal configuration. If you're looking to contribute to LWJGL, it should now be painless.
• Added support for modules. All bindings that LWJGL supports can now be conditionally included or excluded during the build process. If you have a need for lighter binaries, it's now very easy to deploy a customized build.
  This feature also allows us to support as many bindings as we like, assuming at least some users find them useful, without worrying about the distribution size of the official release.
• Native binaries for all OSes and architectures now live in the same directory. The previous structure, with different subdirectories for each OS/arch, was causing trouble with popular application launchers and tools that create/extract JARs.
• Added new demos and tests. If you can build LWJGL locally, make sure to run the fantastic ray tracing demos contributed by Kai Burjack!
• Many bug fixes and API improvements of course!

So, what's coming next?

• Support for Gradle and deployment to Maven Central.
  Ant is showing its age and we need something modern and more easily maintainable. Depending on how this goes, we'll probably drop Ant support at some point.
• Mantle bindings
  Everyone is excited about Vulkan, but it will be a while before the specification is released and stable drivers are available. AMD's Mantle is the API that Vulkan was based on and you can use it right now to start designing a next-generation rendering application. Obviously it will be an optional module, since it's Windows-only and requires GCN hardware.

After that we'll get:

• Support for all (still relevant) OpenGL extensions. If you have time to contribute, this is what we need more help with.
• EGL and OpenGL|ES bindings

Around that time we should do a beta release. Moving on:

• Vulkan bindings, when the spec is released. You can't wait, we know!
• D3D 12 bindings. Hey, why not, we have modules now. :)
• Video decoding bindings.
  We promised that before, but it has been postponed due to technical difficulties. We're still discussing what the best approach should be, if you have any input please post a topic on the forum.
• Font rendering functionality.
  This is another very commonly requested feature and we really want to avoid any AWT dependencies. There are several options here as well, so feel free to offer suggestions.

Enjoy the first LWJGL 3 release!

The LWJGL team is proud to present the latest and final release of the now legacy LWJGL 2 series.

Full details and changelog for the release can be found here (LWJGL 2.9.2).
Update Jan 19, 2015: There has been another bugfix release. Details here (LWJGL 2.9.3).

Pull requests that are well-written and properly tested will still be accepted and the nightly build server will continue to run for the time being.

If anyone is interested in taking over maintenance of the LWJGL 2 project, they should contact spasi via PM on the forums.

Many thanks to everyone that has contributed to LWJGL over the years!

From hereon the focus will be on LWJGL 3+.

An excellent first part article/tutorial of a series on 'Ray tracing with OpenGL Compute Shaders' by Kai Burjack.

Its pretty rare to find good tutorials covering such topics especially using modern OpenGL techniques.

By the end of the tutorial series its expected that you'll be able to produce cool results like the following image:

Read the full article/tutorial on the LWJGL3 wiki here

LWJGL uses the OpenAL-Soft library for its OpenAL support.

One of the MESA developers, Timothy Arceri, while profiling OpenArena noticed that about 14% of the CPU usage was being used for processing sound. After looking into the situation he implemented SSE2 and SSE4.1 linear resamplers in OpenAL-Soft which in some cases have halved its CPU usage (or made it twice as fast).

The optimisation was included in the 1.16 release of OpenAL-Soft and as a result is passed onto LWJGL users.

Gotta love open source development.

The full details of the change can be read on Timothy's blog here

Nov 08, 2014 was a huge milestone for LWJGL 3. It was the first time anyone could download a nightly build of the library and start playing with it. A few days later the new site was deployed and suddenly there was so much interest for the project. Not that surprising I guess, LWJGL is used extensively and everyone's been waiting for a better version, but it did come as a shock after two years of silently working towards the next big release. Yes, it's been almost two years, our first LWJGL 3 commit was on Dec 23, 2012!

Initial feedback has been surprisingly positive. Seems everyone's favorite feature is the GLFW bindings and I'd like to take the opportunity to publicly thank Camilla Berglund (aka elmindreda) for the fantastic job she's doing with the project. It's really been wonderful to finally be able to rely on a well-designed and well-implemented windowing system.

The site seems to also have left a positive impression, though it's light on content at the moment. As we get closer to an official release, more information will be added and we hope that we'll also be able to feature the first projects that use LWJGL 3!

The community excitement did also result in a flurry of activity inside the project. Issues had to be fixed, design choices and technical problems explained, new usability features implemented. Change log for the past week or so:

• Bug fixes, lots of them! The library was suddenly exposed to a wide variety of hardware and operating systems, so some friction was expected. That's what nightly builds are for. :)
• The minimum required Java version is now 6 (down from 7). Java 7 was only a minor convenience and was painless to drop. In return, we made deployment of applications that use LWJGL a lot easier for some of our users.
• Resolved #17, which was affecting a lot of users.
• Re-implemented native library loading, so that using LWJGL 3 is as simple as LWJGL 2. Both -Djava.library.path and -Dorg.lwjgl.librarypath are now supported and users do not have to specify a specific OS and architecture anymore.
• Added new OpenAL extensions and refactored the API to allow for thread-local OpenAL contexts.
• Made building LWJGL locally less painful. JAVA6_HOME is now optional, added a release Ant target and an override for where the generated files are stored.

The greatest news though was that we already have an offer for a contribution to LWJGL 3, bindings to a new API! Stay tuned!

It's finally here! LWJGL 3 has a new, modern home, an updated forum, nightly build infrastructure and... a blog! This will be a fun new way to stay up-to-date with LWJGL and the latest developments in the world of Java gaming and computing. Don't forget to subscribe to the RSS feed!

It's been a long time since the decision was made to completely rewrite LWJGL, something that very often results in doomed projects. But we're still here and now getting close to the very first official release! This release will have alpha status, but the most important functionality is already in place. For the beta, we want to have feature parity with LWJGL 2, which at the time of writing this means adding support for OpenGL|ES (and EGL of course), as well some of the most popular vendor-specific OpenGL extensions currently missing.

With that said, feel free to download a nightly build and do some testing, or even start porting your applications. We're very confident that you'll love the new feel and power of LWJGL 3, the robust new windowing system and, our favorite feature, the amazing productivity boost from the built-in documentation! Initial feedback has been extremely positive and quite a few developers are using it already!

We also have a new logo, that symbolizes the project's fresh start. We wanted a modern, yet familiar design, something that stays close in concept to the legacy logo. So, here it is:

Love it? Hate it? Let us know on the forum!

The roadmap ahead is pretty straightforward. But like all open source projects, the bottleneck is the availability of contributors, their day jobs and other obligations, that keep the project from getting there sooner, rather than later. If you'd like to help, the codebase is mature enough and you can jump right in. Go through the wiki and don't hesitate to ask for help. We'd love to receive a contribution from you!

Until next time!