MayHoldCloseableResource vs AutoCloseable

[Zhong Yu]

The question is marker interface vs marker annotation. Which is better,

    class Foo implements Serializable

or

    @Serializable
    class Foo

? I'm leaning towards marker interface whenever possible.

Zhong Yu


On Mon, Jul 8, 2013 at 1:03 PM, Paul Benedict <pbenedict at apache.org> wrote:
> My mistake, Zhong. I wrote that too fast. The annotation already has CLASS
> retention policy so it's available for tooling. Since that's all the
> information necessary to make the decision whether a programmer can
> opt-out/mandate closing the resource, the MayHoldCloseableResource interface
> is not necessary under any context. Both humans and tools just require the
> annotation.
>
>
> On Mon, Jul 8, 2013 at 12:54 PM, Paul Benedict <pbenedict at apache.org> wrote:
>>
>> Zhoung, my proposal dfoesn't turn on/off the contract. The stream would
>> still be auto-closed in a try-with-resources construct. All I am saying is
>> retain the hint at runtime whether or not the stream actually has a resource
>> to close. That's information that shouldn't be discarded; it can definitely
>> help the clients who have smart tooling/IDE to read that metadata.
>>
>>
>> On Mon, Jul 8, 2013 at 12:21 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>
>>> 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)?
>>> >>
>>> >>
>>> >
>>
>>
>