Has the JNI feature moved / evolved / not been implemented yet in the latest Lime? I’m looking at lime.utils.JNI but it’s looking a bit sparse?
On the same note, do Android native extensions work the same as before or have they not been implemented yet? I’ve noticed that a lot of the Android stuff that was done using a Java activity before is now handled by SDL.
http://www.openfl.org/blog/2015/04/08/openfl-hybrid-release/#comment-1981516890 ? CMIIW still in the works I guess.
The goal is to allow the same functionality, as much as possible, the Java side on this is done but the JNI helper class is not implemented, I want to consider whether we want it as-is, or something different
So, so far we have the Java extension API the same as before with the onPause/onResume etc getting called but we can’t communicate between Haxe and Java yet. Does that sound about right? Is it possible for me to copy some files from Legacy to get JNI back just for now or is a bit more involved than that 
?
If you are okay with touching C++, you could take a look at that. So long as there is access to the environment from JNI, I think the former JNI helper could work in Lime 2
Does anyone have any links to documentation for the Haxe C++ target and communicating between Haxe and C++? Specifically the AutoGC type at the moment but anything else would be useful. I’m looking at modifying Lime to include JNI again but am having trouble finding any references
Mostly it’s by looking at source code, you can see the “ExternalInterface.cpp” where most of the “DEFINE_PRIM”, “val_" and "alloc_” calls are made for the CFFI API
There is some detail here:
Hello,
What are the plan for java extension now ?
We use haxe / openfl at work and we’re stuck with legacy backend because we can’t use our extensions on lime 2 (hybrid mode doesn’t compile for us).
Is there any progress on this point since bubba asked ?
Thanks a lot.
Its one of two key things on my mind, text and JNI, it has not been forgotten 
2 Likes