I also have an idea for a common code simplification, kind of related to the code I've been writing for frustum culling.
I'm thinking that many people may have code to do frustum culling in their applications, and will therefore have code somewhere that looks like this :-
what I'd like to see, and I know this has been touched on before, is code that looks like this instead :-
Now creating a new FloatBuffer inside this call would be expensive (in terms of speed/object creation), but could LWJGL have a private FloatBuffer (initialised internally at application startup) of a big enough size (256?) to accommodate the largest of the different GL_PROJECTION_MATRIX enum values, and automatically wrap up the supplied float and do the necessary rewind() and get() methods.
This could then also lead to a reverting of the decision to drop the v from methods like this that should be called glGetFloatV().
As you'll now be realising I like to keep my OpenGL java code as much like the C code that I've been trying to learn from on the web, and from books.