Re: java.io.File
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.
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.
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.
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.
--
Lew