Monday, June 26, 2006

Weak References

The nice stuff about Java is that is has GC. The bad part is that the GC only takes care of memory. Why is that ?

Programmers like to be messy so we sometimes forget about little things like dispose() that memory. GC is great in this department. But we're also messy in the sense that we forget to close files, network connections, etc.

There are all kinds of resources, besides memory that the GC could, in theory, take care of.

On such thing are the listeners. I somehow have an inner fear about listeners since they seem messy, in the same way as memory managenent. God forbid you forget to remove a listener or your object will be kept forever.

So - why cant' the GC keep track of listeners also ? A quick solution seems to be the usage of weak references for the listeners. Supposedly a weak referenced-object is no longer needed so our listener can finally die.

And this is a simple way to involve the GC in managing the listeners.

The disadvantage is that there must be a strong reference to the listener at all times (when we need it) otherwise it could get GCed together with the Weak Reference.

We don't actually care about this when we have an ueber-object which implements XListener or we create an anonymous inner class (which creates a closure to the ueber). But if we do it the fluffy way with our own Listener implementation classes, it's back to ground 0 again. We still have to take care of the strong references, etc. Darn.

No comments:

The case of the different jsch 0.1.54 binaries

As part of the Apache NetBeans IP clearance we are combing through all the code and dependencies. One interesting thing we bumped into wa...