Proposal: Automatic Resource Management (original) (raw)

Bob Lee crazybob at crazybob.org
Tue Mar 3 21:53:38 PST 2009

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

More information about the coin-dev mailing list