Advertisement

What does this have to do with Jini?
Although I've been focused on Java technology since early 1996 and have written many Java programs, articles, and books, while pondering a problem associated with Jini, it finally dawned on me why finalizers really exist. This light bulb lit up in my brain a day after my second meeting with the Jini architects at Sun's Burlington, Mass. facility, where I participated in a design review of the Jini Service UI proposal. I hope this article will trigger a discussion about the issue; I have created a discussion topic at the Jini Forum at Artima.com to host that discussion.

While thinking about Jini service UIs, it occurred to me that Jini clients will often pull in, from the lookup service, objects of whose class the client has no, or only partial, prior knowledge. If such objects don't make use of any finite resources on the client besides memory, the client can just release all references to the objects, and the garbage collector will reclaim the memory. But what if such an object, upon finding itself resurrected inside the client, opens a socket back to the host from which it came? What if such an object fires off a thread? What if it, upon finding itself with sufficient permission, opens a file on the client side?

If all these activities took place in a Java application, the program would likely include some code that had sufficient prior knowledge of the object's class to enable it to invoke a cleanup method. After all, the object had to be instantiated somewhere inside the application, and instantiating an object most often involves prior knowledge of its class.

But in a mobile code scenario, such as a Jini client receiving objects from a Jini lookup service, the client code may not have any more knowledge of the object's class other than the java.lang.Object contract. The code that originally instantiated the object, which most likely has full knowledge of the object's class, is sitting somewhere else across the network, not in the client. If the code that knows how to invoke a cleanup method on the object is sitting across the network, the client code can't call the cleanup method locally, in the client's address space, where the nonmemory resources are being held. Thus, the client and Jini have a problem.

The problem arises because of an intersection of two Java and Jini features:

• Garbage collectors release only JVM memory and don't automatically clean up anything else.
• Jini clients may download objects about which they don't have full prior knowledge. (Classes and interfaces the client doesn't have available locally can be downloaded.)

Given that I became aware of this problem while thinking about service UIs, I decided to propose a solution in the Service UI proposal, which I brought to my meeting with the Jini architects. I invented an interface called Terminatable that declared one method, terminateService(). Here's the interface with javadoc comments describing the semantics of its one method:

package net.jini.service;

public interface Terminatable {

    /**
     * Terminates a service and prepares its service object for garbage collection.
     * Once this method has been invoked on an object, the service may no longer
     * be usable by a client. Thus, this method should only be invoked on a
     * service object right before all references to the service object are
     * released. To use the same service again once this method has been invoked on
     * the service object, the client will have to download the service object
     * again.
    */
    public void terminateService();
}