Brian, you wrote: "It would be utterly criminal if someone were to
restructure the above code into the below code because some IDE inspection
complained about
"must call close or use TWR."
I agree here. However, the inheritance of AutoCloseable is going to likely
prompt some kind of action by developers. While wrapping in TWR may be the
pedantic case (and hopefully the minority case), I think the majority
client code will be using @SuppressWarning("resource") because no one likes
to see warnings in their IDE.
I'm still a believer the best middle-ground solution is the use of
@HasResource that you created -- except bumped up to apply on all
AutoCloseable types. Rather than explain this, here's some code:
@Retention(RetentionPolicy.CLASS)
@Documented
@interface HoldsResource { boolean value() default true; }
// Added a new default value
@HoldsResource
public interface AutoCloseable { ... }
@HoldsResource(false)
public interface IntStream { ... }
By default, all uses of AutoCloseable types definitely hold a resource.
This is the expectation of today. Your work in the stream library has
brought forward the case this might not always be expected. I believe this
is a good progression.
Your annotation was designed with static analysis in mind. I just think
it's at the wrong level. This proposal makes MayHoldCloseableResource
irrelevant and disappear, the use of TWR with true-backed resource streams
good, and fix false leak detections for non-resource streams.
--
Cheers,
Paul
