LWJGL and Javascript - taking it further

The idea of a powerful Java engine that can be used from Javascript, definitely has me intrigued especially as a teaching aid, so I decided to take it further - can I really throw up a polygon that's using a shader? Of course I was not going to make things easy for myself the same binary for the "engine" must work universally anywhere LWJGL will work (for now just Linux and windows - know anyone with a Mac?).... As I understand it one of the main reasons for rewriting Java's scripting engine from scratch was to take advantage of the invokedynamic byte code. This has had profound effects not in only in terms of execution speed but seemingly the rewrite has an effect on the integration between Java classes and scripts. One thing right off the bat I though would cause issue is using buffers for things such as vertices, I was almost sure some madness like this would be needed

var intArray = java.lang.reflect.Array.newInstance(java.lang.Integer.TYPE, 7);

  fortunately things have moved on since, I though - lets just pretend I know no better and just try it with a JavaScript array...

var vts = [
  -0.5,     0.5,     0.0,        0,1,
   0.5,     0.5,     0.0,        1,1,
   0.5,    -0.5,     0.0,        1,0,
  -0.5,    -0.5,     0.0,        0,0 ]
var BufferUtils = Java.type("org.lwjgl.BufferUtils")
var verts = BufferUtils.createFloatBuffer(20)
verts.put(vts); verts.flip();
GLES2.glBufferData(GLES2.GL_ARRAY_BUFFER, verts, GLES2.GL_STATIC_DRAW);

As you're probably aware most of the "functions" in LWJGL are static methods so by creating a variable that's a Java type of the class you can access those methods. While you could just use the fully qualified class

var verts = org.lwjgl.BufferUtils.createFloatBuffer(20)

If you're using other routines its probably easier to have a Java.type var kicking round Having created a Java bytebuffer we can just put a JavaScript array into it! Having used a number of different embedded languages I have to say its usually a lot less convenient than that! I didn't bother decoding a PNG in JavaScript (I'm not that much of a masochist :) ) instead providing a method in the main Java class to return a texture handle... This is an example of doing the heavy lifting in Java, in a similar manner you probably wouldn't want to do all the low level stuff in JavaScript but instead provide general Java routines to do higher level functionality. Could this be useful for making a game? Most definitely! you could for example have your game engine sorting display lists of 3d entities, physics, advanced path finding and line of sight routines - all this would be implemented in your Java engine. While designing levels your editor could for example allow you to define collision zones, each zone could then have an event JavaScript. There are all sorts different "events" that you could optionally attach a JavaScript to, the limit is your imagination and maybe practicality, but for sure the fact the low level stuff is so easy to use could mean a third party adding a new item to the games HUD could be almost trivial... Done right the JavaScript may only add milliseconds per frame, but the flexibility and power could be very useful aside from third party moding, not only don't you need to recompile your game but potentially your in-game editor might mean you don't even need to restart the game itself, leading to a truly rapid game development environment, PAUSE, TWEAK, PROFIT ! You can find a texture shader example here Enjoy!