Question: In the client program on which I work, we dispatch server calls to different Threads, to not lock the UI (equivalent of a SwingWorker).

This is made with a model class inheriting an abstract class containing the "update" method, which is preparing the new thread, and executing the code from an abstract method in this newly created Thread (plus other tweaks)

It works correctly, but my issue is that when debugging (or logging), it is hard to keep track of which method exactly called the "update" method, since the stack trace ends with the creation of the new Thread.

**What would be the proper way to keep track of the stack trace which led to call this new Thread?** Ideally, in a way which would show in the debugger's stack navigator (from Eclipse in this case; the idea is to navigate easily in the initial context).

Answer: 
Typically stack traces don't cross threads so this is going to be tricky. However, in the constructor of your Worker class you could access the current thread with...

```
Thread current = Thread.currentThread

```

You can then get the current stack trace of that thread by calling...

```
StackTraceElement[] currentStack = current.getStackTrace();

```

You can then store that in an instance variable for your worker and view that from your debugger. This has to be done before the control passes into the new thread, that's why I suggested doing it in the constructor. However, any method that gets called before the `start()` method of the new thread will be fine.
You say you do "like SwingWorker". In this case, why not using an [ExecutorService](http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html) ? Java concurrent framework is pretty well made, and would allow you to avoid the classic pitfalls of threading, amongst them your question.