Hello!
I’ve just read that Sun and SGI are going to develop a binding for OpenGL. You can read it here:
http://www.sgi.com/newsroom/press_releases/2003/july/sgisun_opengl.html
What do you think… will this make LWJGL and JOGL unnecessary?
Has someone more informations? When will there be the first official binding for OpenGL?
Greetings, Adam.
Isn’t that more about ME?
Pah, it’s all you, you, you… 
LOL - many traps in that language for non-natives…
Micro Edition
Sorry, couldn’t resist! ;D
But to the original poster: yep, it’s been posted a couple of times in the last day or so, and there’s some discussion of it in other threads.
As to your questions:
[]I personally think it can only be a good thing.
[]LWJGL and JoGL are different APIs with different approaches, both from each other and from this new one. They will all continue to be necessary.
[]No more info as of yet, except for what people have posted elsewhere.
[]Heh - define “official”! 
Incidentally, here’re the other posts:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=News;action=display;num=1059407903
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=News;action=display;num=1059407116
And here’s where it’s being discussed:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1059397227
I know its confusing, but this is all part of the same efforts that the same people are doing in Sun who are working on JOGL.
So relax, its not a competing project.
JK
what we are basically seeing is sun finally taking the gaming industry seriously… the cell phone gaming phenomion has taken off… and one of two things can happen next… it will fizzle out… or with a little help it can become a thriving industry.
To full fill its potential ( cell phone gamming ) sun has decided to try to bring opengl to the cell phone. Great idea… but wait… what about the desktop… so in a seperate effort jogl has been created… jlwgl was a seperate effort all together to meet this same need for the desktop… its methodologies are slightly different and hence there are really two camps of java desktop gamming programmers now. both libraries have their good and bad points. And i dont see either one of them goinging away any time soon.
Pesonally i think this is an exciting time to be a java programmer. Ive been a lead programmer for the last 4 years ( in java ) and the potential for new programs to be created ( that use opengl ) are amazing. … And lets not forget the chance to show every C++ programmer that ever snuffed java that not only can we do what they do in games… but we might even be able to do somethings better.!
JMG/Shadowlight/Shadejmg
(i have too many names )
[quote]Pesonally i think this is an exciting time to be a java programmer.
[/quote]
Because you never know what’s next?
You developed for Java3D and now throw it away?
You turned to LWJGL and now throw it away?
You turn towards JOGL and now feel insecure bc. Sun announces different things the same time?
You developed technology and throw it away bc. Sun suddenly comes around the corner with the same stuff?
Exciting, yes, somehow…
Switching between different OpenGL bindings don’t excactly require massive code rewrites, so I’m not so worried about that.
And Java3D was pure moosedroppings for games in the first place. Sure, it was an intresting prototype / proof of concept API, but adding OpenGL support to Java is such an obvious and perfect solution that it really leaves no place for a pure high-level API like Java3D.
The scenegraph part will probably live on either as a Sun effort, or (even better, imo) as something like Xith3d, but the immediate mode serves no purpose whatsoever at this point.
[quote]I know its confusing, but this is all part of the same efforts that the same people are doing in Sun who are working on JOGL.
[/quote]
Now that’s good to hear, uhm, read.
If you’re letting someone else dictate you needs - you’ll always be in this boat regardless of what technology you’re using unless that technology simply isn’t advancing any more.
Then you should be asking yourself a question - why am I throwing technology away. Java3D - sure, you don’t really have a choice if you coded directly to the API as Java3D is closed. However there is absolutely nothing stopping you from sitting a Java3D API on TOP of JOGL, LWJGL, etc. This is basically what Xith3D is. Design by contract, interfaces, and loose API bindings with higher level APIs. As someone who’se been developing software professionally for over 15 years I can tell you this - if you’re chasing the latest hot technology, you’re making a mistake. If you’re coding to the latest hot technology, you’re making a mistake. if you’re throwing away good code because you want to be in with the latest hot technology, you’re making a mistake.
Not to bad-mouth LWJGL, but if you take a look at applications that coded directly to the API - those applications had to be rewritten for 0.5, 0.6, and then again for 0.7. When I did a rewrite of my scenegraph and rendering code for 0.5->0.6 I saw the writing on the way and simply wrapped LWJGL with a higher level API and made LWJGL a service provider (like Xith3D) and when I decided to move to my own custom binding it took me 2 days of effort. When I saw JOGL and decided that I could add it as a service provider for non mobile devices, that took me 8 hours of effort.
my point? Don’t assume that the technology underneath you won’t/can’t change - because it will. It always has, and if man keeps progressing it will continue to do so. Somewhere out there exists an API that will do even cooler things. I’ve set myself up so that it shouldn’t take me more than 48 hours (weekend) to move this tech to any API I desire for whatever reasons may be necessary. Took a lot of work up front, but the flexibillity it has afforded me has already paid for itself.
Having said that, when we reach 1.0 for LWJGL we will freeze the API, and all future releases of 1.x will operate exactly as 1.0 does except for bugfixes and entirely new features. The main reason we change so much is because we’re very responsive
Cas
Well I don’t think you’re going to be any less responsive once 1.0 is released. Its certainly an advantage to be able to change the API to fix bugs and remove cruft or dead/useless features from an API. I wish the java SDKs changed did the same sometimes. Doesn’t require much to wrap a vertex buffer as a shape and change the underlying shape rendering code to match whatever API you happen to be on
Just to emphasize what Jeff said. The Java bindings for OpenGL is being driven by the Games Technologies Group at Sun. Our intention is to have the expert group start with jogl bindings and go from there.
As far as Java 3D, we are still looking at options.
As for the Java 3D team members that have lost their jobs, they are all good engineers and I would recommend them to anyone who is hiring out there. If anyone has any leads let them know or me and I will forward whatever I get to them.
d
djp: I hope you intend to expose swapbuffers.
Hey djp, I think it’s about time I was involved in the expert group. Would you drop me a line?
Cas
[quote]Our intention is to have the expert group start with jogl bindings and go from there.
[/quote]
My concern is that JOGL will be used as the basis of a closed API and then the community will be split. If OpenGL bindings are included in the core (great!), then we have to make sure that the open source JOGL can remain as an ‘endorsed standard’ that can override the bindings in the core… (I think something similar is done for XML?)
That way the faster moving open source version can be used when needed.
Not sure what you mean about a “closed API”. If someone wants to develop their own version of the binding there will be a TCK available for certifcation.
The Java bindings project is not just a write once and then you’re done project. As the OpenGL API evolves the bindings will too.
d
[quote]The Java bindings project is not just a write once and then you’re done project. As the OpenGL API evolves the bindings will too.
[/quote]
That’s what I mean. If JOGL is adopted as a Sun standard extension or part of the JRE core then at least that distribution of it will change slowly compared to the open source JOGL.
If the paths diverge (one interpretation of “start with JOGL and go from there”) then developers have to make some hard choices. Use the bindings in the JRE, or JOGL. If JOGL is installed such that it replaces the JRE bindings (endorsed standard?) then doing so might break something that expects the original Sun provided bindings.