Re: finalize() not guaranteed to be called -- ever

Raymond DeCampo <nospam@xxxxxxxxxxxx> wrote:
> > And Java does not have this feature nor manual forced deletion of the
> > object because they lead to things like dangling pointers. The other
> > problem is that objects in variables have value semantics and not
> > reference semantics. Value semantics for an object means that the object
> > will not be polymorphic. It can also cause confusion when you do
> > something like this where B is a subclass of A:
> >
> > B b;
> > A a = b;
> >
> > Which will cause a to not be a B anymore.
>
> You'll have to be more clear here. I'm not even certain which language
> you are referring to.

Dale is referring to C++, and explaining very succinctly why "objects"
placed on the stack in C++ are NOT actually objects by the standards of
typical OO theory. It's a point that's lost on many C++ developers. It
is also the justification for not including this possibility in Java.

> > So the point is that the issue has nothing to do with destructors, but
> > with the lack of variables that hold objects. Just adding destructors
> > buys you absolutely nothing for Java.
>
> I do not see how your conclusion follows. Destructors could be added to
> Java with benefits. All that would really be necessary would be that
> the JVM should guarantee that finalize() is called. Then
> implementations of java.sql.Connection could close() themselves, etc.

Let's start by agreeing on common definitions. A destructor a block of
code that is called automatically when an object is deallocated. Since
there's never any way at all to guarantee that an object will be
deallocated in Java, destructors per se wouldn't do any good.

You suggest that the JVM can just guarantee that finalize() is called,
without changing the memory model. The question is: WHEN would the JVM
guarantee to do that?

Would it be called whenever ANY reference to an object goes out of
scope? That would be very annoying, and would entirely prevent such
basic and good design techniques as passing database connections to
other methods or storing them in data structures. They would be getting
inadvertently closed all the time, and oh what a pain it would be.

Would it be called whenever the last live reference to an object goes
out of scope? I hope not, because that would prevent the use of any
kind of deferred garbage collection algorithms for finalizable objects.
You'd be stuck with all JVMs doing weak/strong ref-counting for ANY
reference to ANY supertype of ANY type that defines a finalize() method.
Performance would tank, and we'd be in serious trouble.

Or perhaps the VM should read your mind and decide when to call the
destructor?

> There are many pitfalls there however and the designers of Java chose
> not to include this benefit. To say it buys you nothing doesn't wash
> however.

Dale said it doesn't buy you anything unless you also change the memory
model to allow locally-scoped "objects" (which, of course, are not true
objects). As it turns out, Dale hit it right on the head on this one.
I'm anxiously awaiting your answer to the magic question of "when", as
explained above.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
.

Relevant Pages

  • Re: Can Java Programmer Learn C++ Quickly?
    ... It's a serious mistake to equate finalize() with a destructor. ... Destructors are primarily used to release resources; ... Java, and should be used with try/finally blocks. ...
    (comp.lang.java.programmer)
  • Re: finalize() not guaranteed to be called -- ever
    ... Then the Java object should have some kind of dispose method. ... Destructors are a nice feature of C++. ... C++ has the added feature that objects can be created as local variables which are destroyed automatically when the variable goes out of scope. ... The other problem is that objects in variables have value semantics and not reference semantics. ...
    (comp.lang.java.programmer)
  • Re: finalize() not guaranteed to be called -- ever
    ... Then the Java object should have some kind of dispose method. ... It is very different in that it is possible to write C++ programs in which the destructors are never invoked manually but do run. ... In Java you call a dispose method which you only have to do for objects with non-memory resources to free. ... All that would really be necessary would be that the JVM should guarantee that finalize() is called. ...
    (comp.lang.java.programmer)
  • Re: Can Java Programmer Learn C++ Quickly?
    ... > Are you sure you can make virtual function calls from destructors in ... what about finalize? ...
    (comp.lang.java.programmer)
  • Re: Why does C# see protected java members as public?
    ... I understand issues regarding java package scoping, ... What is it in the java "protected" semantics ...
    (microsoft.public.dotnet.vjsharp)