libgdx uses it to wrap Box2D, libjpeg, vorbis, mpeg123, and many other things, but jnigen isn't specific to libgdx. It can be used to build any native libraries for use with Java. Eg, Jglfw uses it to wrap GLFW. Next time you need to interface with native code, maybe you keep it in mind!

It's not that bad You can directly write the C/C++ source code in the Java source code, it supports iOS too and it seems documented but GlueGen already does a very good job on OpenGL, OpenAL and OpenCL. If a developer wants to keep C/C++ and Java source code into separate files, GlueGen should be used, otherwise jnigen is a better choice.

I'm not familiar with GlueGen. Gave it a very quick look. It looks limited to C, so if you need C++ that might be an issue. I can't comment much further on it without digging deeper, though I can say mapping C to Java looks quite complex.

It seems the biggest difference between jnigen and tools that generate Java code from native code (GlueGen, SWIG, etc) is that jnigen allows you to write and control the Java code. Typically this will mean a nicer Java API, since it is handwritten and customized for the intended usage. I do concede that it can reduce development time to generate Java code from native code.

jnigen also feels to me like a simpler approach to the problem. You end up with exactly what you'd have if you were hand writing JNI: Java native methods and corresponding native code (in a separate file). jnigen reduces the pain of JNI by generating and populating the native code and handling the build for all platforms. If you rename a Java native method, add new native methods, new classes, change method signatures, etc you don't have to do anything.

jnigen should work great for projects that want to keep source in separate files. If I were doing that, I would still use native code inline with the Java code, but only for the Java to native interface. The rest of the code I would put in a separate file. jnigen has a special "/*JNI" comment for includes, statics, functions, etc. The contents just get inserted in your native code.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org