Question

When ever I see a class documented as thread safe, I wonder why it was not designed to be a utility class with all static methods like java.lang.Math, etc.

I’m missing valid driving force whenever I design a class in the scenarios like no state but chained methods in a single class.

Example 1: How about a class A that has a ‘thread-safe field’ S; I mean, the object ‘S’ itself is thread-safe. Can we declare all the methods and fields like S in class A to be static.

I hope my explanation is clear enough. Please clarify.

Note: Exclude javabeans, property holding classes, etc.. My question was regarding classes which perform some actions based on input params, they might need to make use of other classes as well.

I apologize that I edited the question. First draft was totally ambiguous.

Answer 1

I can easily imagine a situation where a class is required to have state, yet it’s also a requirement to be thread-safe. I use queues for worker-threads for example. It HAS to be thread-safe and definitely has to have state in it. (namely the elements in the queue)

EDIT:

Note: Exclude javabeans, property holding classes, etc.. My question was regarding classes which perform some actions based on input params, they might need to make use of other classes as well.

If by that you mean that your question is about truly stateless classes, then -by definition- your observation is correct. Those can almost always be expressed in static utility classes.

EDIT2:

I think you are being somewhat mislead by the fact, that a lot of times when we see static we can relax about thread-safety. (Though it’s not true in every case, just a rule of thumb) While thread-safety and statelessnes can go hand in hand in a way, static is an orthogonal concept. Furthermore, statelessnes does give you thread safety but thread safety doesn’t have to mean stateless. If that would be the case, the whole concept of synchronized would be unnecessary.