This can only descend into an OO flame war

I stand by the principle of creating software to do a job well, and our job is to enable people to write AAA games that run on Java runtimes easily. To this end it's a certainty we won't be adding multiple contexts etc.
But it's also particularly true that we are following the path of least resistance. There is nothing non-OO about static methods. Why do they exist in an OO language? Because they have their place. Why is the Math object full of static methods? Etc.
It is my belief that static methods in the various GL classes is perfectly object-orientated, in the sense that the class defines the namespace in which the static methods live. And they are static, believe me - they are a direct wrapper for a C library, and no more. As the C library is not object orientated in any way neither can the Java library be. However, we can make proper use of the facilities that Java gives us to accommodate this - which is static methods.
Before in Java you would use GL.vertex() as your namespace qualifier but many developers rightly think this is a) a waste of typing and b) ugly, which is why static import is coming to 1.5. However this causes a namespace problem with a few of the GL commands. This brings us neatly full circle back to having the gl prefixes on all the commands again, so they can be statically imported from a convenient class and without any namespace collision.
Now, it would be great if we could
efficiently generate a GL instance which implemented only those interfaces the GL context said it could handle... but right now I don't see an efficient way to do this, nor easy.
So for now what we want to do is capture the existing C programmers' expertise, and make it much easier for them to migrate their game writing to Java. A lot of code will be cut 'n' pastable from C, minus the pointers, which need to be declared as buffers.
We strive always to make life easier for the majority, not more full-featured for the few. This is why Java is such a big bloaty complicated beast and why it takes so long to learn how to do anything useful in it. My total failure to make JSP work the other day illustrated this to me once again. I spent half a day trying to make the hiscore table work before I gave up and installed, learned, and wrote a PHP page to do the same trick in under half an hour. The JOGL/JOAL/JINPUT stuff is exactly the same: it's fully-featured, full-fat, full-complexity, and requires J2SE to boot.
If I really had my way I'd have a version of BASIC instead of Java but that's for another project.
It might be productive to list the pros and cons of what we propose to do:
Pros- Easy migration from C and C++
- Simple to understand
- No need to keep instances of GL all over the place
- Extension technique well-understood by existing OpenGL community
- Eases the path of refactoring with JOGL and GL4Java slightly
Cons- Can't do any fancy pipelining stuff
- Breaks all existing code
- Deliberately simplified model may mean that a few applications simply aren't feasible. In particular I hear that people would like to be able to write level editors - but this is probably moot as we don't support multiple windows or AWT anyway
Any more?
Cas
