Box Old Objects to Be Autoclosable

Since Java 7, we can use try-with-resources and have any object automatically closed that implements the Autocloseable interface. If the resource is Autocloseable, some of the classes need some wrap-up but are not Autocloseable. These are mainly old classes in some legacy framework that still get in our way to make us trip up. Nobody is using Struts any more, but still, there are enough old frameworks that are lurking in the dark and with which we have to live. I recently had that experience and I was so motivated that I created a simple AutoCloser class.

We may have a legacy class (in the example, this is a mocking inner class of the testing class)

public class NotAutoclosable {
    public NotAutoclosable() {
        opened = true;
    }

    public void dispose() {
        opened = false;
    }
}

Which is not auto-closeable as the name also implies. It does not implement the Autocloseableinterface and it does not have a close() method. It has to be disposed of by calling the aptly named method dispose(). (The boolean field opened is used to check later in the unit test to assert the correct functioning of the AutoCloser class.)

The use of the class looks as follows:

@Test
void test() {
    final NotAutoclosable notAu;
    try (final var s = AutoCloser.useResource(new NotAutoclosable())
            .closeWith(sp -> sp.get().dispose())) {
        Assertions.assertTrue(opened);
    }
    Assertions.assertFalse(opened);
}

We create the resource using the constructor of the inner class, and we also define a Consumerthat will “close” the resource. This consumer will get the same Supplier that is stored in the variable s.

Side note: This functional argument has to be a consumer and cannot be a Runnable using the variable s because that variable is not initialized when the lambda expression is evaluated as a lambda expression. When it is going to be used, it will already be defined but that is too late for the Java compiler; it does not trust the programmer that much, and usually, it does it with good reason.

The AutoCloser class is the following:

public class AutoCloser<T> {

    private final T resource;

    private AutoCloser(T resource) {
        this.resource = resource;
    }

    public static <T> AutoCloser<T> useResource(T resource) {
        return new AutoCloser<>(resource);
    }

    public AutoClosableSupplier closeWith(Consumer<Supplier<T>> closer){
        return new AutoClosableSupplier(closer);
    }

    public class AutoClosableSupplier implements Supplier<T>, AutoCloseable {
        private final Consumer<Supplier<T>> closer;

        private AutoClosableSupplier(Consumer<Supplier<T>> closer) {
            this.closer = closer;
        }

        @Override
        public T get() {
            return resource;
        }

        @Override
        public void close() {
            closer.accept(this);
        }

    }
}

The inner AutoClosableSupplier class is used because we do not want the programmer accidentally forget to specify the lambda that will finally close the resource.

This is nothing really serious. It is just a programming style that moves the closing of the resource close to the opening of the resource a bit like the deferred statement in the Go language.