Hiya,
I’m about to start a new project, but I’m not sure how JSR 231 is going to affect future development. I think I read that there would be some API changes? What is the timeframe for expected release? I’m hesitant to start coding in an API that’s about be deprecated. At the same time, I don’t want to sit on my hands waiting for something.
I just wish Sun would focus on one project and stick with it.
There are some API changes in JSR-231 but for current JOGL applications they are mostly cosmetic. For example, GLDrawable has been replaced by GLAutoDrawable for most current JOGL apps. The timeframe for public review of the APIs is later this fall, but you can check out the current source code by checking out the “JSR-231” branch of the JOGL source tree. You can start developing with the current JOGL now; it will not be difficult to change your application to use the JSR-231 APIs later.
[quote]I just wish Sun would focus on one project and stick with it.
[/quote]
We are sticking with JOGL and adapting it to be more general.
Sorry but I have to ask why; “GLAutoDrawable”?
What does that mean compared to “GLDrawable”?
[quote]We are sticking with JOGL and adapting it to be more general.
[/quote]
I’d also like to know what you mean by this. How is JOGL not already general?
It’s just a binder/wrapper for/over OGL(the C calls aren’t inlined within the JIT are they?), what are you trying to do?
JSR 231 is not “just” the wrapper over the GL API; it also defines in a general way how the wrapper interfaces with AWT.
Cas 
Thanks.
I would love more information about this.
I’m a big fan of JOGL and I try to get as much information about it as possible.
We are trying to get the JSR-231 spec into public review as soon as possible. This will probably mean later this fall. In the meantime, you can feel free to check out the current source code for the reference implementation. It is still undergoing changes but it is fairly close to the structure of the final APIs.
cvs co -r JSR-231 jogl
The javadoc is not yet complete but for example the difference between GLDrawable and GLAutoDrawable is discussed.
I couldn’t hold myself back from looking at the new classes 
I looks very promising, IMHO a clean abstraction of the GLContext was missing for a long time and the ability to call the OpenGL methods outside the GLEventListener (GLAutoDrawable seems to enable that) too.
I certainly wish that the API caters for those
who wanna have complete control over the
threads, rendering and swap buffers.
IMHO the GLDrawable callback has a monolithic
feel to it like so many APIs out there. The GLUT
approach is only good for simple apps/demos.
In a pro app I’d really like to see simple things
like this:
No callbacks please
In other words, as transparent as possible.
I know very well the pitfalls for making it work
with AWT/Swing’s threading model, but that’s
what GLEventListener is for. For people like me who’s
designing complex apps, don’t make me design
for the API because if every API that I need to use
is so monolithic, it only creates a lot of pain.
Right now I have a custom version of GLCanvas
that lets me do direct rendering without any
interference from AWT/Swing. I wish I can avoid
that.
I wish there was a high-level discussion about
how this can be done, instead of providing
API previews. No articles, no discussion with
users: this is bad.
.rex
The way the Java Community Process typically works is that the expert group formulates a specification which goes through a public review phase and then a reference implementation is developed. JSR-231 is differing from most JSRs (in my opinion) because we are aiming to have the reference implementation done by the public review phase. I believe this is important because otherwise we may end up with an unimplementable specification. In building the initial prototype of the RI I’ve already come across a few core API changes that were necessary to make the spec implementable.
In the expert group we have already addressed issues like the callback mechanism; rather than forcing users to use it, it is built using lower-level, public APIs. The GLCanvas and GLJPanel still support it, but it is no longer the only way of interacting with the library. Further, it is possible for users to portably build their own GL widgets that don’t support the callback mechanism. I disagree with your statement that the callback approach is only good for simple applications. In my experience, it is the best way to abstract away issues of multithreading and asynchronous widget creation/destruction which is a consequence both of the multithreading of the AWT and also of using an object-oriented widget library.
I would encourage you to check out the JSR-231 sources in the JOGL source tree. We went to great lengths to ensure that the RI would be covered under the BSD license and be developed in the open so your early comments on the new APIs would be appreciated.
Rex, if you want that, then you want LWJGL. There’s no reason to be forced to use the JSR231 implementation. JSR231 is aimed at a wider audience with diverse applications and design requirements. LWJGL is more focused on the kinds of stuff you want to do.
Cas
If you have any mixing of AWT/Swing and OpenGL in your application I would strongly recommend you look at the JSR-231 RI-in-progress. From what I’ve seen on the message boards, JOGL’s and the 231 RI’s GLCanvas is more robust than LWJGL’s AWTGLCanvas (especially when removing and re-adding the canvas to the hierarchy), and unless you’re doing full-screen applications then LWJGL’s full-screen Display is not what you need.
(Hm, if there’s any problem about removing and re-adding AWTGLCanvases in LWJGL to the hierarchy we need to know about it…)
Cas