Consider generalizing Lazy behavior around closing resources #1363

Open
adriancole opened this Issue Oct 27, 2016 · 1 comment

Projects

None yet

1 participant

@adriancole
Contributor

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

@adriancole
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment