[EDIT:]
I apologize.
This topic is not helpful at all. I really think its better to delete this, than propably causing flame-wars or whatever. If I would write another topic about JogAmp, LWJGL will not be discussed.
I hope you understand, and I hope this will be deleted soon…
[quote=“matheus23,post:1,topic:39153”]
LWJGL is static-only because it allows you to copy-and-paste sourcecode from C to Java, using static imports. This is very convenient and allows you to keep your code ‘clean’, but not having to pass a ‘gl’ instance around in every remote corner of your app. IMHO this is still the way to go, and is actually how the OpenGL API was designed. Don’t expect to use JOGL and be able to interleave calls to different ‘gl’ instances: you still have to manage contexts yourself. Behind the scenes, JOGL simply makes static (native) calls to OpenGL, just like LWJGL.
[quote=“matheus23,post:1,topic:39153”]
LWJGL was there first, there was nothing to go with.
Indeed, OpenGL is not an object-oriented API. We mapped it directly so you could invent your own object-oriented abstraction for it. However, as this is not how graphics drivers or hardware works, it is probably not so wise to do it. Creates ugly as hell code too.
Cas 
As this thread is likely to spiral out of control, not in the last place due to statements like: “In the end I’d say LWJGL is good for Java-newbes”, I think it’s best to urge everybody to only reply to factual statements, ignoring any strong subjective statements that might be posted. Otherwise this thread will be locked quickly.
I retract my previous statement about code ugliness and leave the aphorism “beauty is in the eye of the beholder”
Cas
Should I maybe leave out the LWJGL vs JogAmp thing?
I apologize. This is a critical point, and everyone should decide that by themselves.
If you really want an OO graphics api, then use JME, or Ardour3d, both of which have both lwjgl and jogl backends.
If you want to code OpenGL, then lwjgl’s static interface is the closest to the original C api as you’ll get. This is good because it means all the documentation and code on the web still applies.
Ah. I see! A new fact learned
I like the static API of LWJGL but sometimes I find it awkward to remember which version of opengl the function was defined in (choosing between GL11, GL15, etc.) while having a GL object allows inheritance to define the different opengl versions (and to remove functionality in the case of moving to Opengl 3+).
One thing that I’ve always been confused about in both JOGL and LWJGL is what happens when an ARB function is invoked. In JOGL, the API doesn’t even expose ARB so I’m assuming that it must do something like GLEW and calls the ARB version if no core function is available. With LWJGL, both the ARB and core functions can be called explicitly in Java but if I call the ARB and the core is available, will it upgrade and call the core function?
LWJGL does nothing but wrap calls.
When you call the ARB version, like glBufferSubDataARB(…), the ARB version is called in OpenGL.
When you call the core version, like glBufferSubData(…), the core version is called in OpenGL.
Worth noting is that there won’t be a difference between them as long as both are supported and the function/constant names are identical (except for the added suffix (ARB, EXT, etc)). Of course it does not make sense to use both the core AND the extension version of a feature. It should be safe to use OpenGL 2 (shaders, multitexturing, VBOs) on 99% of all computers. If you want FBOs, the extension is supported by OpenGL 2 hardware, but it was only promoted to core in OpenGL 3.