I'll try to cut straight to the chase here, with a bit of effort I've now converted an application I'm working on from using JmePhysics2 (ODE implementation) to jBullet-Jme.
A major difference seems that with jBullet-Jme an added collision listener does not get notified unless the creation of the physics space (the first invoking of PhysicsSpace.getPhysicsSpace()) is done within the update of the GameTaskQueueManager.
Strangely enough everything else apart from the collision listener works without that, really I just was wondering why?
Also on a more general note, should I be submitting every interaction with the jBullet-Jme physics space into the GameTaskQueueManager Update queue?
Thanks
Chris
Hi.
I dont know why you get this result with the CollisionListener… It should not matter if you start the PhysicsSpace on the OpenGL thread or any other thread. Are you sure it is correlated like you say?
About modifying from another thread… In a normal setup OpenGL and physics run on the same thread, so you should in fact use the GameTaskQueue to update physics objects. Actually this is true for all objects that are used by the OpenGL engine, not just when you use physics. If you do the modifications in the update() call of course it is already the OpenGL thread, so no need to use the queue.
Cheers,
Normen
Cheers for the reply normen.
The second point I mentioned about the submitting to queue for the OpenGL thread; modify physics object and JME objects from the OpenGL thread - makes sense, thanks for clarifying that 
Now, the collision listener problem is
I tried it myself, not with your test and I could not reproduce the error. I did not try your code yet, though. By just looking through the code, I found this:
private final PhysicsSpace pSpace;
This might be your problem, final variables cannot be changed at runtime..
Norman please try the test class I wrote, on my machine it demonstrates exactly the problem I was trying to describe - consistently.
There is a chance (albeit a slim one) that my PC / IDE setup is somehow causing the problem I'm having, and if you try the test class this can be identified as the cause, or ruled out.
I have doubts that the final keyword would be causing this problem. However I ran the test again, replacing that line with these each of these
(Test1)
private volatile PhysicsSpace pSpace;
(Test2)
private PhysicsSpace pSpace;
There was no difference in behaviour, with line 47 was uncommented the collision listener still received no notification on a collision.
I even tried remove the field pSpace entirely, replacing it with PhysicsSpace.getPhysicsSpace() and still the problem persisted.
Any more thoughts on this?
doh, sorry… since I am currently rewriting jbullet-jme for jme3 I had to set up a new project and did actually not compile the changes I made to check this I recognized when I put in your class.
I experience the same problem now and it is related to a BulletGlobals call within jbullet-jme. Apparently jbullet uses java.lang.ThreadLocal variables to register the contact callbacks, so its true, only the thread that the physics is started on will get the callbacks.
I will have to include a workaround for this into jbullet-jme, luckily the callbacks are already queued in the PhysicsSpace anyway so it should not be too hard. I filed a bug here, you can track the progress and make comments there… or even post diff files? 
Thank you very much for your input.
Cheers,
Normen
No problem, and it's good to hear you're keeping yourself busy and that the jbullet-jme is making into JME3! :-o
Ah yes, threads …awkward little things that they are.
I've checked out the bug from the link - it all looks good & I'll follow the progress, and if I find the time and patience to work with threads, who knows I may even have diff file to post.
Currently I'm developing an Archery game using jme2 & jbullet-jme, so no doubt will have more posts about the physics to come! 
Yeah, probably the best solution… Do you have commit access?