Consider generalizing Lazy behavior around closing resources

[codefromthecrypt]

from @autoletics in openzipkin/zipkin-reporter-java#24 (comment)

---

I see in a number of extension classes the same logic:

check whether close has been called before
check whether the object (delegate) has been previously created
if so then close/shutdown the object (delegate / contained)
Would it not be better to have the Lazy* super class not already ensure this itself. The close method being final (not in terms of signature because that would break the api) and only being executed once at least in terms of what extensions would see via a hook method(s) for when close must be performed.

close() -> onClose(T)

or

close() -> close(T)

after checking that the reference (T) was not null and that close() was not already previously dispatched

[codefromthecrypt]

one thing this implies is cutting in two-steps, ex fixing here, releasing, then fixing elsewhere. Alternatively, we could make the lazy type not internal, and just design the new one like that.

Note: another option is to generate the lazy closable by an auto-value extension. For example, the latest auto-value includes a lazy generator. This would allow us to not have to share libraries to get behavior like this. https://github.com/google/auto/tree/master/value/src/main/java/com/google/auto/value/extension/memoized

[jorgheymans]

Is generalizing the Lazy behaviour still going to happen or are we going to be lazy about it and let it be ? Lazy consensus applies, if i don't hear back in a couple of weeks i'm closing this.

[codefromthecrypt]

I don't think we need to make more library coupling by adding a super-type for lazy here.

Consider brave has recently removed the zipkin dep, if anything this could probably be punted to the libraries themselves, or left as-is.