I was thinking about JOGL

Acutally this apply to LWJGL as well.
Look for example at this code

gl.glClearColor(1.0f, 0.7f, 0.2f, 0.6f);
            gl.glClear(gl.GL_COLOR_BUFFER_BIT | gl.GL_DEPTH_BUFFER_BIT);
            gl.glMatrixMode(gl.GL_PROJECTION);
            gl.glLoadIdentity();
            
            glu.gluPerspective(-50.0f, 1024.0f / 768.0f, 0f, 22.0f);

See? It’s standard JOGL code.
And then look at this

gl.clearColor(1.0f, 0.7f, 0.2f, 0.6f);
            gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);
            gl.matrixMode(gl.PROJECTION);
                        gl.loadIdentity();
            
            glu.perspective(15.0, 1024.0 / 768.0, 0.0, 220.0);
            gl.translatef(c1,c2,c3-20);

This is simple modification that I did. Cute… Isn’t it better? It’s more confy, at least.
I think that gl.PROJECTION is more close to GL_PROJECTION as well.
So I’m thinking, what would happen, if we will shift GL interface in both JOGL and LWJGL towards this direction?

[quote]Acutally this apply to LWJGL as well.
So I’m thinking, what would happen, if we will shift GL interface in both JOGL and LWJGL towards this direction?
[/quote]
You’re not using LWJGL in a static context!
it would look like this:

   glClearColor(1.0f, 0.7f, 0.2f, 0.6f);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();
   
  gluPerspective(-50.0f, 1024.0f / 768.0f, 0f, 22.0f); 

compare this to your existing c code, or tutorials on the net and you will see that they look astoundingly alike!

Have a look at the jogl API feedback requested for JSR 231 thread for a long debate about this topic.

My personal opinion is that lwjgl has got it right.