Request for feedback: Dropping obsolete bindings

[Spasi]

It's been 9 years since the first LWJGL 3 release and it's time for some cleanup. There are two major changes coming in 3.4.0:

Removal of binding documentation.

Quick access to comprehensive documentation directly in the bindings has been one of LWJGL 3’s standout features. However, maintaining this documentation has significantly slowed the development of other valuable LWJGL functionality. To ensure the long-term health and viability of the project, we will remove the embedded documentation so we can concentrate on adding new bindings and working on LWJGL 4.

Removal of obsolete bindings.

Many existing bindings have limited usefulness. To reduce clutter and free up space for future bindings, we plan to remove some of these outdated components. Please review the list below and let us know if you have objections to the removal of specific bindings. Be sure to explain your use-case and provide any arguments in favor of keeping them.

• CUDA (maintenance effort: high)

The CUDA bindings have always been incomplete, only the Runtime API is available. The CUDA ecosystem is huge, with many useful libraries layered on top of the base API, that LWJGL has no bindings for. There are two options, either add those missing bindings to make CUDA actually usable, or remove it completely. We're currently considering the latter because a) there haven't been any requests for more CUDA support and b) most projects utilizing CUDA do so over higher-level C++/Python frameworks and low-level access is interesting to very few users.

• jawt (maintenance effort: low)

Keeping jawt bindings around won't be an issue, it has a small and stable API. However, AWT interop has always been problematic/unstable and we'd like to discourage further attempts. Users that absolutely need jawt could relatively easily create their own bindings using the FFM API in newer JDK versions.

• libdivide (maintenance effort: high)

We are not aware of anyone actually using libdivide. It is also not even an actual native binding, because JNI overhead defeats its purpose. Instead, it has been ported to pure Java, which is kind of out-of-scope for LWJGL. It's too much Java code that must be maintained and performance-tuned (needs intrinsics introduced after JDK 8 for useful performance). Ideally, this would be a separate project that would also make use of the preview Vector API for additional performance.

• LMDB (maintenance effort: low)

It is still useful as an embedded database / mmap-replacement, but we are not aware of anyone actually using it.

• Meow hash (maintenance effort: low)

We are not aware of anyone actually using this and, like libdivide, it would be better to implement this in pure Java with the Vector API.

• nanovg blendish.h/oui.h (maintenance effort: low)

We are not aware of anyone actually using these two libraries based on NanoVG. Note: NanoVG itself is not going away.

• OpenVR (maintenance effort: medium)

OpenXR has made OpenVR obsolete, for the most part. However, there may still be users that need features not exposed by OpenXR yet.

• OVR (maintenance effort: low)

OpenXR has made OVR obsolete.

• SSE (maintenance effort: low)

A bad idea in the first place. Obsolete.

• Tootle (maintenance effort: low)

Anyone using Tootle should probably migrate to meshoptimizer, which is more feature rich and under active development.

• Yoga (maintenance effort: medium)

It is still useful for UI development, but we are not aware of anyone using it.

• Your suggestion here...

Any other binding you think should not be included with LWJGL?

[NekoCaffeine]

Among the listed bindings, I've only utilized libdivide, specifically its Java-side implementation. I'm perfectly comfortable with implementing libdivide independently in my own project.

[Desoroxxx]

By the binding documentation do you mean the javadoc? If so that has been so far very important to me

[Spasi]

I'm afraid so.

[NeusFear]

I had no idea what yoga was until I looked it up after this post, I would be extremely happy to use that for my engines ui framework. I had been doing everything thus far manually, this would make things much easier. I have seen a few posts online of people using it as well for "non-android" projects.

[SWinxy]

lwjgl3-awt uses the JAWT bindings, but that can also be accomplished with libFFI if LWJGL3 drops it or FFM for LWJGL4. libFFI is already used to support macOS without necessitating building a native library. lwjgl3-awt doesn't use the entire API set either—some functions are not used. What would be nice is if we could get a Java API for window handles on top of a C API (JDK-6553366).

[NekoCaffeine]

I believe abandoning documentation maintenance is reasonable.
Outdated documentation is more harmful than none, especially when users can consult the official documentation of the target libraries.
Letting documentation maintenance hinder core feature development would be counterproductive.

[wedesoft]

Is it still possible to keep documentation of the function signatures (method parameters and their types)? I found the OpenGL documentation quite helpful and I imagine Vulkan could be useful in a similar way. Never mind the explanation what each method does. That information can be found elsewhere.

[Spasi]

Hey @wedesoft, yes, that's a good idea. I've already kept the javadoc for struct definitions and callback function signatures, should do the same for downcall signatures.