The class and method descriptions should describe whether the object can be operated on by multiple threads concurrently, or whether methods can be called concurrently by multiple threads.

This doc bug has a corollary javadoc tool bug 4078855 that states that javadoc should be modified so it does not print the keywords "synchronized"
or "native" in the method signatures.

It's important for the developer to know whether it's safe for multiple threads
to operate on an object concurrently,.  To this end, it is important for the general class description and method descriptions to describe whether the object is thread-safe or not.  However, this synchronization can be implemented either in public methods or in private methods, and the Java Platform API spec should not declare one to be preferred over the other.  A licensee should be able to achieve synchronization internally if they wish.  

Example 1:  java.util.Enumeration interface - A single Enumeration cannot be used by multiple threads concurrently.

Example 2:  java.util.HashTable class - An instance of HashTable cannot be
used by multiple threads concurrently.

Reason: Even assuming that Hashtable should be thread-safe, there's no reason that we should tell people that we're achieving this by synchronizing all of its exported methods.  We should reserve the right to synchronize internally at the bucket level, thus offering higher concurrency.  (Geeks take note: the auto-grow functionality of Hashtables may prevent us from taking advantage of this specific suggestion, but you get the idea.) - Josh Bloch