This tip is as relevant to general Java programming as it is to Java3D: don't burn large amounts of time in your event listening methods or in a behaviour's processStimulus method. The thread that calls your listener method is not yours to do with as you see fit: it's an AWT or Java3D thread that has important work to do elsewhere. If you do start burning serious amounts of time in a callback the AWT event queue will start to fill or Java3D will start to fall behind in it's processing. This effect can snowball. For example, if you take too long to handle one event by the time you've finished there may be another three events waiting for you, then another seven, and so on. Like garbage collection (see tip #4) this can lead to inconsistent frame rates.
The solution is to start being lazy. That's lazy in the sense of lazy evaluation, not lazy as in "wearing your socks inside-out instead of washing them". Different kind of lazy.
The basic idea is not to try to do everything at full frame-rate. One simple way to do this is to run different bits of processing code every alternate frame - move objects one frame, check for collisions the next frame. A better solution is to run your complex processing code in a separate, lower priority thread and so decouple the job of rendering from that of updating your application. By making processing code asynchonous to rendering code, you get snappy visuals without crippling what your application can do. Just remember to take care how you synchronise your threads (see tip #3).