Using Netbeans Lookup.getDefault() outside the platform.

A nice thing about the org.openide.util package is that it is standalone and my be used in any project. So you can use Lookup everywhere!

Using lookup outside NetBeans Platform means that the getDefault() lookup contains only the meta-inf services and the classloader. Which isn't bad if you do your jars with services. But in my case I don't.

So I needed somehow a way to add some objects in the global lookup. Nothing easyer: just define the System.property: org.opeinde.util with your classname (which must be a Lookup.Provider) and them make your own public methods to add objects to the lookup.

So I had com.example.MyLookup registered, with my own static method addToGlobal() and that was I. I could register with the lookup things like the main frame, etc. and use it with the normal Lookup.getDefault.lookup(MyObject.class). Fun stuff !

If this was helpful for you then maybe you'll like reading the other NetBeans Platform-related posts.

--
Emilian Bold
Java-loving consulting services from Timisoara, Romania.

Free as in beer and as in speech

An interesting thing this time on TV: a commercial of a mobile company where they say that after the freedom of speaking won from Ceausescu we will now get the right of free
speaking on the mobile (as in no money). I think this is something everybody could understand as a description of open-source with the free as in beer (the commercial) and free as in speech (won after the revolution).

Although the commercial is quite bad-taste especially after so many years after the revolution, it's an amazingly good description of the core free software movement ideea.

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.