Simple Resource Clean-up
neal at gafter.com
Tue Mar 3 10:47:31 PST 2009
This would be the first instance of an annotation that changes the
meaning of the language's primitive constructs. Today, this kind of
thing is the role of declaration modifiers. We went to great length
to discourage this kind of use of annotations in the past; annotations
are to annotate the program text (in a way sometimes visible to
libraries), not define it. I understand the reluctance to add new
keywords to the language, but I advise against adding annotations as
language modifiers (essentially, adding modifiers with an "@" prefix).
The fact that this kind of flexibility is required suggests the
facility should be provided by libraries rather than hardcoded into
On Tue, Mar 3, 2009 at 10:03 AM, Joshua Bloch <jjb at google.com> wrote:
>> The specification requires that the object in the try () block have a
>> "close()" method. Wether the method throws any or no exception, or if it
>> returns a value or no value does not matter.
> This is a "naming pattern" (of the sort used by serialization and beans).
> If we need more flexibility than interfaces provide, I believe that we're
> better off going all the way to annotations (see Item 35 in Effective Java,
> Second Ed.). This would allow us to use the automatic resource management
> statement with types whose "dispose" method wasn't named close (such as
> java.awt.graphics.dispose). This is listed as a "design alternative" at the
> bottom of my proposal.
> Here's how I summarize the pros and cons: "[Use of an annotation] allows the
> use of a different method names (such as destroy and terminate) and eases
> the use of the new construct with existing resource types. But it is more
> “magical” and does not mesh as well with Java’s type system." I do see this
> as a viable alternative, but with pros and cons. I believe it would be
> relatively straightforward to retrofit my proposal to use method annotations
> instead of (or in addition to) an interface.
More information about the coin-dev