> From: Eric Fixler [mailto:[EMAIL PROTECTED]] > > I'm wondering if there's a design reason why HitCollector is > an abstract class, rather than an interface.
I don't recall my thinking, if any, when I did this. An interface is more flexible, since it can be a mix-in, but calls to interfaces are slower on some JVMs. HitCollector does need to be efficient, so this could be be significant. I just searched around and found a benchmark at: http://waitaki.otago.ac.nz/~bryce/gcj/meth-inv-bench.tar.gz With IBM's 1.3 Linux JVM I get: no call: 90ms [9ns / call] local: 30ms [3ns / call] private: 30ms [3ns / call] interface: 381ms [38ns / call] i/f after cast: 301ms [30ns / call] abstract: 30ms [3ns / call] abstract w/cast: 46ms [4ns / call] With Sun's 1.3 or 1.4 on Win2k I get: no call: 100ms [10ns / call] local: 331ms [33ns / call] private: 90ms [9ns / call] interface: 341ms [34ns / call] i/f after cast: 330ms [33ns / call] abstract: 331ms [33ns / call] abstract w/cast: 300ms [30ns / call] So for at least some JVMs interfaces are still slower to call than abstract methods. Whether this is enough to make a measurable difference with HitCollector is an experiment I'd like to see conducted before changing HitCollector to be an interface. Doug -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
