Eclipse class loading
Most people who ever touch Java come to hate the CLASSPATH environment variable. It always needs tweaking to enable Java to load the desired classes. Eclipse, therefore, totally ignores it. One of the features of Java is that you can replace the standard class loader with your own. Eclipse does so; and in fact each Eclipse plug-in has its own class loader.
You then just specify which other plug-ins yours depends on, and it all works beautifully, 99% of the time. It really does.
The only problem is in the very rare circumstances when a plug-in is dependent on classes from some other plug-in which it can’t predict in advance. One such situation applies to Macrobug tools: I have lots of plug-ins which contain events relating to what’s happening on the device. One feature of the tools is to save that stream of events so that it can later be replayed. I’m doing this using Java Serialization, which is an easy way to convert an arbitrary network of Java objects into a stream of bytes which can be written to file – and back again.
The problem lies with that ‘back again’ bit. The plug-in responsible for reading this event stream (com.macrobug.eventrecorder) needs to be able to load classes from myriad other plug-ins which have events that got recorded.
That’s usually impossible, and for that reason I massively constrained the original class structure so that my recordings only contain very basic generic types from plug-ins which the event recorder can safely rely on.
But today I’ve come across this article, most of which I already knew – but not the bit about registering ‘buddy’ class loaders. So, all I have to do is ensure that all my event-providing plug-ins register themselves as a buddy of the event recorder plug-in: and in future, the event recorder plug-in will be able to load classes from those plug-ins!
Hooray. I only wish I had known this months ago.