From mbien at fh-landshut.de  Mon Mar  1 08:48:41 2010
From: mbien at fh-landshut.de (Michael Bien)
Date: Mon, 01 Mar 2010 17:48:41 +0100
Subject: Is Disposable the only allowed interface for ARM blocks?
Message-ID: <4B8BEFE9.1040306@fh-landshut.de>

Hello,

Disposable.close() is intuitive if applied on streams but not necessary 
in other situations. It would be nice to have other synonyms like e.g 
dispose() or release(). I think there was an discussion about allowing 
more interfaces on this list but it seems the ARM proposal only suggests 
Disposable with close().
Is this final?

-- 
Michael Bien
http://michael-bien.com/



From neal at gafter.com  Mon Mar  1 08:57:03 2010
From: neal at gafter.com (Neal Gafter)
Date: Mon, 1 Mar 2010 08:57:03 -0800
Subject: Is Disposable the only allowed interface for ARM blocks?
In-Reply-To: <4B8BEFE9.1040306@fh-landshut.de>
References: <4B8BEFE9.1040306@fh-landshut.de>
Message-ID: <15e8b9d21003010857w134eaebcr7cbffd0f70febac6@mail.gmail.com>

Michael-

Extension methods may provide a completely different approach that one
can use to get a more flexible specification for ARM, including
support for different method names, but it may be some weeks before
project lambda has that in its draft specification for us to build on.

Cheers,
Neal

On Mon, Mar 1, 2010 at 8:48 AM, Michael Bien <mbien at fh-landshut.de> wrote:
> Hello,
>
> Disposable.close() is intuitive if applied on streams but not necessary
> in other situations. It would be nice to have other synonyms like e.g
> dispose() or release(). I think there was an discussion about allowing
> more interfaces on this list but it seems the ARM proposal only suggests
> Disposable with close().
> Is this final?
>
> --
> Michael Bien
> http://michael-bien.com/
>
>
>


From jjb at google.com  Mon Mar  1 10:13:03 2010
From: jjb at google.com (Joshua Bloch)
Date: Mon, 1 Mar 2010 10:13:03 -0800
Subject: Is Disposable the only allowed interface for ARM blocks?
In-Reply-To: <4B8BEFE9.1040306@fh-landshut.de>
References: <4B8BEFE9.1040306@fh-landshut.de>
Message-ID: <17b2302a1003011013o59bbab76sf827dc1039b2406c@mail.gmail.com>

Micahel,

On Mon, Mar 1, 2010 at 8:48 AM, Michael Bien <mbien at fh-landshut.de> wrote:

> Hello,
>
> Disposable.close() is intuitive if applied on streams but not necessary
> in other situations. It would be nice to have other synonyms like e.g
> dispose() or release(). I think there was an discussion about allowing
> more interfaces on this list but it seems the ARM proposal only suggests
> Disposable with close().
> Is this final?


Final is a strong word, but it is the plan of record (and what we
implemented).

        Josh


From melbeltagy at yahoo.com  Mon Mar  1 02:15:36 2010
From: melbeltagy at yahoo.com (Mohamed M. El-Beltagy)
Date: Mon, 1 Mar 2010 02:15:36 -0800 (PST)
Subject: Proposal: Automatic Resource Management
Message-ID: <132201.63614.qm@web30501.mail.mud.yahoo.com>

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.


      

From reinier at zwitserloot.com  Mon Mar  1 12:47:11 2010
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Mon, 1 Mar 2010 21:47:11 +0100
Subject: Proposal: Automatic Resource Management
In-Reply-To: <132201.63614.qm@web30501.mail.mud.yahoo.com>
References: <132201.63614.qm@web30501.mail.mud.yahoo.com>
Message-ID: <560fb5ed1003011247wd91c049id3e2c28ad4cefa5e@mail.gmail.com>

This won't work very well.

We already _HAVE_ finalize(), and could be used for this. The reason
finalize() isn't used for ARM is because the concept of finalization is
extremely complicated. Basically, objects may live for hours after they
become eligible for finalization; if not much in the JVM is requiring new
heap memory then gc may not happen for a long time. However, keeping OS
resources (such as files and sockets, or DB connectors) open has a
significant cost associated with it, *and* close often finalizes a
transaction of some sort (e.g. a close() on a file will flush any buffers,
on a zip stream it'll write the zip descriptor, it'll send the close
connection packets for TCP/IP sockets, and it'll commit or rollback an open
transaction for a DB connector). It is therefore important that the point at
which a resource is closed is carefully managed and happens at a very
precise moment. Not 'sometime later. Possibly hours later'.

Perhaps you meant that an AutoClosable/Disposable object should get its
autoClose()/dispose() method called *IMMEDIATELY* when it becomes eligible
for garbage collection. However, that's not how the JVM works. It does
*not*, after every instruction, check if some object reference has now
become eligible and mark it for the next sweep of the GC to clean it up. So,
if this was your idea, then it is not practically implementable - at least,
there is no obvious way to do it, and you haven't given us any idea about
how to go about updating the JVM to make this possible.

Lastly, such a change is JVM based and such changes are usually too tricky
and have too much impact to fit within the mission of Project Coin.

--Reinier Zwitserloot



On Mon, Mar 1, 2010 at 11:15 AM, Mohamed M. El-Beltagy <melbeltagy at yahoo.com
> wrote:

> 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.
>
>
>
>
>


From mbien at fh-landshut.de  Mon Mar  1 19:54:17 2010
From: mbien at fh-landshut.de (Michael Bien)
Date: Tue, 02 Mar 2010 04:54:17 +0100
Subject: Is Disposable the only allowed interface for ARM blocks?
In-Reply-To: <15e8b9d21003010857w134eaebcr7cbffd0f70febac6@mail.gmail.com>
References: <4B8BEFE9.1040306@fh-landshut.de>
	<15e8b9d21003010857w134eaebcr7cbffd0f70febac6@mail.gmail.com>
Message-ID: <4B8C8BE9.3060803@fh-landshut.de>

Neal, Josh,

thank you both for the rapid answer.
I already thought about extension methods and looked at the current 
lambda proposal but couldn't figure out how they would help in the 
situation (without strange idioms like doing a static import in client 
code to be able to call release() instead of close()).

Its probably best to stay with my own Releasable interface (in a public 
api) and check again later if it could be made ARM forward compatible 
afterwards.

best regards,
michael


On 03/01/2010 05:57 PM, Neal Gafter wrote:
> Michael-
>
> Extension methods may provide a completely different approach that one
> can use to get a more flexible specification for ARM, including
> support for different method names, but it may be some weeks before
> project lambda has that in its draft specification for us to build on.
>
> Cheers,
> Neal
>
> On Mon, Mar 1, 2010 at 8:48 AM, Michael Bien<mbien at fh-landshut.de>  wrote:
>    
>> Hello,
>>
>> Disposable.close() is intuitive if applied on streams but not necessary
>> in other situations. It would be nice to have other synonyms like e.g
>> dispose() or release(). I think there was an discussion about allowing
>> more interfaces on this list but it seems the ARM proposal only suggests
>> Disposable with close().
>> Is this final?
>>
>> --
>> Michael Bien
>> http://michael-bien.com/
>>
>>
>>
>>      
>
>    


-- 
Michael Bien
http://michael-bien.com/