Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10535

Re: java.io.File

Show all headers | View raw

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' doesn't have
>> one.  'FileInputStream' doesn't have one.  None of their ancestor classes 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 'File' 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 'FileOutputStream', 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, not overt invocation of the 'close()' method.  The two are orthogonal.  An object can have a non-trivial 'finalize()' method and no 'close()' method, lack 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 resource release, but does require explicit coding.

In the case of a 'finalize()' that releases resources, you can allow resources to be released automatically, but you run the risk that they never will be.  Furthermore, such a 'finalize()' will increase memory pressure because 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 example 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 help you won't know why.  The problem with sitting on your ass and doing nothing is that you never do anything.  I recommend neither doing nothing nor doing something blindly in hopes that you break nothing.  Rather, do something intentional and tactical with an actual chance of being helpful.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-02 09:35 +0000
  Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 07:25 -0800
    Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-02 15:55 +0000
      Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 08:17 -0800
        Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-02 16:31 +0000
          Re: java.io.File markspace <-@.> - 2011-12-02 08:53 -0800
          Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 14:02 -0800
            Re: java.io.File Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 17:12 -0500
              Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 14:16 -0800
                Re: java.io.File Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 18:42 -0500
                Re: java.io.File Lars Enderin <lars.enderin@telia.com> - 2011-12-03 01:06 +0100
                Re: java.io.File Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-12-07 15:51 +0200
            Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-05 15:14 +0000
              Re: java.io.File markspace <-@.> - 2011-12-05 07:49 -0800
                Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-05 16:28 +0000
              Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-05 15:25 -0800
                Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-06 10:29 +0000
          Re: java.io.File Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 17:08 -0500
      Re: java.io.File Roedy Green <see_website@mindprod.com.invalid> - 2011-12-03 00:57 -0800
    Re: java.io.File Mayeul <mayeul.marguet@free.fr> - 2011-12-02 17:33 +0100
      Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 14:07 -0800
        Re: java.io.File Mayeul <mayeul.marguet@free.fr> - 2011-12-06 15:52 +0100
          Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-06 09:23 -0800

csiph-web