Possibility to make bindings mockable in LWJGL N (4?)

[xxDark]

Question

This is not a question about current major version of LWJGL, but rather a future version (4 or perhaps later?..)
Would it be possible to make bindings a non-utility classes?
For example:

public interface Binding<C, T> {

	T create(C context);
}

public interface GL11 {
	
	void glLoadIdentity();
	
	void glPushMatrix();
	
	void glPopMatrix();
	
	...
}

Binding<GlContext, GL11> GL11 = GL11C::new;
Binding<GlContext, GL$N> GL$N = GL${N}C::new;

Java provides a way to import static fields, so the old "singleton" style could still be used for developers who don't want to maintain the binding instance or they are sure that it is safe to store it in a static final field.
This:

• Eliminates LWJGL-specific thread local variable stored in JNIEnv function table;
• Allows developers to implement a layer on top of GL${N}C (or any binding in general);
• LWJGL can utilize this style of the API to generate implementation of bindings with unsupported methods stubbed, instead of doing this.

HotSpot is good at inlining virtual calls, thanks to type profiling, but the approach to structuring the API this way should of course be measured.

[Spasi]

Hey @xxDark,

I don't know about the Binding interface, but yes, the current FFM-based binding generation prototype produces instances (implementations of bindings specified as interfaces), i.e. a non-static API. This is very much a work-in-progress, but you can see some examples in the ffm branch:

https://github.com/LWJGL/lwjgl3/blob/ffm/modules/samples/src/test/java22/org/lwjgl/demo/glfw/CustomBindings.java
https://github.com/LWJGL/lwjgl3/blob/ffm/modules/samples/src/test/java22/org/lwjgl/demo/system/windows/CustomKernel32.java

With this approach, a library like GLFW would still be exposed as a static API (the actual generated instance will be encapsulated internally). However, OpenGL(ES) bindings will become instance-based (gl.Clear(...) or ctx.glClear(...) instead of glClear(...)) and that instance will implicitly carry what is GLCapabilities now and will solve all the issues you mention above. A static GL(ES) API may also be available to simplify migration from lwjgl3, but it will suffer from thread-local lookup overhead on every call.