I've just managed to start demos using my IDE after some voodoo stuff with instrumenting et al.
You can just use already provided jbullet-all.jar and copy just the demos package, this way you don't need to do any instrumentation. I suppose I should really create a readme.txt
I'm quite impressed with what I see. Although I'm worried about the performance issues.
Looks like those demos are taking up a lot of CPU power. Gets to 50-70% on my Centrino Duo.
And you don't use shaders, shades, textures, lighting effects. I guess performance would worsen even more in that case.
Could you speculate on performance issues a little bit. What are the bottle necks?
Maybe I'm using some libs incorrectly (some software rendering?) ?
I've put all dll's into the root of my project.
In comparison I've downloaded and started a Tokamak demo in pure C (OpenGL rendering). There is that demo with a hundred of cubes/cones/spheres falling onto a table (similar to the basic demo with cubes) and the CPU usage is close to none (somewhere around 7%).
Is it because of the physics calculations done in C? or because of the Java JNI calls to rendering?
I don't think this is Java-specific issue. The demos are rendering in loop without any FPS throttling, so you'll end up with (almost) full CPU utilization (and it's normal in many games). Shaders etc. doesn't play much role, since they're handled mainly by GPU. Software rendering is used only in applet demo.
I didn't tested Tokamak demo, but it must either limit FPS or have enabled vsync, which you can test too by either driver settings or by calling Display.setVSyncEnabled(true) in initialization code of com/bulletphysics/demos/opengl/LWJGL.java. You should rather compare this to the Bullet C++ pre-compiled demos (available in downloads).
Using C or JNI doesn't play role here. And JNI overhead with OpenGL is practically non-existent as you need to batch geometry anyway to render efficiently in OpenGL generally (JBullet demos do that).
Wouldn't it be better to bind physics calculations to C instead of writing it in pure Java?
For this issue, no. Generally yes it's also a way. I initially did a binding before and wasn't satisfied with it: bad API interaction with native stuff, you need to track objects to destroy instead relying on GC, maintaining native builds for all supported platforms is huge task, you can't use it in secure (sandbox) environments such as unsigned applets, there was lack of full-blown pure Java physics libraries, etc.
With JBullet it's as easy as just include one .jar and you're done with that, it simply works the same on all platforms with one build
The rendering in Java is not delayed right now, the only thing that worries me is the cooler on my notebook that starts to hum and the fact that at some point the rendering will be delayed or for some older hardware my games will not be real time but more of a turn-based nature.
Just limit FPS in your game loop, or redraw only when needed. The physics itself is running at fixed speed (maintained automatically by Bullet), so it shoudn't utilize CPU that much unless you overload the simulation of course