On 2 May 2012 19:18, Thomas Neidhart <[email protected]> wrote: > On 05/01/2012 05:23 PM, David Smiley (@MITRE.org) wrote: >> I am reviewing Apache Lucene's use of Commons-Codec phonetic Encoders for >> thread-safety. Unfortunately, there is barely any mention about >> thread-safety in the javadocs. I think that's a real problem. I noticed >> this old JIRA issue which touches on some of the related aspects of this: >> https://issues.apache.org/jira/browse/CODEC-55 >> >> I think the only safe thing for me to do is assume these Encoders are not >> thread-safe.
Yes, that is the safest option. What kind of thread-safety are you looking for? To be able to use the same instances concurrently in different threads? To be able to use different instances concurrently in different threads? To have a pool of instances used singly by multiple threads? > Hi David, > > unluckily not all of the encoders are thread-safe atm: > > codec | thread-safe | comment > ----------------------------------- > Metaphone | N | code-length may be changed > DoubleMetaphone | N | code-length may be changed > Nysiis | Y | > Soundex | N | maxLength may be changed > RefinedSoundex | Y | > ColognePhonetic | Y | > Caverphone1 | Y | > Caverphone2 | Y | > BeiderMorseEnc /| Y | not 100% sure, but no members are > PhoneticEngine | | changed when encoding and no setters > exist > > We should add this information to the javadoc and make all codecs > thread-safe imho. Agreed; this really needs to be done for (almost?) all Commons components. > Best regards, > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
