I quickly discovered that coordinating the lifetimes of even a small number of threads (read: two) was easy to get wrong. There are the usual issues with state shared between threads; those can be solved with appropriate synchronization mechanisms. Stopping the threads turns out to be the tricky part.
To make things concrete, an OSGi bundle can implement an interface called BundleActivator, which contains just two methods: start() and stop(). OSGi calls these methods when the bundle is started or stopped. The general rules for implementing these methods are that they must return quickly, they can be invoked on any thread, and they should avoid doing things that could lead to deadlock. For example, a start() method should not attempt to use the OSGi facility for installing a new bundle because that is a long-running operation. Furthermore, because the level of parallelism in the OSGi implementation is not guaranteed, the installation call might block waiting for the start method to return; because install was called from start, deadlock arises.
The bundle is allowed (assuming security permissions are granted) to spawn new threads. However, the stop() method must guarantee that all of these threads have exited before returning. That's the root of the coordination problem.
What can happen if you get this wrong? Just about anything. The OSGi implementation I was working on was throwing ClassNotFoundException exceptions from classes I'd written when they attempted to access other classes I'd written in the same bundlewhich meant it couldn't be a classpath problem. That baffled me until I realized the exception was thrown from a thread in my bundle, which was still running after stop() had returned. The OSGi framework, thinking the bundle was stopped, had disconnected the class loaders for that bundle, causing a later request to load classes to fail. (Remember, class loading in Java is lazy.)