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.

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

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.

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.

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

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.

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