http://www.gamedev.net/info/news/FullStory.asp?StoryID=5389
this artice on gamedev.net, are they speaking of JOGL or something else?
Although I slashdot 
I read the article.
What the heck is it? Tell me this is not another seperate effort for OpenGL bindings but that this is a SIGGRAPH annoucement about JOGL…? 
all cool with me… it gets the java opengl out there and thats cool with me :)… more the cooler…
yes, but is it cool?
but it is NOT JOGL we are talking about here…so can anybody tell me what is the idea behind having two identical projects?
Reading the text, the new joint project is aimed at OpenGL ES, isn’t that the mobile based thing?
Kev
could be… but term “mobile terminal” can mean lotta different things
one way or the other it is quite amusing how many API we will have soon … providing they all get finished before we get into something new ;D
Justin Couch just wrote on the Java3D mailing list:
"This has been a very long time in the making. I’ll try to find the other press release. It is now formal that Sun and SGI will be developing formal OpenGL bindings to Java. Note that this is not the JOGL project on
JavaGaming. "
That makes it sound like it’s not just for mobile platforms and is a binding within the core API. Which would then mean, why would you want to use JOGL? What’s going on here? Is there no communication within Sun? Could this mean JOGL is the test bed? This is a little strange I think.
I hope that new api exposes swapBuffers().
It has been my experience that we would not get a fully clear, concise and accurate answer on this type of quesion.
This is a full binding to all of the OpenGL specification, not just OpenGL ES. ES is both a subset of OpenGL 1.3 and additional functionality (eg fixed-point API calls),. The Java bindings for ES will form a part of this binding work.
Because of this dependency, it will not be using JOGL as the base (at least from what my Sun and SGI contacts are telling me - I’m one layer outside of the inner loop). JOGL is heavily dependent on AWT, which makes its usage in a mobile environment very difficult.
Note also that the forces inside Sun that have been pushing this are not the people traditionally associated with 3D graphics inside of Sun and therefore has, mostly nothing to do with the Java Gaming stuff here.
Sun management (no offence to you guys doing a great job on these forums/jogl) never stops amuse me :
A glimpse in to the future:
Soon™ management will probably decide that java3d should be renamed javagl2.0 and launch a private expert group that in the year 2010 presents it’s first draft. Then java programmers interested in writing high performance games will step up and use nio buffers to interact with opengl3.0, whereas another division of Sun starts the JoGL3 open source project etc etc ;D
I’m grumpy that it took Sun and SGI SEVEN years to get with it. I’m pleased that they’ll being using the JCP.
I really hope that this means that JOGL is adopted as the initial implementation and pulled into the JRE core and is always up to date and fully supported… and there isn’t wasted duplicate effort…
But I have a feeling this is going to create a bit of a mess instead :(.
This is strange news…
What do people spending a lot of time and effort into Jogl like Ken and others do have to think…?
I’ll tell you what I think - screw em. Let them go off and BS with yet another binding if they want, don’t really care. When their binding works on all the platforms that JOGL works on and is open source, I’ll consider reading about it
There is no doubt this comes as a shock to me ( usually have better info ;-))
However…
IMHO, this should not matter as far as development goes. More marketing, great. More resourcs, great.
2 OGL APIs, well it can’t be that hard to jump between if one is dumped or whatever happens.
Now if the focus is OpenGL ES, good as well. Many tools ( read graphs and renders ) if written simple and lite will port and can be useful in totally new markets/apps/idea etc.
…hm… what they might end up with here is some kind of bizarre cross between LWJGL and JOGL. We’re going to add support for OpenGL ES as and when it becomes generally available. We’ve got no dependency on AWT; in fact our entire API is designed to run on Palm-sized devices right up to desktop PCs. Sounds familiar?
Look into my crystal ball:
I see a confusion of similar APIs… I see a tall dark stranger saying “Not invented here”… I see left hand and right hand blissfully unaware of each other’s existence… I see the LWJGL getting it right first ;)…
Cas