Future of JOGL, LWJGL ?

[adamp]

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.

[Herkules]

Isn't that more about ME?

[cfmdobbie]

Pah, it's all you, you, you...

Games published by our own members! Check 'em out!

[Herkules]

LOL - many traps in that language for non-natives....

Micro Edition

[cfmdobbie]

Sorry, couldn't resist!

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"!
  

[cfmdobbie]

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

[Jeff]

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

[shadejmg]

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 )

[Herkules]

Pesonally i think this is an exciting time to be a java programmer.

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....

[Markus_Persson]

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.

Games published by our own members! Check 'em out!

[Zynaps]

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.

Now that's good to hear, uhm, read.

[gregorypierce]

Because you never know what's next?

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.

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....

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.

[princec]

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

[gregorypierce]

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

[djp]

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

[Markus_Persson]

djp: I hope you intend to expose swapbuffers.

[princec]

Hey djp, I think it's about time I was involved in the expert group. Would you drop me a line?

Cas

[swpalmer]

Our intention is to have the expert group start with jogl bindings and go from there.

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.

[djp]

My concern is that JOGL will be used as the basis of a closed API and then the community will be split.

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

[swpalmer]

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.

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.

[ChrisM]

Hey djp, I think it's about time I was involved in the expert group. Would you drop me a line?

Cas

Cas,

There is no "expert group" ala the JCP for JOGL because it is open source.  Anyone who wants to contribute to the code can.  In essence, this community is the expert group

-SG

[Athomas Goldberg]

Cas,
There is no "expert group" ala the JCP for JOGL because it is open source.  Anyone who wants to contribute to the code can.  In essence, this community is the expert group
-SG

Just to clarify, when the JSR around OpenGL is initiated there will be an "Expert Group" at which point Cas's request will become more relevant.

In the meantime, the more feedback that goes toward making jogl *the* basis for a reference implementation of the JSR the more likely the results of the JSR will reflect the interests of the community. That doesn't mean things won't change as a result of the JCP, but ideally those changes won't be complete departure from what we've done so far.

[Athomas Goldberg]

I don't want to get ahead of myself, but as of JavaOne 2002, the JCP permits OpenSource reference implementations of JSRs, so presumably this would apply to JOGL and whatever official Java Bindings for OpenGL JSR is initiated. It's conceivable that the two will ultimately become one and the same thing, with the Project Owners on JOGL becoming part of the JSR Expert Group and vice-versa. I'm not saying this is how it will turn out, but the JCP structure would certainly permit it.

[swpalmer]

as of JavaOne 2002, the JCP permits OpenSource reference implementations of JSRs, so presumably this would apply to JOGL and whatever official Java Bindings for OpenGL JSR is initiated. It's conceivable that the two will ultimately become one and the same thing, with the Project Owners on JOGL becoming part of the JSR Expert Group and vice-versa. I'm not saying this is how it will turn out, but the JCP structure would certainly permit it.

The problem being that the JCP process may lock out most of the community during the important phases.  The community will only be able to comment during the public review period.  I guess it is up to the expert group to decide how public they want to be with their discussions though.  Let's hope this goes smoothly.

Overall I think this interest in OpenGL that Sun is showing is a good thing.

[gregorypierce]

That's really the problem I have with the JCP... everything is just too damn private. A lot of effort that went into LWJGL could had a shared burdon had people known what JSR-134 was going to be for example. Not that LWJGL wouldn't exist (because that's just not the case), but JOGL could have definitely benefitted from more input from the LWJGL folks.

[Athomas Goldberg]

I've got to check on the particulars, but I believe one of the big announcements regarding the JCP at this JavaOne was the provision in JCP 2.6 (JSR-215) http://jcp.org/en/jsr/detail?id=215 that allows for Expert Group "observers" (non-voting members of the expert group who have access to non-public drafts in order to provide feedback). This is designed to enable a larger group of developers to provide feedback, without overly ecumbering the voting process.

JSR 215 also changes the Community Review (currently open only to JCP members) to Early Draft Review making it open to the public. Once again this is intended to allow for earlier feedback from a broader cross-section of users.

JSR-215 is supposed to be finalized in November, so hopefully if and when the OpenGL JSR happens it will be under the new JCP.

[djp]

I am looking into ways to address this.  I don't want the EG to go off for a while and come back with a spec that "shocks and awes" the community (I have been trying for months to get that expression into something ).  Depending on the timing JSR-215 might not be out yet.  If that is the case maybe an extended public review period would work.

Ideally what I would like is to update jogl as the spec changes - makeing it the active reference implementation.  But I don't know about a few things:
1) Is that legal under the JCP?
2) Would the ecommunity want to be dealing with a changing API?

Also, note that the rules of governance are up - which we intend to strictly follow for the games-core projects.  Please feel free to state your case for API additon/subtractions/changes and described in the policies.

d

[Mithrandir]

 1) Is that legal under the JCP?

I believe so. Take the Tomcat/Jakarta project as examples of this same thing happening.

2) Would the ecommunity want to be dealing with a changing API?

No doubt. They're used to open source development, which tends to change API definitions on a fairly rapid basis while in the middle of development coming up to a stable version.


One thing to note about the JSR process is that there will be a heavy push from a number of players to be independent of AWT, which may prevent JOGL from being used - or maybe heavily modified. The independence is so that OpenGL ES can also be included as a implementation. The OGLES spec has been formulated as a set of extensions and subtractions to the core OpenGL spec, so it should be possible with the right API design to include both. Since OGLES is targeted at mobile devices, hence J2ME, AWT dependence would be a major sticking factor.

[gregorypierce]

We actually don't have to have such stringent AWT reliance as we currently have. All we need to do is change the way our current factory implementation works such that we specify a renderer:

.createRenderer("AWTWindowedRenderer", etc);
.createRenderer("RootlessRenderer, etc);
.createRenderer("NativeWindowRenderer", etc);
.createFullscreenRenderer("FullScreenRootlessRenderer", etc);

This does a Class.ForName() and gets back something that implements RenderingPlugin. This plugin contains in its core how it renders to a window/screen/etc. At this point the AWT dependency is located in the plugin - not in JOGL and people can create any bizarre renderer they want (like OpenGLES). There is just an interface that all of the rendering plugins have to implement that allows them to be bound to the JOGL framework. Right now the rendering method is too tightly coupled to the core JOGL implementation.

[Athomas Goldberg]

1) Is that legal under the JCP?

As of JavaOne 2002 it is legal to have an open source reference implementation of a JSR, so I'd assume the answer to this is yes.

2) Would the ecommunity want to be dealing with a changing API?

Well it is open source, after all.

It will probably have an effect on the governance of this particular project, in that the EG will probably take on the role of "Project Owner" with the rest of the developers on the project acting as "observers" I'm sure the voting process can still be employed, though developer suggestions and votes will constitute "feedback" and it will be up to the EG to make the final decision.