Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Andreas Leitgeb Newsgroups: comp.lang.java.programmer Subject: Re: it's Closeable, but I don't want to close() it yet. Date: Thu, 28 Feb 2019 19:10:20 -0000 (UTC) Organization: A noiseless patient Spider Lines: 27 Message-ID: References: Reply-To: avl@logic.at Injection-Date: Thu, 28 Feb 2019 19:10:20 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="736217a967b4422be6275df234d15eb4"; logging-data="13831"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gwuYnDn1in5EPgoFIqtF6" User-Agent: slrn/1.0.3 (Linux) Cancel-Lock: sha1:bRLiXL/5q/6D9P313MxAbOhL40M= Xref: csiph.com comp.lang.java.programmer:38752 Marcel Mueller wrote: > Am 27.02.19 um 16:51 schrieb Andreas Leitgeb: >> In my application there exists an entity that is Closeable. >> It is kept in some class, and other parts of my application >> request a ref to the entity and do actions on it, then drop >> their ref, leaving the entity intact. >> >> Everything runs fine, except eclipse warns me about spots >> where the entity is requested, used, and then dropped. >> Eclipse thinks it might need to be close()d. > > It is best practice for connection pooling or other object sharing to > implement close() in a way that the object is put back for further use. > A corresponding factory returns this instance on later invocations > again. You will need however some point where the underlying object is > actually closed. This could be the end of a web request or even just a > timeout. I totally agree for a typical "Pool" scenario. My case can be better characterized in that the Closeable entity is an attribute of a Context class, and a getter is called by "users" for the ref of the entity. Lifetime management of the entity is handled by the Context. "Users" (specific methods doing their parts of the Context's whole task) really shouldn't close() it or they would spoil it for later users.