commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Davies <juliusdav...@gmail.com>
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:
    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.

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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message