+1 I could do with a synchronous way of doing this. join() wasn't an option for me, as the worker threads are never returned to the caller. I've had to look up the progress message and determine from that whether it's finished. Or do a thread.sleep to wait for status of book to be installed.

Have you looked at o.c.j.bridge.BookInstaller for example code.

Recently fixed a bug in there that had the same problem that you were describing. As it was a contributed fix, I'm not certain that you can catch the end. But I think so.

It was BookIndexer to which the fix was applied. Should be similar issue here.

The issue here is two-fold:

• being able to install a book in a synchronous fashion
• being to specify an external thread-pool

On the first, that's what we need to do for tests for example. On the second, this around design, in that it is usually frowned upon to create your own threads in a J2E container (say Tomcat, JBoss, WebLogic, etc.). Generally speaking the container should be managing the threads.

Ideally the functionality in JSword should usually/always be written in a synchronous fashion, with a set of utilities on the side that allow you to do things in the background asynchronously and an optional thread pool to do this work rather than using JSword to create the threads.

Is it perhaps worth investigation using JSR236 and JSR237 to implement this framework. http://commonj.myfoo.de/ gives a tiny implementation of it.

+1 We should get rid of threads in JSword. Need to work with front-ends to make it happen gracefully. Maybe keep the old marking it deprecated.

It was trivial to remove thread creation in the call an move it to the caller.

Both Installer and Indexer are now synchronous. Threading is the caller's responsibility.