commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Davies <>
Subject Re: Thread-safety of Commons-Codec Encoder
Date Thu, 03 May 2012 18:30:09 GMT
> 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:

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.

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

Mostly talking to myself here.


Julius Davies
604-222-3310 (Home)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n

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

View raw message