MayHoldCloseableResource vs AutoCloseable

[Paul Benedict]

I look towards the design of @Repeatable as a good metaphor for achieving
this feature. In that case, you have an annotation that has runtime
retention; it tells programmers and IDE/tools how to influence code
writing. The annotation becomes repeatable, but it doesn't have to be in
the source. You can ignore the repeating aspect and just write container
annotations, if you wish.

The same influencer option exists here. If you re-purpose @HoldsResource
with runtime retention for any AutoCloseable object, the programmer won't
be forced to close it -- unless an annotation attribute mandates it. The
mandate would require a boolean flag, perhaps.

Ex:
@HoldsResource(false)
public interface IntStream extends BaseStream<Integer, IntStream> { ... }

Is it better? It is to me .. and much more straightforward when reading
code. I don't know what you had in mind when you said "the obvious and
numerous challenges of annotations", so you may have to explain, if you
choose. However, I see this design better than introducing a superfluous
interface. Objects should just use AutoCloseable directly, provided the new
annotation controls leak resource warnings and the mandate to close it.


On Mon, Jul 8, 2013 at 10:32 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Thanks Brian. So I go back to my question. Why not just use the
>> annotation and dump the interface? If any AutoCloseable sub-interface is
>> annotated with @MayHoldResource, resource leak warnings and catching can
>> be disabled. The current sub-interface, imo, does not achieve anything.
>>
>
> Perhaps a better question is: why *would* we use annotations here?  Why do
> you think this is somehow "better" (especially given the obvious and
> numerous challenges of annotations)?
>
>