Blog

Follow up of previous post.

I did a few more tests and it looks like Haxe/Java doesn't support a specific feature. Using libgdx skins breaks haxe compilation. The haxe/java team is working on this and it should be fixed soon.

In the meantime, I modified libgdx code to make haxe happy. It wasn't too hard, only renaming a field in gdx/src/com/badlogic/gdx/utils/ObjectMap.java (hasNext) and recompiling the jar.

Using the modified jar as the -java-lib is all is required to generate working java code. The official libgdx/gradle project do the rest.

If you want to give it a try, you can download my modified jar on dropbox.

Just put it somewhere on your system and use it as the -java-lib jar as seen previously.

Feature wise, everything I tested seem to work. I had a few hipcups with the haxe/java support with the following things but nothing blocking:

• importing interfaces static fields is cumbersome, remember that you have to import like this:

import com.badlogic.gdx.graphics.VertexAttributes.VertexAttributes_Usage.*;

If you encounter "is already defined in X", it means you have some extra import which is not required.

• haxe/java does not seem to support varargs method calls, I had to create a native array to create a Material. I hope the API has alternative methods everywhere varargs are involved:

var attrs = new java.NativeArray<Attribute>(1);
attrs[0] = ColorAttribute.createDiffuse(new Color(0xE50000FF));
var material = new Material(attrs);

• double means Float, float means Single and long means Int64, type conversion can be boring, even more when bits are involved, cast can help, for instance cast (Position | Normal) will make haxe/java works for you instead of having to call haxe.Int64.ofInt(Position | Normal) for the same result.

I did not inspect the generated java source a lot, nor did I test performances. I just hope an haxe user is not too much penalized for his choice of language compared to a native java developer :)