An alpha JOGL implementation for jME 2.0 has just been added to SVN. Thanks goes to Steve Vaughan for his work in porting the LWJGL implementation.
Please note that this code is still missing a few features such as Pbuffer and Applets. Also I've noticed some bugs still when using shaders. Any assistance in tightening things up would be appreciated.
Nice, thats been a long time coming! Thanks Steve.
What if any would the difference be for the developer. Or are we still do discover them?
Speed benefits and alike?
Thanks for the news btw 
I'm told JOGL will be part of java 6u10, so perhaps reduced distribution size will be a benefit at some point.
Hey, that's cool! Been waiting for this. I guess it's time to clear up my code from crazy LWJGL usage 
I saw the lwjgl x64 thread and jogl thread. So I thought: Is there a (working) jogl x64 version?
Yeah, you might need to download the correct binaries though (release 1.1.1). (see https://jogl.dev.java.net/servlets/ProjectDocumentList?folderID=9260&expandFolder=9260&folderID=0 ) I've only uploaded the windows ones so far… wondering if we should even have jogl binaries since there are so many options there.
I started the JOGL port in order to allow the use of JMonkey’s scene graph with another code-base which used JOGL.
As a future benefit, some of the development in Java Mustang includes JOGL/Java2D interoperability (See http://weblogs.java.net/blog/campbell/archive/2005/09/java2djogl_inte_1.html).
Of course one would ask which is better? JOGL or LWJGL?
following some links (that I've not read yet but that may help):
renanse said:That sounds highly unlikely. Not only would it add a serious dent in the download size - but it hasn't been included in any of the builds yet - and 6u10 is in beta stage.
I'm told JOGL will be part of java 6u10, so perhaps reduced distribution size will be a benefit at some point.
Matzon said:
renanse said:That sounds highly unlikely. Not only would it add a serious dent in the download size - but it hasn't been included in any of the builds yet - and 6u10 is in beta stage.
I'm told JOGL will be part of java 6u10, so perhaps reduced distribution size will be a benefit at some point.
I think it was meant that reduced distribution size would be on our end, meaning you wouldn't have to include it with your game. because they already had it
yes… and thats what I am saying: JOGL in any 1.6.x release is highly unlikely. Furthermore I actually think its unlikely in any Java SE release, simply because of the nature of a java opengl bridge (too much "uncontrolled" native code access).
I would agree with you Matzon. I say "I've been told" though because I've heard from people inside Sun who were excited about us supporting JOGL who have said that this was the case. They are not on the JOGL team, or on a team that would have anything to do with the VM itself I imagine, so I'm sure this is not a set in stone thing. Just seemed more than rumor at that point.
Yup. Though I see the advantages for said OpenGL users (I actually think the main advantage would be the pre-accepted security dialog, and not size), I still think they're a minority compared to the other features that are used in the SE release. So I don't think its a good Idea to add it to the SE (unless they in the future only deliver the Java Kernel downloads).
However, I think that one of the main problems with these OpenGL bindings, is that it is very easy to bring down the VM by an illegal OpenGL command with a wrong buffer. The only way to fix this is to check every GL call that requires a buffer, which would be very bad for performance.
renanse said:
I would agree with you Matzon. I say "I've been told" though because I've heard from people inside Sun who were excited about us supporting JOGL who have said that this was the case. They are not on the JOGL team, or on a team that would have anything to do with the VM itself I imagine, so I'm sure this is not a set in stone thing. Just seemed more than rumor at that point.
Do you still maintain the JOGL port?
Not for jME these days, sorry. It's fairly solid though and in use at at least one company I know of.
SRA is actively developing with the JOGL port on some upcoming products, which was our driver for the original JOGL port contribution. In addition, it looks like Sun's next release of Project Wonderland will be using the JOGL port.
Sure sounds like its worth keeping the JOGL display system also running… I hope gouessej does not think like he is the only person who cares about JOGL
I have a sneaky feeling that if it has not happened yet, at some point JOGL will pass LWJGL in terms of capabilities, simply because there is a larger bunch of ppl working on it and more people testing… am i wrong on this?
The JOGL implementation was a direct port of the LWJGL one for the most part and further changes I made to one I made to the other. Was not that much work to do and hopefully that would be kept up and they would be kept in sync.
Mindgamer said:
Sure sounds like its worth keeping the JOGL display system also running.. I hope gouessej does not think like he is the only person who cares about JOGL :)
I know some other people are interested in using JOGL in JME. I notice that some people tried it in an applet and it crashed. But many people on www.javagaming.org don't understand why I don't want to simply use the LWJGL display system.
Mindgamer said:
I have a sneaky feeling that if it has not happened yet, at some point JOGL will pass LWJGL in terms of capabilities, simply because there is a larger bunch of ppl working on it and more people testing... am i wrong on this?
I don't know but in my humble opinion, JOGL is more reliable than LWJGL, especially under Linux, it is worth using it inside JME.
Finally, count on me. I'm going to use JME for my game TUER, it will NEVER rely on LWJGL, I will do my best to allow JOGL to work fine in JME. I have a very small graphics card then I can detect the part of the code that won't work under OpenGL 1.3, that is what happened with JOGLContextCapabilities.