Frequently an extension will accept not only the tokens it defines, but also many other GL_ constants from either the core or another extension, as a parameter to a certain function. How do you organize the extension classes in this case?
The "contract" is simple; Any constant/function that appears in the New Tokens/New Procedures and Functions of a given extension, will be present in the corresponding LWJGL class. For extensions that use constants (or even functions) of other extensions, a user is responsible for reading the extension spec and knowing which other extensions are involved (and use them accordingly).
As one example, I see you've cleverly made e.g. ARBVertexBufferObject and ARBPixelBufferObject extend ARBBufferObject; do you have other examples of this?
Yes, this is (almost) an exception to the above rule, to avoid code duplication and it's more natural too. Other examples:
- ARBProgram => ARBVertexProgram, ARBFragmentProgram
- NVProgram => NVVertexProgram, NVFragmentProgram
Is all of the LWJGL OpenGL interface code handwritten, or do you have any tools that help automate the process?
Java-side, yes it is. For C code, we once had a nice tool that auto-generated the functions (signature only, with parameter names, plus some special support for Buffer parameters). After several revisions and changes to how the extensions are initialised, it is so straightforward now that we just do it by hand.