🚀 go-pugleaf

Thanks Benjamin for a comprehensive reply.

I guess I am used to an approach where I create an object, and then don't
have to worry about cleaning up because the object does all that itself.

As you said, a cleanup is usually required as a result of an error, or the
completion of some section of the application, and so it is possible to
explicitly call a close or cleanup method where required.

However, this requires a more structured design approach than I usually
adopt. So I guess I need to stop looking for an easy way to cleanup, and
instead go back and look at the problem I am trying to solve, and devise a
more structures solution.

Thanks
    DavidL

"Benjamin Johnston" <s355171@student.uq.edu.au> wrote in message
news:8s9jav$va1$1@bunyip.cc.uq.edu.au...
> > I probably need to be more precise with my questions, so they can't be
> > confused.
> >
> > I am aware of the finalize method, but, unfortunately, haven't seen it
> work.
>
> /snip/
>
> > then when that app runs I would expect the "finalize called" message to
be
> > displayed, but it doesn't happen.
> >
> > Maybe my JVM is broken ?
>
> Really, finalization isn't something you should be worrying about, its a
C++
> thing. In practice, you'll very rarely need to use finalize.
>
> Anyway, to explain;
>
> Firstly, say I've got a class;
>
> public class Test {
>      public void finalize() {
>           System.out.println("finalize called");
>      }
>
>      public static void main(String[] args) {
>           new Test();
>      }
> }
>
> (This is functionally eqivalent to the classes that you posted, only it
> takes up less screen space).
>
> Ok, what happens...
>
> 1. Java starts up, calls main.
> 2. main creates the new instance of Test, and then the Main method exits.
> 3. Java automatically shuts down when there are no live threads, so when
the
> only thread (Main) exits, the VM decides to shut down too.
>
> The VM shuts down. The VM doesn't finalize by default on shutdown. (There
is
> a brief explanation in the JavaDocs of why).
>
>
> So, how do we see the finalize method work?... two ways...
>
> Firstly, tell the VM to finalize every class before the VM shuts down;
>
> public class Test {
>      public void finalize() {
>           System.out.println("finalize called");
>      }
>
>      public static void main(String[] args) {
>           System.runFinalizersOnExit(true);
>           new Test();
>      }
> }
>
> After invoking System.runFinalizersOnExit(true); the VM will finalize
every
> object before shutting down. If the finalize methods do weird things, like
> start creating new Threads or invoking other objects, you'll probably run
> into problems. Anyway, the above code snippet prints "finalize called", as
> desired.
>
> runFinalizesOnExit is deprecated... you shouldn't really be doing it.
>
>
> The other way we can see finalize in action is by forcing the Garbage
> collector into action....
>
> public class Test {
>
>      private int[] memoryWaste = new int[1000];
>
>      public void finalize() {
>           System.out.println("finalize called");
>      }
>
>      public static void main(String[] args) {
>           while (true) {
>                new Test();
>                System.gc();
>           }
>      }
> }
>
>
> Ok, this might pause for a while, and then might start spitting out
> "finalize called".
> (It does on my VM, it should on most VMs, but a VM isn't required to do
> this)
>
> This program continuously intantiates fairly large objects, and discards
the
> references (so its immediately available for garbage collection).
>
> The call to System.gc() is ONLY A RECOMMENDATION to the VM. It is
perfectly
> ok for the VM to ignore such a request (in fact on my VM, it does ignore
the
> requests for a while). System.gc() is the programmer's way of saying
"here's
> a nice time to do some garbage collection, if you feel like it". It would
be
> perfectly legal for a VM to never garbage collect, and just keep wasting
> more and more memory, even if you called System.gc() over and over again.
>
>
> Finalize is something you really don't need to use. You cannot predict
> exactly when its going to be called (if at all), and for this reason, its
> only used in pretty specialized cases.
>
>
> Because deletion isn't explicit in Java, finalization is much less
> significant than it is in C++. In Java, you'll typically find that you'll
> have a close() or discard() method to tell an object to 'clean up' --
which
> you'd invoke when the operation is completed or the user clicks 'close'.
If
> you're new to Java, this might seem like a limitation, but I think you'll
> find that once you're used to Java's style of doing things it doesn't get
in
> the way.
>
> In practice you'll find that, say with sockets, it will be clear when
> something need to be closed (you may put a close statement in the finally
> clause of a try-catch). This is because such objects last either for a
> particular command (you'd close the objects when the command is
completed),
> or they will last for the entire application's execution (so you'd close
> them on shutdown).
>
> File and Socket I/O usually has a clear place to put open/close. GUI
cleanup
> is automatic on VM shutdown, and discard methods are invoked when a frame
is
> hidden (and will not be shown again). Almost everything else is done for
you
> by the garbage collector (such as deallocating arrays and memory used by
an
> object).
>
> The other thing you mentioned, physical ports aren't used often... but the
> comm framework (a standard extension) has close methods, which you'd
> probably find somewhere suitable to call them from.
>
> While I'm reluctant to say this, here I go... in Java, when you create
your
> own close method it is like creating a method for explicitly
> freeing/deallocating the object (except you leave the actual memory for
the
> garbage collector to clean up).
>
> I hope that explains things.
>
> -Benjamin Johnston
> s355171@student.uq.edu.au
>
>
>