Using ThreadLocal with static methods

Is it possible to use ThreadLocal with static methods? I have a utility class with static methods. On rare occasions, it would be desirable to retain state for a thread (user). I have examined the ThreadLocal class code and, given the way it constructs a key in its constructor, it does not appear to be possible using the ThreadLocal class itself.

Creating separate instances of this class is not an option. I would rather forgo the retention of state rather than give up the convenience that static methods currently provide.

I am not opposed to maintaining a Map of all threads and their corresponding state. However, if I choose this approach, is there a way to know when to remove an entry from the Map, e.g. the thread terminates or returns to a pool?

Any suggestions would be appreciated.

I'm not sure I understand the issue. The class with the static methods should hold an instance of ThreadLocal in a static variable.

I was concerned that, if I maintained a ThreadLocal variable as a static variable, it would not be able to distinguish between different threads (users). However, upon reviewing the ThreadLocal code again, I see I glossed over the fact that ThreadLocal always retrieves the thread local values for the current thread so it appears my concern may be moot. Is this correct?

My other concern was that, if the thread originates from a thread pool the thread local values for that thread be reset (initialized) each time it is returned from the pool. I would not want thread local values to be retained for subsequent users of the thread. Is it reasonable to assume that the thread will be re-initialized each time it is returned from a pool?

I myself use ThreadLocal with static methods of a utility object and it works fine.
[ July 27, 2007: Message edited by: Sverre Moe ]

Basically, a ThreadLocal is a Map. The keys are Thread objects, and the Values are whatever you store in the ThreadLocal. When you ask the ThreadLocal for its value, it looks up the value in the Map, using Thread.currentThread() as the key. That's all -- nothing you couldn't code easily yourself. For some reason a lot of people think this class is mysteriously powerful, but it's really quite trivial. So for your first question, the answer is yes, that's correct.

For the second question, if the value must be reset when a Thread is taken from a pool, then the Thread is going to have to do that itself; it will not happen automatically. The ThreadLocal class knows nothing about your pool.

Thanks all.

Count me among those who thought this class "mysteriously powerful". I should have read the Javadoc more closely. I have since confirmed (as you already know) that it works the way I want it do.
[ July 27, 2007: Message edited by: Jay Damon ]