> 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: [email protected]
For additional commands, e-mail: [email protected]
