I count at least 3:
[]JOGL
[]Java2D OGL-pipeline for Tiger
[*]OGL rendering layer for Java3D
Sounds like overkill. Wouldn’t it be cool to use JOGL for Java2D and put Java3D on top of Java2D/AWT?
Java3Ds Canvas3D could then be a lightweight component again and overlay system would be just a snap.
Just a dream…
I mentioned something like this to Chris Campbell a while ago… I said, why not just use LWJGL while you’re implementing the OpenGL 2D pipeline; that way it’s all in pure Java and easy to tweak. But for reasons unknown nobody was interested.
Also for reasons unknown JOGL continues to soldier onwards in the wrong direction duplicating the efforts of the LWJGL. Listen up, chaps! We’ve already done all the binding work! No need to do it again!
Cas 
[quote]Sounds like overkill.
[/quote]
Sometimes I don’t understand Sun’s decisions… There are other strange things like this in all the Java library…
Chman
Probably because OpenGL is not 100% available on all the platforms that Java is available for.
So, for example, Java3D has bindings to both DX and OpenGL to provide a layer of abstraction.
This probably won’t change until/unless OpenGL becomes available everywhere. It’s getting there, but certainly was not as far along when J3D (for example) was designed.
Also, each of the bindings is intended for a different type of usage and different audience. For example, jogl doesn’t support VR caves or VR goggles (does it?) while Java3D does. Jogl is low-level and high-performance, while Java3D is high-level and low(er) performance.
Not everybody is writing games using those tools.
Could it be all redesigned from scratch now that the landscape has changed? Probably. Is it worth it to Sun? Probably not.
[quote]Probably because OpenGL is not 100% available on all the platforms that Java is available for.
So, for example, Java3D has bindings to both DX and OpenGL to provide a layer of abstraction.
[/quote]
Thats a lousy excuse. You implement an OpenGL binding and a DX binding, then do your renderer abstraction in Java. Xith3D does that, 'cept it uses LWJGL and Jogl.
[quote]Also, each of the bindings is intended for a different type of usage and different audience. For example, jogl doesn’t support VR caves or VR goggles (does it?) while Java3D does. Jogl is low-level and high-performance, while Java3D is high-level and low(er) performance.
[/quote]
Thats the difference between direct bindings and using a scene graph, and a totally separate issue.
… and JInput is supposed to do that kind of thing too.
Cas
There’s a big difference in how it is done though. Java3D does the abstraction at the native code level, where Xith3D does it in the Java level. Java3D tries to gain extra performance by reducing to a minimum the cross-JNI calls in bundling everything up on the Java side and then making just a few calls through JNI. Xith3D, OTOH, makes all the OpenGL calls on the Java side, thus having a far higher number of cross-JNI calls to the immediate mode rendering layer.
[quote]Probably because OpenGL is not 100% available on all the platforms that Java is available for.
So, for example, Java3D has bindings to both DX and OpenGL to provide a layer of abstraction.
[/quote]
Yes and no. The reason for the DX layer was that a lot of the Win32 systems had OpenGL, but only a software implementation with no hardware impl. Originally J3D was only OpenGL and it wasn’t until 1.2 that a formalised DX renderer was added.
These days, most video hardware has good quality OGL drivers, on par with thier DX drivers in the Win32 space. In fact, it has reached the point where a lot of cards have better OGL drivers than DX (particularly high-end cards like 3DLabs and nVidia CAD cards). Thus, it becomes worthwhile implementing 2D systems with OpenGL as that is the most common cross-platform API.
[quote]I count at least 3:
[]JOGL
[]Java2D OGL-pipeline for Tiger
[*]OGL rendering layer for Java3D
Sounds like overkill. Wouldn’t it be cool to use JOGL for Java2D and put Java3D on top of Java2D/AWT?
[/quote]
Mostly politics is involved in this. Note that the JOGL stuff didn’t happen years earlier because of a lot of politics between Sun and SGI over the use of the OpenGL trademarks and interactions with the ARB. However, it was completely acceptable to be a “user” of OpenGL under the covers for implementing their rendering APIs but not OK to call themselves “formal Java bindings to the OpenGL spec”.
Completely rewriting something like Java2D from scratch would take massive amounts of work to do. That woiuld have started at least 2 years ago, well before the current JOGL work and JSRs started to happen. That’s why you get the current dichotomy. I doubt you’ll see J3D move to using JOGL as it wants to retain it’s cross-API implementation internally, so the only thing that remains is to see whether the link between JOGL and Java2D internals can be made cleanly. That’s really an implementation issue for the people shipping JOGL, not for high-level land like the JSR expert group.