Automatic Resource Management and Simple Resource Clean-up

[Neal Gafter]

Thorsten-

I think you're on the right track when you suggest the resource
management library to encapsulate the implementation of proper
resource management.  A library solution could be flexible enough to
handle the more complex cases like transactions too.

Regards,
Neal

On Tue, Mar 3, 2009 at 1:18 PM, Thorsten van Ellen <thorsten at vanellen.de> wrote:
> Josh, Neal and Roger!
>
> I have had this idea also for a long time. I think it is in a "tradition" of
> java of suppressing typical programming errors. A good example for the tradition
> is automatic memory management and garbage collection that is a very complex
> mechanism to avoid one very typical programming error.
>
> Management of resources other than memory usually is really as buggy as memory
> management. My observation is that resource management is one of the most
> frequent bug pattern I know of. Look at any project: you hardly find correct
> optimal implemented examples and you nearly always find bugs in every non
> trivial project. Analysing/finding the bug often is very difficult like finding
> memory management bugs.
>
> It seems to me, the feature benefit is worth some more effort. The effort of
> thinking a bit more about it might be not too much, especially if your heading
> toward a "minimal" solution like "simple clean up", but I don't know what is
> "affordable" in jdk7-schedule.
>
> Just to put in some additional/new ideas and to "make the cake bigger" before it
> is reduced to the optimal solution ("brain-storming", sometimes thinkind around
> a corner helps):
>
> Both proposed solutions might have problems with resource management, that is
> distributed/shared/spread between two or more separated methods. Such problems
> might be solved with a kind of GOF-"pattern", interfaces and a tiny "resource
> management library".
>
> And there exist even more complicated resource management problems like ACID
> database transactions that do not only have one "close"-operation but two
> (commit and rollback) and a more complex decision process between those.
>
> But regarding these additional ideas may also be counterproductive for a tiny
> language modification that solves 98 % of the typical bugs and therefore may
> also be ignored!
>
> Best regards
>
> Thorsten van Ellen
>
>