GL4JAVA VS JOGL

OpenGL Development JOGL Development
#1

Much of the graphics applications are written in OpenGL, opengl have low level API due to which it makes life easier when compared to JAVA3D, Java3D is slow compared to OpenGL.

GL4JAVA is not compatible with latest Mesa 6.0, it will crash if u try to use it, this fellow is sleeping, and gave up as JOGL is picking pace. Some body said that GL4Java has lot of memory leak problems bcos of poor implementation of JNI calls, and it is very difficult to modify if u find a bug. If u got a problem then u are dead as no one will bother to ur question posted in gl4java forum or if u write to the author. gl4java is compatible with JDK1.4 if one day sun comes with JDK 1.5 then u may not find to use gl4java as I am not confident of the author that he will upgrade the codes.

JOGL is quite a good one, good use of patterns, not so complex,u can understand the source code, less memory leak problems, certain care has been taken.
Good forum there are people who are paid to help u out if u got any problem, once u post it on the forum.
SUN is going to maintain it that is a good news.

My experience
We have a very complex software developed using GL4Java and using Mesa 4.0, I have a defect which will be working only if I use Mesa 6.0 but if I move to Mesa 6.0, then my application crashes, I posted to get some help from the forum but no use. I tried asking the author but hopeless, In the end I changed my codes to use JOGL, not much difficult thing.
I sucessfully managed to fix the bug.
My Defect: I am using latest redhat version which uses gcc 5.0 and Mesa 4.0 is using

#2

I think you should see gl4java as a dead/abandoned/unmaintained project. AFAIK Sven Goethel hasn’t done any work on it for quite some time. I was doing quite some maintenance work on it myself, but then jogl came along… Jogl basically didn’t have any of the problems I was trying to fix in gl4java, so I stopped the work I was doing on gl4java. And as far as I know nobody took over.
Unless you really really need to use jdk <= 1.3, I don’t see any benefit in using gl4java anymore.

#3

Well JoGL and Gl4Java are vastly different, and in my honest opinion GL4Java is a much better binding to OpenGL, it has all the hazards and capabilites of OpenGL. the JoGL team is attempting to add layers of protection over OpenGL that make its use more limited. For example, last time I reviewed the code, there was no way to perform manual buffer swapping, GLCanvas was final and you couldn’t extend it, you had to use a factory to instantiate one, in addition, there was no way to make a context current directly. You have to indirectly tell JoGL thorught the invokeGL command or run all of your openGL commands through the display(GLDrawable drawable) callback. We are staying with GL4Java and have been invited to participate in JSR 231. JoGL is not a bad implementation, it just prefers safety over capability.

-Jason

#4

We prefer safety in LWJGL as well. We cannot stress how important it is to for software fail safely. In these days of dynamically downloadable code, safety and reliability are the #1 requirements for a Java API.

Cas :slight_smile:

#5

Safety is important, however if you claim to be a binding for OpenGL, then be a binding for OpenGL. It just as easy to pass a NULL array to any of the OpenGL calls, thus causing major havoc, are there checks for everything? We need to educate programmers. If you’re old enough to buy a hammer, you’re old enough to hit your thumb…

Jason

#6

But isn’t that the whole point these days, you keep a few programmers around who know not to hit there thumb with a hammer and they produce safety-hammers (impossible to hit your thumb with them you know) so that the rest of the programmers can stop worrying and hitting their associate thumbs and get on with building what ever it was you were putting nails into in the first place.

i.e. Programmers arn’t here to be educated, they are here to get the job done in the most efficient manner.

Taken to a greater extent, its also about protecting yourself from use cases you hadn’t initially accounted for. By covering all the thumbs up front its not possible for one of them to be forgotten about.

Kev

#7

The issue has gone far beyond programmers mistakes now, it’s also about malicious code, feedback, and customer satisfaction. LWJGL code will come with a guarantee that it cannot be used to initiate a malware attack. Part of that guarantee is that we check everything, all the time.

Cas :slight_smile:

#8

Good luck with that… :-*

My last two cents:
If it can be made safe, FULLY functional and fast, then I’m all for it, however I haven’t seen this possible yet. Please someone, make me swallow my words.

Jason

#9

LWJGL is safe, fully functional, and fast. Start munching!

Cas :slight_smile:

#10

Last time I checked LWJGL is only supporting full screen modes and does not support the Swing Widget set, or any windowing operations for that matter. Not everyone is trying to make games with these toolkits. It looks like I’m still hungry… :slight_smile: