Force other developers to call method after completing their work

Question

In a library in Java 7, I have a class which provides services to other classes. After creating an instance of this service class, one method of it may be called several times (let’s call it the doWork() method). So I do not know when the work of the service class is completed.

The problem is the service class uses heavy objects and it should release them. I set this part in a method (let’s call it release()), but it is not guaranteed that other developers will use this method.

Is there a way to force other developers to call this method after completing the task of service class? Of course I can document that, but I want to force them.

Note: I cannot call the release() method in the doWork() method, because doWork() needs those objects when it is called in next.

Answer 1

This seems like the use-case for AutoCloseable interface and the try-with-resources statement introduced in Java 7. If you have something like

public class MyService implements AutoCloseable {
    public void doWork() {
        // ...
    }

    @Override
    public void close() {
        // release resources
    }
}

then your consumers can use it as

public class MyConsumer {
    public void foo() {
        try (MyService myService = new MyService()) {
            //...
            myService.doWork()
            //...
            myService.doWork()
            //...
        }
    }
}

and not have to worry about calling an explicit release regardless of whether their code throws an exception.

---

Additional answer

If what you are really looking for is to ensure that no one can forget to use your function, you have to do a couple of things

1. Ensure all constructors of MyService are private.
2. Define a single point of entry to use MyService that ensures it is cleaned up after.

You would do something like

public interface MyServiceConsumer {
    void accept(MyService value);
}

public class MyService implements AutoCloseable {
    private MyService() {
    }


    public static void useMyService(MyServiceConsumer consumer) {
        try (MyService myService = new MyService()) {
            consumer.accept(myService)
        }
    }
}

You would then use it as

public class MyConsumer {
    public void foo() {
        MyService.useMyService(new MyServiceConsumer() {
            public void accept(MyService myService) {
                myService.doWork()
            }
        });
    }
}

I did not recommend this path originally because it is hideous without Java-8 lambdas and functional interfaces (where MyServiceConsumer becomes Consumer<MyService>) and it is fairly imposing on your consumers. But if what you only want is that release() must get called, it will work.

Answer 2

Yes you can

You can absolutely force them to release, and make it so it is 100% impossible to forget, by making it impossible for them to create new Service instances.

If they did something like this before:

Service s = s.new();
try {
  s.doWork("something");
  if (...) s.doWork("something else");
  ...
}
finally {
  s.release(); // oops: easy to forget
}

Then change it so they must access it like this.

// Their code

