When a remote object's "unreferenced" method is invoked by the system, it is
invoked in a separate thread created for that purpose which inherits its
"context class loader" from the thread that created it, which may be a remote
call dispatch thread (if the object's unreferenced state is due to the receipt
of a DGC clean call) or the DGC lease checker thread (if it is due to an
expired lease), which would, in turn, have inherited its "context class loader"
from a remote call dispatch thread processing some previous DGC dirty call. In
either case, the context class loader in effect when the remote object's
unreferenced() code is invoked will be fairly arbitrary. Because of this,
actions untaken during the execution of the unrefenreced() method that require
the correct setting of the context class loader, such as the correct resolution
of class in the return values of remote calls or the location of downloadable
URL protocol handlers, will fail.

The context class loader of the thread used to invoke the unreferenced()
method should be set to the context class loader stored for the
remote object in its corresponding Target instance-- the same context class
loader set when a remote call is dispatched to the object.

[This does make one wonder: should the access control context stored in the
remote object's Target instance be set like is done for call dispatching, as
well as the context class loading? For call dispatching, the access control
context from export-time is set to make security checks occur for parameter
unmarshalling without skeletons, an issue not really relavent to unreferenced()
callbacks...]