The Artima Developer Community
Sponsored Link

Cleaning Up After Jini Services
Standardize the Way Jini Clients Release Resources
by Bill Venners
First Published in JavaWorld, March 2000

<<  Page 4 of 8  >>


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 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:

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();

<<  Page 4 of 8  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use