MayHoldCloseableResource vs AutoCloseable

[Paul Benedict]

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