Feedback and comments on ARM proposal

[Joshua Bloch]

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