MayHoldCloseableResource vs AutoCloseable

[Paul Benedict]

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