I see alot of people abstracting away from the rendering platform, avoid dependancy on any sort…
Hmmm, Java3D, Hmmmm Xith3D…
Kev
This merely shifts the “problem” onto a different API. If I had a quid for every person who’s told me to “just write a wrapper layer so you can have a DirectX version too”… these people just have no idea.
Cas 
dude its cool 8)
its like having Java and JavaME - now theres a real cool JavaOpenGL and a JavaOpenES, its not going to be the same anyways. its all good news for Java.
top result mate i say!
Cas,
Don’t get me wrong, I don’t mean a standard “API”, I mean writing your own abstraction. It comes down to control I suppose.
Kev
I see larger studios looking at the commercially supported variant… sad but true. My pet project already has support for OpenGL ES and another API that has yet to be announced - something that having another layer around the renderer help attain in a couple of hours
Fortunately we have no commercial interests, only ethical ones
Cas
Those damn customers 
I’ve just gotten hold of the OpenGL ES specs and header files… I wonder what I can do with it in my spare time.
Cas
Sorry on the slow response times. Lots of things happening here at Siggraph.
Yes, the OpenGL ES spec is now release. There is an adopters agreement in the works for those that wish to nominate that they conform to the spec (compatibility test kit, sample implementation source etc). That will retail at about US$1K (at least that is what they said at the BoF yesterday). Obviously, that’s pretty useless for those of us in Java land, but there is high expectation of formal Java bindings coming out soon too (either directly from the above JSR or as a side project). Note, however, that SGI stated flat out yesterday at the BoF that you must respect the logo and trademark issues. You can’t call your implementation “OpenGL” or “OpenGL ES” without having gone through the conformance testing.
Now, for what’s happening with the JSR… From what I can find out, Doug Twilleager is the spec lead, and the rest is up for grabs. One part of Sun wants to offer the JOGL work as the reference implementation for the spec work, but there are other parts of Sun, and a number of other companies that don’t. As a simple rule, assume that the formal package name will not be net.java.jogl. It will either be org.opengl.foo or something in the javax line - like javax.media.opengl. So, even if the API calls remain exactly the same, you will need at least two different sets of code if you are to support both JOGL and whatever comes out o f the JSR process.
Personally, I’ve been chatting with the Sun people and telling them what a screwup of their marketing they’ve been doing. With any luck, they’ll listen. I’ve already pointed them to these threads here about the confusion going on amongst the various communities.
More to come as I work my way through Siggraph…