gdx-jnigen: a stupid idea that might just work

Since i’m to lazy to type, i made a demo video. All the native code in libgdx uses this now. I explain the reasons in the video. Use at your own risk. Also, sorry for the crappy audio, my headset died.

edit: as Riven kindly pointed out, there’s a bug in the add method. Look at the offset, now back to me, now back at numElements, now back to me. Sadly, i never learned how to iterate over arrays given offsets πŸ˜€

20 thoughts on “gdx-jnigen: a stupid idea that might just work

  1. Curious as always… You did drop in the vid briefly JavaCPP is not to your liking, well hell.. roll ’em if you got ’em and bam jnigen for life; yo!

  2. programming is all about wheels…

    cool crazy new feature anyways. libgdx really taught me some weird things I never thought Java can do.

  3. holy cow you invented something thats more work than writing a jni wrapper manually…

    mind you that’s about par for the course for swig and others…

  4. Main motivation to not use Swig was that the generated APIs are hideous, albeit a lot faster in terms of development time.

    I don’t see how it is more work than writting all the JNI wrapper things myself? (build system, method stubs, array/string/direct buffer to pointer, refactoring method names, which is automatic with gdx-jnigen).

    Care to elaborate why it’s more work?

  5. it just seems you have to do all the stuff you normally have to write a jni THEN you have to make this long winded method and seemingly do a whole bunch of other stuff.
    my build system needs minimal editing for new classes copy/paste a line method stubs are copy/paste from the javah header and to pointer code is usually just a single line or so and like shelling peas…
    I honestly don’t see how this saves time, quite the reverse!
    I’m obviously missing something….

  6. If i add a new class, i don’t have to do anything. If i rename a method, i don’t have to do anything. If i change the signature, i don’t have to do anything. I never touch a single .h/.cpp/ant build script myself. Now, compare that to what you’d have to do if you manage your .h/.cpp manually. You have to invoke javah manually, copy over the new signatures, give every argument for every method an argument name and hope they match your java signature order.

    On the topic of resource managment: it’s damn easy to fuck that up and i’d rather have something automatic that guarantees that all strings and arrays are released when no longer needed.

    The long winded method is 50 lines of code for the biggest native code project, 10 for the smallest one. You write that once, just as you would write your make file once. I don’t know what build system you use, but i’d like to learn more how it copes with multiple build targets and their configurations πŸ™‚

  7. For me is not a so bad idea: in this way you can’t have code assistance by Eclipse (and no block comments inside your code!), so for a large C code production is the wrong way, but for a big java project with some little optimizations should be a good save-time. I agreed with Mario, this system could be just a way to speed up the work if used judiciously.

  8. I’m wondering since I haven’t learned much of JNI…

    can the JNIGen create JNI directly from C (or C++) codes or just from the Java?? It woud really be crazy if it can. πŸ˜€

    either way, it’s really cool.

  9. I have to say, this inspires me to learn C so I can make my Java run faster. Mario, you certainly do make some wonderfully crazy shit.

  10. Wow that is really slick. Reminds me of python scipy’s weave module that compiles c/c++ code into native libs that are loaded on the fly. Its a little bit different since it requires the production machine to have a build toolchain. However, the code is written in .py files as strings.

    I had been wanting to do some performance heavy calculations and needed C to the speed I wanted. I think I might use jnigen for that!

  11. Congratulations, it looks awesome !

    Do you know if there are guidelines somewhere about when to go native ?

    Keep up the good work πŸ™‚
    Carl

  12. I follow your video.
    I have an error:
    Exception in thread “main” java.lang.RuntimeException: Error copying source file: com\badlogic\gdx\jnigen\resources\scripts\memcpy_wrap.c (Classpath)
    To destination: jni\memcpy_wrap.c (Absolute)
    at com.badlogic.gdx.jnigen.FileDescriptor.copyFile(FileDescriptor.java:571)
    at com.badlogic.gdx.jnigen.FileDescriptor.copyTo(FileDescriptor.java:482)
    at com.badlogic.gdx.jnigen.AntScriptGenerator.generate(AntScriptGenerator.java:76)

    Use libgdx 0.9.7

  13. @Shumy
    Same here.
    My Workaround:
    I created a new package in my src folder: com.badlogic.gdx.jnigen.resources.scripts and put the memcpy_wrap.c from git there.

  14. BuildExecutor.executeAnt(“jni/build.xml”, “-v”) can not gererate .dll in libs folder

    Property “env.PATH” has not been set
    Property “env.PATH” has not been set
    [available] Searching D:goSheepWorkSpaceJniTestjni${env.PATH}
    [available] Unable to find i686-w64-mingw32-g++

    Seem like it can not find g++ compiler .I am sure that the Path variable have been set to /MinGW/bin .

Leave a Reply

Your email address will not be published.