There’s an exciting new prospect in the world of Java web publishing called DukeScript.
Jaroslav Tulach, NetBeans Founder and Initial Architect, and Anton (Toni) Epple, a Java Consultant and Trainer, have recently won a 2014 Duke's Choice Award with DukeScript, a technology meant to bring Java to every client, mobile or desktop, without the need of a plug-in. In spite of its misleading name, DukeScript is not a new scripting language but an attempt to “put Java back in JavaScript”, in an attempt to fulfill the initial vision for Java: Write Once, Run Everywhere.
At this time the core team is busy working towards the 3.1 release, but if anyone starts experimenting with this we’d love to hear about it.
Question would be, could it be possible to write a jme renderer that uses webgl for rendering, and works trough this?
That way we kinda instantly would support most platforms.
The author has written a page on GWT detailing what he perceives as GWT’s shortcomings compared to his own Bck2Brwsr VM.
I would prefer to support Android natively like we do now – we’re already a Java engine so it’s pretty weird to convert to JavaScript just to run on Android. Same for iOS; he’s using RoboVM to… run the code in the browser? That sounds a bit strange to me, maybe there’s something I don’t get, but just using RoboVM or Avian directly seems less complicated.
Windows Phone on the other hand could be a good target.
Did some asking around. If anyone wants to take a whack at this, this should be enough to get you started making a @JavaScriptBody based renderer for jME3.
Here is what I just learned about 3D:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-ios/src/main/java/com/jme3/renderer/ios/IGLESShaderRenderer.java
And
https://developer.mozilla.org/en-US/docs/Web/WebGL/Using_textures_in_WebGL
If I compare the ios and webgl calls, I would guess you need something like this for DukeScript:
class WebGL {
private final Object gl;
WebGL(String id) {
gl = init(id);
}
void bindTexture(int target, int texId) {
glBindTexture(gl, target, texId);
}
So, to get this straight - it is a jvm written in javascript? Somehow, I want to run it inside javafx webview, to have jvm on top of javascript running on top of jvm
Anyway, I think I would feel less violated even if they would do jvm in Adobe Flash…
@abies said:
So, to get this straight - it is a jvm written in javascript? Somehow, I want to run it inside javafx webview, to have jvm on top of javascript running on top of jvm ;)
Anyway, I think I would feel less violated even if they would do jvm in Adobe Flash...
To be honest, i find it way more interesting as a gwt replacement after reading a bit about it.
As it would allow me to do all kind of java stuff without having a very complex build.
I have played a bit with Bck2Brwsr and I admit that it is very easy to use even though I’m not a big fan of JavaScript. The Netbeans plugin seems to be a bit broken but you can give it a try with Maven: The few commands to enter to run a simple test
There is an example with TeaVM + LibGDX + WebGL here. In my humble opinion, it should be doable to do exactly the same with Bck2Brwsr and another engine. It’s possible to use the HTML5 full screen API to write a full screen “application” with this stuff
In my humble opinion, it is a nice solution to target the operating systems on which we have no chance to install a JVM, for example Firefox OS.
TeaVM seems to be faster than Bck2Brwsr according to this test but it uses a very old version of the latter (which supports OpenJFX/JavaFX too).
@erlend_sh You’re welcome. TeaVM claims to be faster than GWT but this benchmark doesn’t confirm it. Please can some people give it a try?
I’m going to spend some time on using it for 2D non gaming applications first. If it’s really worth it, I’ll see what I can do in 3D. Several JMonkeyEngine renderers can be used as a starting point to write a WebGL backend but keep in mind that Bck2Brwsr supports only a subset of the Java SE API (compact profile?). My skills in JavaScript are a bit low, the web browser often gets frozen and displays some warnings when loading a large file takes too long
As far as I can tell, WebGL is still noticeably slow on MSIE 11, it is a less bad on Project Spartan under Microsoft Windows 10 Preview build 10049. I got a few crashes on a few Windows laptops under Windows 7 but updating the drivers was often enough to improve the situation. It’s still slower than JOGL, you can compare them yourself by testing this JOGL demo and this equivalent WebGL demo (got a BSOD several times with this one). It’s more obvious with this JOGL demo and this WebGL demo (N.B: there is a little occasional Z fighting in both). Switching to full screen improves the frame rate on some web browsers including Mozilla Firefox but Chromium/Chrome beats them all.
I advise the developers to disable the obfuscation if something goes wrong in the generated JavaScript code as usual.