On Tuesday 16 December 2003 01:46, Jonathan Hawkes wrote:
> No, actually, I meant it as I said it.  Consider the following:
>
> class A {
> B b;
> public String toString() {
>     return "I am an A";
> }
> protected void finalize() {
>     System.out.println(b);  // Just do anything with b
>     // b is reachable here
> }
> }
>
> class B {
> A a;
> public String toString() {
>     return "I am a B";
> }
> protected void finalize() {
>     System.out.println(a); // Just do anything with a
> }
> }
>
> public class Test {
>     public static void main(String[] args) {
>         Test test = new Test();
>         test.setup();
>         // wait for GC
>         Object o = new Object();
>         synchronized (o) {
>             o.wait();
>         }
>     }
>     private void setup() {
>         A a = new A();
>         B b = new B();
>         a.b = b;
>         b.a = a;
>     }
> }

I don't know what you expect me to experience, and since the JLS has no answer 
to what will happen in detail, I had to "observe behaviour" which is 
per-definition wrong.

As it is written now, GC will NOT happen at all (at least not on my JVM).
Because there is no low memory condition, and GC will hold its horses.
Add a System.gc() at // wait for GC, and I get B before A (irrelevant, the 
spec says either one will have the finalize() called first, or at the same 
time on a multiprocessor system).
I am a B
I am an A

What you said was (or as least as I interpret any ambiguity). A reference B, 
then A don't reference B and A's finalize() will be called, which is not 
true. B's finalize() is called.

Your quoted text bears little weight compared to the Execution chapter in the 
JLS. It is very imprecise and doesn't even use the proper terminology for 
reachable/finalizer-reachable/unreachable (text below talks about "can be 
accessed" )

Sorry, don't carry an argument with inadequate evidence... ;o)

Niclas

> Now, try it for yourself, and read the API docs for Object.finalize() and
> see if you can't pull it out for yourself.  I have included excerpts below
> and emboldend the appropriate areas:
>
>
> The general contract of finalize is that it is invoked if and when the
> JavaTM virtual machine has determined that there is no longer any means by
> which this object can be accessed by any thread that has not yet died,
> <bold>except as a result of an action taken by the finalization of some
> other object or class which is ready to be finalized.</bold>
>
> After the finalize method has been invoked for an object, <bold>no further
> action is taken until the Java virtual machine has again determined that
> there is no longer any means by which this object can be accessed by any
> thread that has not yet died, <bolder>including possible actions by other
> objects or classes which are ready to be finalized, at which point the
> object may be discarded. </bolder></bold>
>
>
> INCLUDING POSSIBLE ACTIONS BY OTHER OBJECTS OR CLASSES WHICH ARE READY TO
> BE FINALIZED
>
>
> ----- Original Message -----
> From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> To: "Avalon framework users" <[EMAIL PROTECTED]>
> Sent: Monday, December 15, 2003 9:57 AM
> Subject: Re: When use ServiceManager.release(obj)?
>
> > On Monday 15 December 2003 23:21, Jonathan Hawkes wrote:
> > > Before an object is discarded, any object that references that object
>
> will
>
> > > have its finalize() method invoked.
> >
> > I think you typed the above statement wrongly...
> > It should be the finalize() method of the "discarded" (actually
> > transition from reachable/unfinalized state to
> > finalizer-reachable/finalizable state) object that is called, not the
> > referencing (no longer any reference, btw) objects.
> >
> > I assume it was an honest mistake (or you need to be sent back to Java
>
> Torture
>
> > School ;o) ).
> >
> > Cheers
> > Niclas
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to