Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: java.io.File Date: Mon, 5 Dec 2011 15:25:01 -0800 (PST) Organization: http://groups.google.com Lines: 86 Message-ID: <2342549.94.1323127501640.JavaMail.geo-discussion-forums@prgt1> References: <1754083.312.1322839502470.JavaMail.geo-discussion-forums@prjr26> <5ushd716i6g4qncg620f49ancol20af51f@4ax.com> <20850741.465.1322842636010.JavaMail.geo-discussion-forums@prnu18> <4puhd7h1qgr5rq3cgeebmrt64cc7qfn004@4ax.com> <32687452.648.1322863326052.JavaMail.geo-discussion-forums@prjr26> <8fnpd79eq3grdv0vb4vul24vq5j49os748@4ax.com> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 2620:0:1000:167c:224:d7ff:fe69:5838 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1323127501 1360 127.0.0.1 (5 Dec 2011 23:25:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 5 Dec 2011 23:25:01 +0000 (UTC) In-Reply-To: <8fnpd79eq3grdv0vb4vul24vq5j49os748@4ax.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2620:0:1000:167c:224:d7ff:fe69:5838; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10535 Mark wrote: >Lew wrote: >> Mark wrote: >>> AFAIK many classes have a close() method to allow any underlying OS >>> resources to be explicitly freed without needing to wait for the >>> dispose() method to do this. If the File method does uses file >> >> What 'dispose()' method? 'File' doesn't have one. 'FileOutputStream' d= oesn't have >> one. 'FileInputStream' doesn't have one. None of their ancestor classe= s up through >> 'Object' has one. >> >>> descriptors then we may assume that these could be left open until the >>> object is destroyed during GC. >> >> No, we cannot assume any such thing, nor can we even assume any given 'F= ile' instance, >> or any other class instance, will be collected ever. >=20 > Unless the Java class has been badly written we can assume that > when/if the object is collected then any OS resources that it used > would also be freed. Would you agree with this? Certainly not. You cannot assume any such thing. If an object has a 'finalize()' method that does such things, then it will = be documented and there will be certain knowledge, not assumptions. > We also see that File does not have a close(), dispose() or similar > method. Therefore, if the object does use any OS resources, there is > no way for the programmer to force them to be released. We have already seen that 'File' does use OS resources. >> 'FileInputStream', but not all 'InputStream' types, and 'FileOutputStrea= m', but >> not all 'OutputStream' types, do have a 'finalize()' method that might, = eventually, >> release file resources assuming the instances go through two GC cycles, = but there's >> no assurance that that will happen. >=20 > Which, presumably, they have close() methods defined. Apples and oranges. I was addressing the question of automatic closure, no= t overt invocation of the 'close()' method. The two are orthogonal. An ob= ject can have a non-trivial 'finalize()' method and no 'close()' method, la= ck override of 'finalize()' but have a 'close()', both override 'finalize()= ' and have 'close()', or neither. In the case of an overt 'close()', the 'try...finally' idiom can assure res= ource release, but does require explicit coding. In the case of a 'finalize()' that releases resources, you can allow resour= ces to be released automatically, but you run the risk that they never will= be. Furthermore, such a 'finalize()' will increase memory pressure becaus= e it delays or prevents garbage collection of objects with such an override= . ... [snip] ... > I have not rejected your advise, just explained why I had not yet > followed it. I realize this is not an ideal situation but I have > two choices: > 1. To try to do something even without adequate information. > 2. Sit on my ass an do nothing until such time as I get more > information. >=20 > I chose (1). It sounds like you prefer (2). I don't prefer either approach, nor have I recommended anything like either= one. I really have no idea how you reached that conclusion. What I did recommend is "3.", gather more information then act. It's an ex= ample of "Measure Twice, Cut Once". The problem with taking action without= any data is that the action is highly unlikely to help, and if it does hel= p you won't know why. The problem with sitting on your ass and doing nothi= ng is that you never do anything. I recommend neither doing nothing nor do= ing something blindly in hopes that you break nothing. Rather, do somethin= g intentional and tactical with an actual chance of being helpful. --=20 Lew