Feedback and comments on ARM proposal

Mark Mahieu markmahieu at
Tue Mar 10 13:50:33 PDT 2009

On 10 Mar 2009, at 16:33, Tim Peierls wrote:
> On Tue, Mar 10, 2009 at 12:18 PM, Neal Gafter <neal at> wrote:
>> On Tue, Mar 10, 2009 at 8:36 AM, Tim Peierls <tim at> wrote:
>>> the coin-dev list has yet to
>>> 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
> it'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.

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()) {
		// 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()) {
		// 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.

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()) {
		// etc

Muted applause all around.

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)) {
		// etc

Which is exactly what we'd want, I think.

It's just a thought, but does that sound vaguely workable, or have I  
drunk too much coffee again?


More information about the coin-dev mailing list