There are a ton of reasons why I moved away from native code compilers.
Cas 
I’m not suggesting that’s an ideal way forward, but it is interesting that Google seem to be pushing a bit in that direction.
Especially as they are doing their absolute best to totally kill all native plugin code with Chrome OS.
Cas
All apart from their own.
Yes I manage to get info. JOGL is in a good health, don’t worry ;D According to bienator:
“The JOGL2 public api is IMO fairly complete “only” bugfixing and patching has to be done, but I really don’t know a release date.”
JOCL seems interesting too :
Actually, I do really want to be able to access Cg annotation values… still waiting for feedback on that.
JOCL does seem interesting; ScalaCL potentially even more so…
Michael Bien seems very busy with JOCL, maybe talk about that to Sven.
mbien did respond to a previous thread of mine on the subject, commenting that it was Sven’s area and that he was on holiday… I gave it a gentle bump when Sven got back, but maybe a PM wouldn’t do any harm.
Thanks.
sorry to bump again, but I have a feeling that this thread is still very relevant to the future of JOGL2 and remains mostly unanswered. (deployment issues, magic certs, LWJGL merge, newt, es2, competing against WebGL?)
Another month has gone by, and there is no clear future laid out for JOGL2. Sven I appreciate if you are working on this behind the scenes, but is was back in october/november when JOGL was declared alive and kicking after Sun pulled the plug. I haven’t really seen any public progress since then. Ok I know there is a git repository, but there is no community around that. We are still sat here on sun bb’s waiting for news.
Anyway I’ve spent the last month playing around with GWT. Already there are 3 Java bindings down to WebGL. Is it worth at this point to consider using the same approach for JOGL? I like the JOGL API’s, and I don’t see why gluegen couldn’t be generating the WebGL ES2 binding for us? JOGL has the advantage of maturity, and quite a good following…
I just want to get a feeling for the future of Java OpenGL in the browser. When I see how fast things are progressing with WebGL, it makes me wonder if JOGL2 has any future at all, unless that is the binding changes.
http://learningwebgl.com/blog/
http://code.google.com/p/gwtgl/
At least the excitement around webGL might mean that the graphics card manufacturers pay more attentention to testing their drivers with OpenGL rather than just Direct3D.
You guys are being quite pessimistic… Really though, deployment issues don’t matter much. Look at runescape for example, pretty much the most popular web mmo, do you think all these certificates and deployment things stopped them? Hell no. They have a goal and are working toward it.
Users are ready to accept these certificates or what not if they get to play a quality game. So what you should be working at was making a quality game and not worrying about all this webgl/google/whatever “World Domination” crap.
We have already answered to these questions as far as I know. Why do you speak about a binding for WebGL whereas it is already possible to use JOGL 2 in applets? The magic certificate will no more work, there won’t be any merge with LWJGL as Michael is not interested by this.
This is news to me (and not very happy news at that).
[quote]We have already answered to these questions as far as I know.
[/quote]
really? the lack of certificate is news to me, and so is the decision regarding LWJGL. But both are bad news items 
can you point me to the discussion please?
[quote]Why do you speak about a binding for WebGL whereas it is already possible to use JOGL 2 in applets
[/quote]
Many reasons I already mentioned, but mostly because it doesn’t require a client side plugin(Java), or certificate, and is pretty much instant startup.
If anyone’s interested, you can implement JOGL in terms of LWJGL. Just not the other way round.
Cas
Well, I don’t believe I said it this way. But what i said is that I am in favor of choice since not having a choice as “consumer” is always bad. But JOGL is BSD anyone can do anything (s)he wants with it… merge, fork, sell…
I am working now most of the time with CL (check out some demos if you like; screenshots) AND I am writing on a bachelor thesis… so don’t expect major news regarding jogl from me the next few month.
WebGL:
the last conversation i had with the guys of one of the mentioned projects is that using JOGL’s interfaces was on there plan to investigate and they don’t see any showstoppers, but this was around one month ago.
generating static methods is one single flag in gluegen (i believe its even on by default). JNA is far more convincing as an alternative as the generator of LWJGL for me.
[quote]WebGL:
the last conversation i had with the guys of one of the mentioned projects is that using JOGL’s interfaces was on there plan to investigate and they don’t see any showstoppers, but this was around one month ago.
[/quote]
I asked on here about using the JOGL API’s and the guys didn’t seem to be aware of JOGL at all…
http://www.khronos.org/message_boards/viewtopic.php?f=46&t=2353&start=0
I’m now playing with GWTGL http://gwtgl-examples.appspot.com/ and so far I quite like the approach of keeping a binding and wrapper implementation separate. This might make adopting JOGL2 API an easier task, but I haven’t heard from the guys for a couple of weeks.
PS the OpenCL stuff is looking Very nice!
I agree with what you said. If you find a solution to use JOGL with WebGL, let us know. However, I fear that WebGL won’t be fast enough for resource hungry OpenGL games
Michael,
I know there are a lot more calls in OpenGL vs OpenCL, but I would consider JNA for JOGL as well (I do not actually know what LWJGL is). Is the CPU constantly pegged on all or any of the games made using JOGL? If not, then there might be high price being paid for static calls, and the drop off using JNA negligible. Even if this was the case, I think not nearly all of it is being tied up in actual Native calls. Aren’t Display Lists an effective mechanism for reducing the volume of calls anyway?
Gluegen is something that needs to be understood, maintained, & you actually have do builds on all the platforms that need support (or maintain cross compilers). This effectively means that JOGL is being built / maintained from the ground up. Using JNAerator to build your JNA bindings frees up resources to actually work on the high level bindings for JOGL 3.0, or whatever. There’s JNA support underneath.
Looks like you will be out of school in the not too far future, reducing the JOGL footprint could allow you to have a hobby project without comprising either it or work. Olivier manages JNAerator & projects derived from it, specifically JavaCL, & I know he is out of school. (For other readers who have Nvidia 195 or higher you could run JWS demos from http://code.google.com/p/javacl/, if interested)
I am only bringing this up now on page 6 of a marathon thread, because I thought it might be a blind spot.
Jeff
It is a very bad idea as JNA is slower than JNI (JNA uses Microsoft Platform Invoke under Windows which is noticeably slower than the path used by JNI) and GlueGen works reliably. I highly discourage Michael to use JNA instead of GlueGen. I’m sorry, I’m a quite old JOGL user and I will refuse any use of JNA in it.
Yet another Java OpenCL binding… I don’t really understand such fragmentation as it is always the same history. There were at most 5 Java bindings of OpenGL some years ago and now there are only 2 bindings. How many people will waste their time in maintaining very very similar libraries instead of building 1 or 2 tougher ones? JOCL is Michael’s thesis project, he has to make any decision concerning it (so I won’t have the last word anyway) but I rather encourage the author of javacl to join the JOCL project or at least to use GlueGen instead of JNAerator.
JOCL has some degree of interoperability with JOGL so keep it up Michael 
A back port in JOGL 1.1.1 could be interesting for me but there is no hurry about this.