MayHoldCloseableResource vs AutoCloseable

[Zhong Yu]

On Mon, Jul 8, 2013 at 11:20 AM, Paul Benedict <pbenedict at apache.org> wrote:
> 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> { ... }

Interesting use of annotation to turn on/off contracts of interfaces.
If it's not a sin to monkey patch type systems with annotations, we
might as well use annotation to implement intersection type

    @And(Closeable.class)
    Stream<Path> listFiles(dir)

the static analyzer understands that the returned object is a
Closeable too, so it must be closed.

Zhong Yu


>
> 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)?
>>
>>
>