Proposal: Automatic Resource Management
Jeremy Manson
jeremy.manson at gmail.com
Wed Mar 4 00:25:52 PST 2009
Although this is clear from the proposal, intentions and uses have a
way of diverging. As you know, the usage I showed is very similar to
C++'s RAII idiom, a very similar abuse of constructors and destructors
that uses similar ridiculous wrapper classes.
Jeremy
On Wed, Mar 4, 2009 at 12:12 AM, Joshua Bloch <jjb at google.com> wrote:
> A gentle reminder: this construct was designed for one thing and one thing
> only: resource management. It was not designed for locking. Java already
> contains a native construct for locking (synchronized). A very small
> minority of Java programmers use java.util.concurrent.atomic.Locks. Support
> for them is not a priority. Nearly all Java programmers use resources such
> as java.io.InputStream, OutputStream, Reader, Writer, Formatter; java.nio.Channel; java.net.socket; java.sql.Connection, Statement, ResultSet,
> or java.awt.Graphics. That's what this construct is designed for.
> Goodnight,
> Josh
> On Wed, Mar 4, 2009 at 12:03 AM, Jeremy Manson <jeremy.manson at gmail.com>
> wrote:
>>
>> On Tue, Mar 3, 2009 at 11:56 PM, Neal Gafter <neal at gafter.com> wrote:
>> > On Tue, Mar 3, 2009 at 11:49 PM, Jeremy Manson <jeremy.manson at gmail.com>
>> > wrote:
>> >> As a side note to this conversation, directed at any people who will
>> >> think you can't have this feature with this proposal, regardless of
>> >> your feelings about the particular merits of accomplishing the same
>> >> thing with closures, there *is* a way to handle this case:
>> >>
>> >> try (LockDisposer l = new LockDisposer(lock.readLock())) {
>> >> clientCount++;
>> >> }
>> >>
>> >> try (LockDisposer l = new LockDisposer(lock.writeLock())) {
>> >> return field.getValue();
>> >> }
>> >
>> > Yow. I think the cure might be worse than the disease.
>>
>> That's why I suggested changing try() so that it took an expression.
>> The second version was, I think you will admit, much cleaner.
>>
>> >> I suspect a LOT of people will be doing something similar to this hack
>> >> if this proposal is adopted. To make it much cleaner, you could first
>> >> adjust this proposal so that the try statement can take an expression
>> >> that returns a Disposable, and then you could adjust the Lock classes
>> >> so that a) lock() returns this and b) they implement Disposable, at
>> >> which point you could have:
>> >
>> > You can't make such changes to existing interfaces without breaking
>> > existing code. Changing the signature of lock() breaks existing
>> > callers, and adding a close() method (to implement Disposable) breaks
>> > existing implementations.
>>
>> I'm probably being typically dumb, but I'm not sure how adding a
>> method breaks anything. You don't *have* to change the signature of
>> lock -- just add a new method (call it "disposeLock") that has the
>> required semantics:
>>
>> try (lock.readLock().disposeLock()) {
>> clientCount++;
>> }
>>
>> try (lock.writeLock().disposeLock()) {
>> return field.getValue();
>> }
>>
>> Jeremy
>>
>
>
More information about the coin-dev
mailing list