Now you can improve JME with speed of light by wrapping c or c++ native library (ex Bullet physic or rig of road) (programmer specific)

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