On 3 May 2012 19:30, Julius Davies <[email protected]> wrote: >> So if we agree that the Encoders that exist are thread-safe (as we've >> defined it) and that they should be in general, then I plan to treat them >> that way in Lucene. > > > I guess you're saying you'll do this: > > Pattern #1: save some memory, lose some thread safety > --- > public class MyClass { > private static Encoder E = new Encoder(); > > public void myMethod() { > // need to encode or decode for some reason: > E.encode(stuff); > } > } > --- > > Instead of this? > > > Pattern #2: lose some memory (temporarily to hold encode table), gain > some thread safety: > --- > public class MyClass { > public void myMethod() { > // need to encode or decode for some reason: > new Encoder().encode(stuff); > } > } > --- > > > Base64 definitely requires pattern #2, but the others appear to be > less complex, and might be okay.
Base64 has been made thread-safe in trunk (it was not thread-safe in 1.6). > Interesting dilemma. As an (inactive) codec developer, I prefer > pattern #2 because it means less work for us, but, at the same time, > there is no way to force developers to go with pattern #2 (even if we > documented developers might not read it) and so coding defensively > over here in case developers pick approach #1 could result in less > work for us in the long run (fewer weird race condition bugs filed in > Jira?). > > Mostly talking to myself here. > > > -- > yours, > > Julius Davies > 604-222-3310 (Home) > > $ sudo apt-get install cowsay > $ echo "Moo." | cowsay | cowsay -n | cowsay -n > http://juliusdavies.ca/cowsay/ > > --------------------------------------------------------------------- > 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]
