[quote]Hey djp, I think it’s about time I was involved in the expert group. Would you drop me a line?
Cas 
[/quote]
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
[quote]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
[/quote]
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.
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.
[quote]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.
[/quote]
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.
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.
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.
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:
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
[quote] 1) Is that legal under the JCP?
[/quote]
I believe so. Take the Tomcat/Jakarta project as examples of this same thing happening.
[quote] 2) Would the ecommunity want to be dealing with a changing API?
[/quote]
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.
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.
[quote]1) Is that legal under the JCP?
[/quote]
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.
[quote]2) Would the ecommunity want to be dealing with a changing API?
[/quote]
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.