Question

There is a JDK function that, although the javadocs does not declare it as thread-safe, from looking at the code in Google, it seems that I could get the result I want by calling it from multiple threads without undesirable side-effects, since the function uses mainly stack variables. So it does not matter if it has synchronized blocks. I am wondering though if I am missing something and eventually run into trouble.
The function is connection.call(requestMsg, url); of SOAPConnection from SAAJ api. Any pointer on how I should analyze this in order to decide to use it from multiple threads or not?

Thanks!

Answer 1

The following quote comes from "How to Write Doc Comments for the Javadoc Tool"

The Java Platform API Specification is a contract between callers and implementations.

The Specification describes all aspects of the behavior of each method on which a caller can rely. It does not describe implementation details, such as whether the method is native or synchronized. The specification should describe (textually) the thread-safety guarantees provided by a given object. In the absence of explicit indication to the contrary, all objects are assumed to be "thread-safe" (i.e., it is permissible for multiple threads to access them concurrently). It is recognized that current specifications don’t always live up to this ideal.

To me this says, that you ideally should be able to assume that the standard Java APIs are thread-safe unless it is stated otherwise. But the last sentence says to me that this is a rather dangerous thing to assume that this is always true. Certainly, for most of Swing APIs you should NOT assume thread-safety.

I think that the following is a reasonable approach to deciding what you can rely on to be thread-safe:

• If the javadoc explicitly says something is thread-safe, you can rely on it being thread-safe going forward.
• If the javadoc explicitly says something is not thread-safe, you can rely on it being non-thread-safe going forward.
• If the javadoc says nothing, AND a careful examination of the source code tells you that it is thread-safe, you can rely on it being thread-safe going forward.
• If the javadoc says nothing, AND a careful examination of the source code tells you that it is not thread-safe, all bets are off. It could be a javadoc error, or a shortcoming of the current implementation.

(This is based on the observation that Sun / Oracle are unlikely to make changes that break backwards compatibility. Changing thread-safety characteristics of standard APIs could cause of insidious concurrency bugs … and is therefore doubly unlikely.)