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 ----- Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://apache-commons.680414.n4.nabble.com/Thread-safety-of-Commons-Codec-Encoder-tp4600956p4604182.html Sent from the Commons - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
