Proposal: Automatic Resource Management

[Mohamed M. El-Beltagy]

I've read as much as I can of the ARM proposal and related emails. I'm not sure that I read it all, I tried to read all.
>From what I read and what I have in mind, I think I might be rolling back some ideas that kept on going in the different discussions. So, please, bare with me.

The proposal I have is a little combined of what you have suggested, but changed a little bit and yet, I tried to make it, simple.
We would have two special interfaces similar to the Serializable interface. The two interfaces would be in any package (no need for special package).
The interfaces would be, as suggested, AutoClosable and AutoDisposable. But with the following implementations:
public interface AutoClosable {
    public void autoClose() throws Exception;
}

public interface AutoDisposable{
    public void autoDispose() throws Exception;
}

and the platform would pay attention to the marker interfaces and call the appropriate method.

It would be the responsibility of the implementing classes to implement the method with internal call to the original close method.
For example:
Implementation of a FileWriter is:
public class FileWriter implements AutoXXXX {
    public void autoXXXX() throws Exception {
        close();
    }
    // existing class code
}

In regards to the scope of the ARM and declaration of the resource to be managed, it would be the same as the variable scope that references the object. i.e, whenever the object is eligible for garbage collector, it would auto close or dispose the object before collecting it. (same as finalize method).
Or as another suggestion to the matter, the compiler would be responsible for deciding when to insert the call of the autoXXXX method in the generated classes. (but I guess this solution would not be fully backward compatible with previously compiled classes on new JRE).

In regards to whether or not an implementing class can implement two interfaces, we could have two options:
Option 1: 
       It would be the responsibility of the implementing class to secure the internal state of itself. Meaning: it would check if it's already closed or disposed or not before invoking the original close/dispose method. Advantage: the user of the class could have successfully closed the object before it's auto closed using the existing way of closing connections and files. So, no need to auto close it as it is already closed. Disadvantage: things will be, again, implementation specific which gives the developer the chance of miss handling the resource's state.

Option 2:
       The compiler would give a higher priority to one of the two marker interfaces. Disadvantage: implementation still needs to handle the internal state of the itself (is it closed already or not).


Overall benefits: 
    1. No language changes are required at all. With this proposal, we could even apply it to Java SE prior to Java 5, if we would like to.
    2. Fully backward compatibility.
    3. It overcomes the shortcoming of the updated proposal (http://docs.google.com/Doc?id=ddv8ts74_0vnstdfdh) that the implementation class can decide which exception to be thrown out of the autoClose/autoDispose and which to be ignored.
    4. It eliminates the need for special handling in for-loop as it could be applied to any class (normal resources like streams, or any special collection that needs to be closed or disposed). The for-loop has nothing to do with close/dispose of an object. It's purpose is for iteration. So we would not mix the responsibilities of the code and thus, the code is doing what it's intended to do as well as keeping backward compatibility with existing code.
        One of the cases I read in the discussions was what if there is a collection of disposable items. In this case, when the scope of the collection is over, the items contained inside are over, and thus, eligible for closing/disposal. So, again, the runtime would be able to call the autoClose/autoDispose methods.
    5. No need for new language keywords.
    6. No usage of annotations.
    7. The existing resources implementations could be added gradually to the list of supported resources by the ARM, they don't have to be all released in Java 7.0. Only support for ARM with the new two interfaces is required. i.e., changing class FileWriter  in the API to support ARM does not have to be in Java 7.0, it could be added later in a minor update.
    8. One of the things I really find interesting, is that we can even start with one special interface to the ARM feature (AutoClosable, to be specific) and we can add other special interfaces later on as required (AutoDisposable, AutoOpenable, etc.). This way, the ARM feature itself would be expandable and yet controllable by the platform).

Disadvantages:
    1. For each implementing class, we will need to change the current implementation to add the following:
        a) Add the implements AutoXXXX declaration.
        b) Implement the new method autoXXXX.
        c) Check the internal state of the class before closing. (the most annoying thing).
    2. I really have no clue about the amount of work required in the compiler/run-time to support this feature. But if we are considering ARM in all cases, I guess this would be the minimal changes required.

I really hope that you find my contribution in the ARM topic worth it and I certainly hope that I didn't waste anyone's time.