Porting to Browser

Hi guys.

I want to understand a bit more about how JME architecture works. I wanted to know where in the code would I have to look if I wanted to implement a browser layer for webgl. I want to see if its something I can tackle as Im a decent javascript developer and I also dabble a bit with java coding. Ive played around with GWT a little as well.

Im thinking there’s probably a “platform” layer somewhere that can use lwjgl or android or whatever. Then there must also be some kind of layer for the asset manager system to work on different platforms. Probably the same for the audio system as well. I know bullet has been ported over to javascript with emscripten so Im thinking that could work in the browser as well. Any thoughts on the way forward?

I have a 3d project coming up and I think JME in the browser would be a good solution for me. That way I can support both desktop and browser targets.


LWJGL jmonkeyengine/jme3-lwjgl at master · jMonkeyEngine/jmonkeyengine · GitHub
JOGL https://github.com/jMonkeyEngine/jmonkeyengine/tree/master/jme3-jogl
Android jmonkeyengine/jme3-android at master · jMonkeyEngine/jmonkeyengine · GitHub

For assets, assumed that the current code can be compiled (?) correctly to javascript, you will only need to make an AssetLocator that opens streams to whatever a javascript/webgl app is supposed to load assets.

Thx! :slight_smile: I’ll have a look at these. Also, is there any specific procedure for adding a new platform?


That will be really great. :grinning:
Thanks a lot.

You’ld need a JVM that runs on JavaScript. A couple that came up with a quick Google:

https://www.javapoly.com you load Java libraries or source code like script assets. It seems to rely on parts of the second:

http://doppiojvm.org this one seems more like a traditional JVM, in terms of use. It has a full implementation of the Java8 class libraries available.

I have not used either of these, so can’t really comment on their usefulness, performance, etc.


actulal gwt crosscomplies java to javascript, so it would work in theory.


GWT only compiles a small subset of java classes to javascript, theres a huge amount of classes jME uses that are not converted.

1 Like

Any idea off the top of your head which classes those are?

1 Like

Way too many to get anywhere. I didn’t say “GWT doesn’t convert a few classes” I said “GWT only compiles a small subset of classes”.

1 Like

My main suspect here would be directbytebuffers, as they make no sense in javascript

1 Like

libGDX (open source java game engine) use GWT for deploying on web. It may be a good idea to see how does it handle the web part.
some quick googling :


There are lots of topic regarding this on stackoverflow.com.
Hope it helps you.

1 Like

Also worth mentioning a Quake2’s Java port was ported to Javascript using GWT


The version in question has been ported from a Java port of Quake 2 that already existed called Jake2. The team used Google Web Toolkit, the Canvas API, WebGL, and WebSockets to recreate the game in its HTML 5 form.

So it is theoretically possible, it just needs an insane amount of work.

1 Like

Thx for all the pointers guys. Im first gonna try getting jme-core compiled with Gwt and see how many things Gwt complains about. Then I’ll have a clearer idea of what we looking at for the rest of the modules.


Thanks so much . We hope to hear good news. :grinning:

1 Like

Just wanted to put this here for future reference.

From the little bit Ive researched into getting JME built with GWT, getting everything working in the browser could be quite a lot of work. GWT is only a compiler framework converting from java code to javascript. For classes in the java standard library that you want to use, you would have to implement them and then tell GWT to use them at compile time. There is a small subset of emulated JRE std library classes in the standard distribution. However, some of the more important ones like java.lang.Thread are not there.

The libGDX guys got around this by implementing a substantial amount of the JRE classes themselves. So any effort for JME could use some of that code, I suppose.

Its not impossible, it will just be a lot of work. I think some changes will be needed in the core as well to mitigate any existing dependence on multithreading, if that’s even possible. I dont know to what extent JME uses or requires multithreading. So at least some support from the core team will be required, even if its just moral/advisory support.

Also, integration with native bullet will probably need bullet to be compiled with emscripten (not difficult) and then have the glue code written in native GWT methods to bind everything together. Im also not sure if the

There is one thing, though. The future of GWT seems a bit uncertain. Google is still using it for things like Google Developer Console and Google Adwords and stuff like that. But development on the project does appear somewhat stagnant. But it is quite solid and robust.

1 Like

Html5 compatible browsers should have multithreading support: http://www.w3schools.com/html/html5_webworkers.asp

1 Like

Those following this thread may find www.teavm.org interesting. They’re translating Java bytecode, not source. The project does seem to have an active community, and they are working on implementing the standard runtime classes in a way that will function with their emulator.

Disclaimer: never used it myself, just something that I stumbled across.


The internet is wonderful :smiley:

1 Like

Wow! That looks really promising.

1 Like

Hi guys, I just found another not mentioned here option the WebGL4J project: https://github.com/sriharshachilakapati/WebGL4J.git

Some information:

1 Like