Service.runWithRelease(new ServiceConsumer() {
  void run(Service s) {
    s.doWork("something");
    if (...) s.doWork("something else");
    ...
  }  // yay! no s.release() required.
}

// Your code

interface ServiceConsumer {
  void run(Service s);
}

class Service {

   private Service() { ... }      // now: private
   private void release() { ... } // now: private
   public void doWork() { ... }   // unchanged

   public static void runWithRelease(ServiceConsumer consumer) {
      Service s = new Service();
      try {
        consumer.run(s);
      }
      finally {
        s.release();
      } 
    } 
  }

Caveats:

• Consider this pseudocode, it has been ages since I've written Java.
• There might be more elegant variants around these days, maybe including that AutoCloseable interface someone mentioned; but the given example should work out of the box, and except for elegantness (which is a nice goal in itself) there should be no major reason to change it. Note that this intends to say that you could use AutoCloseable inside your private implementation; the benefit of my solution over having your users use AutoCloseable is that it can, again, not be forgotten.
• You'll have to flesh it out as needed, for example to inject arguments into the new Service call.
• As mentioned in the comments, the question of whether a construct like this (i.e., taking the process of creating and destroying a Service) belongs in the hand of the caller or not is outside of the scope of this answer. But if you decide that you absolutely need this, this is how you can do it.
• One commenter provided this information regarding exception handling: Google Books

Answer 3

The pragmatic solution is to make the class AutoCloseable, and provide a finalize() method as a backstop (if appropriate ... see below!). Then you rely on users of your class to use try-with-resource or call close() explicitly.

Of course I can document that, but I want to force them.

Unfortunately, there is no way¹ in Java to force the programmer to do the right thing. The best you could hope to do is to pick up incorrect usage in a static code analyser.

---

On the topic of finalizers. This Java feature has very few good use cases. If you rely on finalizers to tidy up, you run into the problem that it can take a very long time for the tidy-up to happen. The finalizer will only be run after the GC decides that the object is no longer reachable. That may not happen until the JVM does a full collection.

Thus, if the problem you are tying to solve is to reclaim resources that need to be released early, then you have missed the boat by using finalization.

And just in case you haven't got what I am saying above ... it is almost never appropriate to use finalizers in production code, and you should never rely on them!

---

^{1 - There are ways. If you are prepared to "hide" the service objects from user code or tightly control their lifecycle (e.g. https://softwareengineering.stackexchange.com/a/345100/172) then the users code doesn't need to call release(). However, the API becomes more complicated, restricted ... and "ugly" IMO. Also, this is not forcing the programmer to do the right thing. It is removing the programmer's ability to do the wrong thing!}

Answer 4

You could try to make use of the Command pattern.

class MyServiceManager {

    public void execute(MyServiceTask tasks...) {
        // set up everyting
        MyService service = this.acquireService();
        // execute the submitted tasks
        foreach (Task task : tasks)
            task.executeWith(service);
        // cleanup yourself
        service.releaseResources();
    }

}

This gives you full control over resource acquisition and release. The caller only submits tasks to your Service, and you yourself are responsible for acquiring and cleaning up resources.

There is a catch, however. The caller can still do this:

MyServiceTask t1 = // some task
manager.execute(t1);
MyServiceTask t2 = // some task
manager.execute(t2);

But you can adress this problem when it arisis. When there are performance problems and you find out that some caller do this, simply show them the proper way and resolve the issue:

MyServiceTask t1 = // some task
MyServiceTask t2 = // some task
manager.execute(t1, t2);

You can make this arbitrarly complex by implementing promises for tasks that are dependent on other tasks, but then releasing stuff also gets more complicated. This is only a starting point.

Async

As has been pointed out in the comments, the above doesn't really work with asynchronous requests. Thats correct. But this can easily be solved in Java 8 with the use of CompleteableFuture, especially CompleteableFuture#supplyAsync to create the individual futures and CompleteableFuture#allOf to perfom the release of the resources once all tasks have finished. Alternatively, one can always use Threads or ExecutorServices to roll their own implementation of Futures/Promises.

Answer 5

If you can, do not allow the user to create the resource. Let the user pass a visitor object to your method, which will create the resource, pass it to the visitor object's method, and release afterwards.

Answer 6

My idea was similar to Polygnome's.

You can have the "do_something()" methods in your class just add commands to a private command list. Then, have a "commit()" method that actually does the work, and calls "release()".

So, if the user never calls commit(), the work is never done. If they do, the resources are freed.

public class Foo
{
  private ArrayList<ICommand> _commands;

  public Foo doSomething(int arg) { _commands.Add(new DoSomethingCommand(arg)); return this; }
  public Foo doSomethingElse() { _commands.Add(new DoSomethingElseCommand()); return this; }

  public void commit() { 
     for(ICommand c : _commands) c.doWork();
     release();
     _commands.clear();
  }

}

You can then use it like foo.doSomething.doSomethineElse().commit();

Answer 7

The suggestion of extending AutoCloseable is good, but it makes no guarantee. It relies on developers to always use the try-with-resources statement. It also assumes that using try-with-resources is possible, which it is not when one method creates a resource and another method disposes of it.

An alternative is to use the Resource Leak Checker of the Checker Framework. A programmer runs the checker at compile time. If it issues no warnings, then the code is guaranteed to call the given method. The Resource Leak Checker can be used with or without the AutoCloseable-and-try-with-resources pattern. The Resource Leak Checker works out of the box with the Closeable type, but you can guarantee the calling of any method, not just close(). The Resource Leak Checker is used on Apache Cassandra and at Microsoft, Oracle, Uber, etc.

Of course, if a client programmer doesn't run the Resource Leak Checker (as a javac plugin) at compile time, then you still have no guarantee.

Answer 8

Another alternative to the ones mentioned would be the usage of "smart references" to manage your encapsulated resources in a way which enables the garbage collector to automatically clean up without manually freeing resources. Their usefulness depends of course on your implementation. Read more on this topic in this wonderful blog post: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

Answer 9

For any other Class Oriented language I'd say put it in the destructor, but since that's not an option I think you can override the finalize method. That way when the instance goes out of scope and is garbage collected it will be released.

@Override
public void finalize() {
    this.release();
}

I'm not too familiar with Java, but I think that this is the purpose for which finalize() is intended.

http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#finalize()