Proposal: Automatic Resource Management

[Joshua Bloch]

Neal,

On Fri, Feb 27, 2009 at 11:20 PM, Neal Gafter <neal at gafter.com> wrote:

> The proposed changes to existing APIs introduce an incompatibility.
> This, for example, is legal today:
>
> interface A extends java.sql.Connection, java.io.Closeable {}
>
> However, since you propose that Connection would extend
> Disposable<SqlException> and Closable would extend
> Disposable<IOException>, interface A is broken after the proposed
> change.  Also, the changes you propose to existing APIs introduce
> changes to overload resolution that can break existing code.



While this is technically an incompatibility, I don't think it's likely to
cause problems in practice. Look around and see if you can find any examples
to the contrary;  I am genuinely curious.  Keep in mind that adding a method
to any nonfinal type is technically incompatible in this way, and yet we do
it each release. As long as it's done tastefully, it isn't a problem.


>
> You also missed a few disadvantages.
>
> o All of the difficult decisions that you defer to the expert group,
> such as the handling of exceptions, suggest that this solution is
> likely to be a poor match for many uses, resulting in the sort of
> shoehorning of code into the construct that results in errors.


Whoa!  That is false, and mildly insulting.  I did not "defer the difficult
decisions to the expert group."  The proposal says precisely how exceptions
are to be handled: the first exceptions wins.  This is what people would do
today if weren't so difficult to code up.  Since your premise (that I have
deferred the hard decisions to the expert group) is wrong, your conclusion
(that "the  solution is likely to be a poor match for many uses, resulting
in the sort of shoehorning of code into the construct that results in
errors") is unwarranted.




>
> o This approach of adding point solutions one-by-one to a language for
> particular use cases results in a general degradation of the quality
> of the language over time with little lifting of the level of
> abstraction, so any change of this sort should be viewed with great
> skepticism.


This is not a "point solution."  It is a well established construct, much
used and loved in other languages including C# (the using statement) and
Python ( the with statement).  C++ programmers use destructors to similar
effect, and laud the resulting "RAII" pattern.


>
> o Given the short time frame that project coin is to complete its work
> and the nature of this solution -- attempting to maximize the utility
> in the most common use cases while minimizing the likelihood of user
> error in using the construct -- it seems unlikely that we will not
> have the time to experiment with all the variables in realistic
> contexts.


There are very few variables: this proposal is close to complete.  It solves
a simple, universal problem in a well-tested fashion.


>  Therefore, one should add to the disadvantages the very
> real chance that the language construct is likely to get some of these
> aspects wrong if added in the JDK7 timeframe.  The fact that these
> issues haven't been resolved in the 32+ months since you started
> working on this proposal, or in the 13+ months since a prototype has
> been available, suggests that 3-6 months is not a reasonable timeframe
> to resolve them, and even hints that there may be no generally
> acceptable solution.


I'm not quite sure what issues you mean.  A long while back (at OOPSLA
2004), I suggested that Java needed an automatic resource management
statement, but I did not work on the details.  Recently Joe Darcy announced
a call for proposals in connection with project Coin, so I worked on the
details.  It was, as I suspected, a relatively simple matter to put together
a solid proposal in a short period of time.  Talk of "hints that there may
be no generally acceptable solution" amounts to casting aspersions on the
proposal without noting any real shortcomings.



>
>
> You also forgot to mention the obvious alternatives.  Most
> prominently, control abstraction via closures (BGGA or JCA) allows API
> designers to tune the behavior for the various use cases (APIs)
> without the need for point-solution API-specific language changes.


I don't see this proposal as being related to closures in any way.  There
are languages with both closures and resource management (C#), neither (C),
automatic resource management only (C++), and closures only (Scheme).
 Whether or not Java gets something like BGGA or JCA in the
future, automatic resource management would be an extremely valuable
addition to the language in the next release.


>
> Generally, this proposal appears to leave too many open issues to be
> suitable for inclusion in the coin project/JSR.


But you haven't mentioned any!  So far as I know, this proposal is
comparable in its completeness to the other proposals that we've seen for
Project Coin.

           Regards,

           Josh