The @ThreadSafe annotation

When you’re writing a library (or any code, really), you should make sure that you’re not only writing code which will cover your use case for it, but also that you’re doing it in a way that others could benefit from it. With this I don’t mean early optimisations, or functionality which could be easily labeled as YAGNI, let me be clear on that. But effective code should be self-explanatory, not only in the naming and its modularity, but also in the way it can be used. I found a great example of how to do this on the AWS SDK for Java, since I had to use it while trying AWS Lambda. I was trying to determine if I could safely reuse one of their clients when I stumbled upon this comment on StackOverflow about the @ThreadSafe annotation.

Place this annotation on methods that can safely be called from more than one thread concurrently. The method implementer must ensure thread safety using a variety of possible techniques including immutable data, synchronized shared data, or not using any shared data at all.

That’s exactly what I needed, official confirmation from the author of the library (in this case AWS) about its use on a multi-threaded context. It seems that the original idea for this annotation, and others, came in the “de-facto” Java concurrency bible, Java Concurrency in Practice.

AWS have their own implementation of the @ThreadSafe annotation.

/**
 * Documenting annotation to indicate a class is thread-safe and may be shared among multiple threads.
 *
 * @see NotThreadSafe
 */
@Documented
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.CLASS)
public @interface ThreadSafe {
}

And yes, the client I needed is thread-safe.

Published by

juanmacias

Software developer with a passion for Scala, football, tennis, photography, travelling, playing the guitar, learning languages (real ones), and hacking around.

Leave a Reply

Your email address will not be published. Required fields are marked *