commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (" <>
Subject Re: Thread-safety of Commons-Codec Encoder
Date Wed, 02 May 2012 19:16:26 GMT
The "kind of thread-safety" I would expect and want is for Encoder.encode()
to be thread-safe.  I should be able to instantiate and configure an
Encoder, then share it for multiple concurrent threads to use to call
encode() as many times as they please at the same time.  I will assume it is
up to me (the client/user of the API) to arrange for a happens-before
relationship between instantiation/configuration and the encode() call, by
using any one of a variety of means of doing so.  This is kind of a given
but I want to be clear.

I haven't looked at any of the source behind the Encoders, but one area that
may be problematic is any lazy-instantiation/initialization of state to
instance variables in a non-thread-safe manner by the encode() method.  If
Encoder had an init() method as part of its api, it would be easy to avoid
this problem but alas, it doesn't. 

FYI a good book on this tricky stuff is "Java Concurrency In Practice" by
Brian Goetz.

~ David

View this message in context:
Sent from the Commons - User mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message