Feedback and comments on ARM proposal (original) (raw)

Joshua Bloch jjb at google.com
Tue Mar 10 14:51:39 PDT 2009

Hi Mark,

On Tue, Mar 10, 2009 at 1:50 PM, Mark Mahieu <markmahieu at googlemail.com>wrote:

>>> come up with an example where ARM support is both appropriate and >> difficult >>> to provide under the proposal. >> >> We identified a whole pile of them. java.awt.Graphics, >> org.eclipse.swt.graphic.Path, java.nio.channels.FileLock, >> org.ietf.jgss.GSSCredential, and java.awt.image.VolatileImage to pick >> a few. > > > Even if you think that all of these are appropriate, I don't > believe that t's difficult to provide adapters. > I've been trying to flesh this out with real examples of adapters, and have ended up following a strangely circular path... no modifiers this time (promise!), but I'm starting to wonder whether a two- interface solution might not be such a bad idea after all, only with a twist.

Tim is a bigger fan of adapters than I am (for this purpose). To the best of my recollection, 3 of the 5 types above could be retrofitted to implement AutomaticallyCloseable, and I think that's a better solution where it works.

Taking the SWT Resource class as an example, which cannot be retrofitted with AutoCloseable due to the clash with the Path resource's close() method, one might envisage a simple adaptation to look something like:

class Resource { public void dispose() { // existing SWT clean-up method } public AutoCloseable toAutoCloseable() { return new AutoClosable() { public void close() { dispose(); } }; } // etc } Which could then be used: Path path = new Path(display); try (AutoCloseable dummyVar = path.toAutoCloseable()) { path.whatever(); // etc } Apart from the awkwardness of having to declare the dummy AutoCloseable variable, this quickly shows itself to be overly simple, as soon as we add a second Resource: Path path = new Path(display); Color color = new Color(display, r, g, b); try (AutoCloseable dummyVar = path.toAutoCloseable(), dummyVar2 = color.toAutoCloseable()) { path.setForeground(color); // etc } Now we have the distinct possibility that the constructor invocation for 'color' will throw an exception, in which case 'path' will not be cleaned up. And we can't use ARM to help.

Yep:( You can get around the problem by nesting two automatic resource management statements, but it's a but verbose for my tastes:

  Path path = new Path(display);
   try (AutoCloseable dummyVar = path.toAutoCloseable()
       Color color = new Color(display, r, g, b);
        try (AutoCloseable dummyVar2 = color.toAutoCloseable()) {
           path.setForeground(color);
           // etc
        }
   }

We could extract interfaces for each of the Resource classes (IPath, IColor etc I'd imagine) and add toAutoCloseable() methods to each, which would return something that implements the appropriate interface + AutoCloseable. I can't imagine the SWT API designers being wildly enthusiastic about that, but the resulting value could be used with ARM:

try (AutoCloseablePath path = new Path(display).toAutoCloseable()) { path.whatever(); // etc } I agree: yuck.

But, what if there were an AutoCloseAdaptable interface, in addition to AutoCloseable:

interface AutoCloseAdaptable { AutoCloseable toAutoCloseable(); } If ARM recognised this interface, and called the toAutoCloseable() method behind the scenes (waves hands), Resource could be made to implement AutoCloseAdaptable very simply, and we could write this: try (Path path = new Path(display)) { path.whatever(); // etc } Which is exactly what we'd want, I think.

This is a possibility. It still doesn't work for interfaces, but I can't imagine a class for which it doesn't work. That said, I'm not sure I prefer it to a simple two-interface proposal (AutoCloseable + AutoDisposable). I suspect that this combination would enable retrofitting of nearly every class that could benefit from the facility. I understand that it's unsatisfying, but it's simpler than the AutoCloseAdaptable approach.

Thanks,

Josh

More information about the coin-dev mailing list