Hi friends
Thanks to RatKod i go around JNI and found good things.
First get to know JNA then become familiar with SWIG a great wrapper for c/c++/pythone in java.
But finally found the magic of BridJ(Link has updated) ( Java / native interoperability library that focuses on speed and ease of use.) . I invite developer to get to know this and easily wrap open source library for games like Bullet physic to java.
Bridj has uncompromised speed (thanks to dyncall and assembler optimizations)
Note: JME already has a wrapper for native Bullet.
Ye I know.But the version is 2.72 for 2010 but new version is 2.83 from 2015 with lots of great features.
jME 3.1 uses Bullet 2.82
Spend weeks of trying bridj to wrap physix…
good luck, would like to hear any infos if you get it working
Also consider that most of those wrapper generators are designed for C APIs, whereas bullet is a C++ API with classes, subclasses, methods, and templates.
javacpp allows to wrap C++ but I disagree with the creator of this API about his comparison with GlueGen… Most of those wrapper generators are unable to wrap OpenCL, OpenAL, OpenGL and OpenGL ES as efficiently as GlueGen which uses JNI under the hood. JNA is known to be slower.
I prefer pure ports than wrappers but the source code of Bullet is too big to be ported in one day and the original creator of JBullet stopped maintaining it several years ago 
I put these from https://code.google.com/p/bridj/wiki/FAQ?tm=6
BridJ is a library that lets you call C, C++ and Objective-C libraries from Java as if you were writing native code. It is a recent alternative to JNA.
With the help of JNAerator, it provides clean and unambiguous mappings to C/C++ code and a very straightforward and highly typed API to manipulate pointers, classes, structs, unions…
Binaries are currently available and routinely tested for the following platforms :
Windows (x86, x64)
Linux (x86, x64, armhf, armel)
Mac OS X (x86, x64, ppc)
Solaris 10 (x86… soon x64 and sparc)
Android 3.0 (armv5)
How is BridJ different from…
JNA
Things BridJ aims at doing better than JNA :
BridJ is BSD-licensed (while JNA is LGPL)
Supports C++ (really : virtual methods, inheritance, templates…)
Vastly better structs : lightweight, fast (one or two orders of magnitude faster to create), without any data duplication
Better performance for most function calls :
Direct mode is the default
Some calls are optimized with assembly code to reach near-JNI performance
Supports COM (special case of C++ support) : lets you use “real” Windows APIs (IShellFolder, ITaskBarList3…)
Cleaner API with Java 1.5 generics :
Iterable and typed Pointer<T>
import static org.bridj.Pointer.*;
…
Pointer p = pointerToInts(1, 2, 3, 4);
p.set(0, 10);
for (int v : p)
System.out.println("Next value : " + v);
Typed enums (that can still be combined as flags)
No such thing as IntByReference, LongByReference… Simply use Pointer, Pointer…
No such thing as Structure.ByReference vs. Structure.ByValue : if a function accepts a pointer to MyStruct, it’s gonna be f(Pointer s), if it accepts a MyStruct by value it will be f(MyStruct s). Simple.
Wanna cast a pointer to a function pointer ? ptr.as(MyFunctionPointer.class).
Pervasive multiple endianness support : if you retrieved a pointer to some GPU-filled memory and you know the GPU is little-endian while your CPU is big-endian, you can just call myPtr.order(ByteOrder.LITTLE_ENDIAN). You can then retrieve data from it as usual, and even cast to a struct pointer : it will just work as intended.
BridJ has better JNAerator support (in particular, the experimental -convertBodies option will convert function bodies from C/C++ into Java/BridJ code !), so you won’t need to write any interface by hand.
JNA’s advantages over BridJ :
BridJ doesn’t handle structs by value in function calls yet (neither in arguments nor in return value). This is being worked on, though.
JNA is Java 1.4 compatible (while BridJ requires Java 1.5+)
JNA is mature and stable, used by many projects
BridJ supports less platforms (Windows 32/64, MacOS X Universal, Linux x86/amd64/armhf/armel for now)
JNA has tons of working examples
SWIG
BridJ’s advantages :
it only requires you to build your Java program, whereas SWIG requires a painful native build on every target platform
the resulting API is generally nicer looking, without any manual configuration involved
you work directly with the original C/C++ headers, no need to write special header as with SWIG
SWIG’s advantages :
it’s C++ support is much more solid : once it compiles, you’re pretty sure it’s gonna work (with BridJ, errors will show up at runtime, typically at startup)
it has support for STL types (std::string, std::vector…)
it’s more mature and stable
Well bullet is a realy math heavy library, and for this java is actually really slower.
When I did image processing for my university, I found out that c++ in debug mode is around the speed of java for applying image masks. Reason is simply that the bound checks of the jvm for each pixel acces greatly outwight the actual instructions done. (ratio was around 2/3 bound checks)
This is one of the few cases where you actually want to use a unmanaged language.
I would be kinda interested to see a performanc comparison between the current jni implementation and your proposal however. The main benefit being that mainentance is simplified.
A teacher of mine said the same kind of thing more than 10 years ago and when he wrote his own Java to C converter, he obtained only a small gain (5%) compared to Java 1.3. The JIT compiler is able to remove numerous useless bound checks and I’m not sure that Bullet 2 heavily uses SIMD, I don’t see why Java would be slower in this kind of case and it’s already faster than Fortran in some cases when used for HPC.
JBullet is actually pretty close to native bullet on desktop. However on Android the parity is much more visible - probably because the Android JVM isn’t as good as the desktop VM.
Also JBullet is still based on an old bullet version (2.72 I believe) so many of the newer optimizations are missing.
1.) First of all, that speed difference was nothing said, it was actuall speed difference I encounterd, not somebody else and no hearsay. Because in the beginning I was like you, trying to do all the course in Java to prove the teacher wrong (as he noted that managed languages are not good for this). I learned my lesson for hard numerical stuff.
2.) Jbullet is way slower, but not because it is in java or the version is older, but because many broadphase optimisation were never implemented, For example for CompoundXCompound collision it does really X*Y collision for all childchapes, while the native one does build a acceleration tree first, and then do like 10 or so.
I still disagree with your teacher and he should read this paper:
Current State of Java for HPC
my 2 cents, I tried some of those wrapper,… (but not gluegen) and today javacpp is my favorite in term of ease (no need to write code) and maintenance, and iirc some feature that was not supported by JNA,…
I used javacpp for raknet_java, and my current assimp2java lib (part of assimp_xbuf).
PS: and I used jmbullet (a fork of jbullet) because I’m targeting desktop and because native wrapper always crashed on my desktop last year.
David thanks for replying .
In above replies javacpp is mentioned to be good too. I some how get interested in it.
I want to know your idea about BridJ. Dose BridJ can be used in case of jme or not.
I appeal you to have a look at it(please). It claims it has uncompromised speed (thanks to dyncall and assembler optimizations).Do you think it can able to wrap OpenCL, OpenAL, OpenGL and OpenGL ES as efficiently . I wanted to go around with some wrapper . Which one you prefer the most in case of efficiency and speed and also cross platform. If you mention your idea I will appreciate you.
Thanks so much.
Whats the issue with the current wrapper?
Do you have any performance issues that you can track down to the actual binding?
Regarding bridj, i builded bindings for directx 9 and 10 myself, 11 is not that easily possible anymore.
What all those “easy to use” generators have in common is that they only work for fairly simple libraries. If you have something more complex, you will have write some stuff manually. SWIG and javacpp.
I didn’t really benchmark, because it requires to have the same lib wrap/bind with different way. I just want to do the stuff simply and completly.
When I tried JNA/Bridj there are C++ limitation, that didn’t exist with javacpp. And since I was happy with it, I continue to use it (and avoid to write C/C++ 
)
No No . There is no issue with current wrapper.
I am just interested in such stuff. I thought every one may not heard of it so i mentioned Bridj.
And I just wanted to use every bodies idea. So that I can decide more carefully. Actually I wanted to find sth to be usable for complex wrapping. I will go around javacpp and play with it.
Thanks you helped me.
Indeed, my next experiments are probably also with javacpp.
Thank you . I will try javacpp .