When I went to interview at Google I talked with some engineer or other about Chrome and how I'd like to embed a JVM in it as the core clientside execution engine. Needless to say I didn't get the job but I still think it'd probably be the utterly brilliant panacaea we all want - high speed execution built in to every browser with proper language tools and support behind it, with hardware acceleration and DOM integration out of the box...

When I went to interview at Google I talked with some engineer or other about Chrome and how I'd like to embed a JVM in it as the core clientside execution engine. Needless to say I didn't get the job but I still think it'd probably be the utterly brilliant panacaea we all want - high speed execution built in to every browser with proper language tools and support behind it, with hardware acceleration and DOM integration out of the box...

Cas

Perhaps we should just make a new browser that has proper applet and java integration

Sorry to refresh this thread. I have a meeting tomorrow and I will have to speak about JOGL, they would like to know some things about the future of JOGL. Can someone tell me at least how many people go on fixing bugs and maintaining the whole library? Are Sven Goethel and Michael Bien participating to this project?

When I went to interview at Google I talked with some engineer or other about Chrome and how I'd like to embed a JVM in it as the core clientside execution engine. Needless to say I didn't get the job but I still think it'd probably be the utterly brilliant panacaea we all want - high speed execution built in to every browser with proper language tools and support behind it, with hardware acceleration and DOM integration out of the box...

Cas

Yes, I agree entirely. I code a lot of Javascript (and server-side C#) at work, and it's really shit. Well, the JS is, the C# is ok. Having a JVM in browsers would rock - especially if you could produce bytecode from whatever language you wanted. Awesome solution.

@gouessej Did you manage to get any info, or is the lack of activity over the last month an indication of things to come?

Yes I manage to get info. JOGL is in a good health, don't worry 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."

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Michael,I know there are a lot more calls in OpenGL vs OpenCL, but I would consider JNA for JOGL as well

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.

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

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org