Proposal: Automatic Resource Management

[Bob Lee]

On Tue, Mar 3, 2009 at 9:00 PM, Neal Gafter <neal at gafter.com> wrote:

> See
> http://www.two-sdg.demon.co.uk/curbralan/papers/AnotherTaleOfTwoPatterns.pdf
> for a discussion of the pattern.


It's interesting to note that the author (a supposed expert) doesn't close
resources properly, i.e. he lets exceptions from close() eat earlier, likely
more informative exceptions. He would definitely benefit from this feature.

With closures in the language, you'd
> get the possibility of more flexible resource management than is
> provided by this proposal.


I wouldn't mind having closures one day, but based on the current state of
the BGGA proposal, I think I'd like to have Automatic Resource Management
either way, preferably sooner rather than later. To help illustrate, can you
please show us what this snippet would look like using BGGA closures?

  try (InputStream in = new FileInputStream(src);
      OutputStream out = new FileOutputStream(dest)) {
    byte[] buf = new byte[8 * 1024];
    int n;
    while ((n = in.read(buf)) >= 0)
      out.write(buf, 0, n);
  } catch (IOException e) {
    showDialog("Copy failed.");
  }

For example, you could write APIs to
> provide convenient support for the use of
> java.util.concurrent.locks.Lock,
> java.util.concurrent.locks.ReadWriteLock
>

I'm not too worried about locks. They're significantly simpler than closing
I/O resources in that you don't have to worry about unlock() throwing and
you don't have to nest the try blocks. Unlike closing I/O resources, most
people get locks right (if they use them at all).


> , transactions that can either
> be committed or rolled back, etc, without requiring the language
> commit itself to a single pattern.


The current proposal supports existing transaction approaches just fine.
Either your API auto-commits (in which case you roll back if someone calls
setRollbackOnly() on the resource), or you have to explicitly commit:

  try (Transaction t = ...; TransactionalResource tr = ...) {
    // do some stuff w/ tr
    ...
    t.commit();
  }

If you don't commit(), the tx gets rolled back. Honestly though, I don't see
too many users leaving framework-based transaction solutions (like
@Transactional) behind for this or BGGA closures.

 Worse: a single pattern that we
> would have to get right in the next ~3 months.  These and other
> resource management patterns in use today simply don't fit into the
> mold of this proposal.  That is a warning sign that a language
> construct directly encoding the pattern is inappropriate.


I disagree. I think we know exactly how to close I/O resources already. The
only reason there is any debate today is because doing the right thing in
the absence of this feature is such a PITA. It's very difficult to do the
right thing today; in contrast, this feature makes it easier to do the right
thing than the wrong thing.

Bob