> -----Original Message-----
> From: Peter B. West [mailto:[EMAIL PROTECTED]
<Some babbling about trees and ladders ...>
<snip />
> There's a lot of subjective judgement in making such calls, which is why
> it's useful to have a number of different opinions kicking ideas around.

Yeah.. it probably is too subjective to settle in a few sentences. Of
course, a whole lot of different 'types' of 'most common cases' are possible
(--depending more on the usage context: 1 or 2 paged, but very
processor-intensive documents vs. 48 pages of plain body-text )

I guess it calls more for a sort of recon approach (checking out the tree
before deciding what ladder to bring :) one trip back to the workshop was
part of the deal...)

<snip />
> >>I find the language of the java.lang.ref package confusing, but I think
> >>that phantom references open the possibility of performing serialization
> >>  "on demand", when the object is queued for GC.
> >>
> >
> >
> > Can you elaborate a bit on this? AFAICT, the actual referent of
> a phantom
> > reference is itself unreachable through the reference object (the ref's
> > get() method always returns null), so you could indeed test via
> isEnqueued()
> > whether or not the referent of a phantom reference is queued for GC, and
> > then...? A soft reference at least would allow to get() the
> object and do
> > something with it or make it do something with itself before actually
> > clearing the ref.
> As I say, I find the language confusing, but it seemed to me that, as
> long as the object being GC'd contained enough information to determine
> its origins, when it found its way onto the reference queue for disposal
> the thread responsible could serialize it just before it was destroyed,
> and store the information required for its recovery in the appropriate
> place.  The same may be achievable using the other reference types.

In a way, I was actually wondering whether you were thinking of only using
the phantom ref to *test* for an object being queued, and possibly use the
object itself to do the serialization?
(science-fiction: I was thinking of an object being created and being
phantom referenced, and when being created, also being given a way to access
its own phantom reference to be able to find out whether it is scheduled for
GC, and if so, trigger a serialize() method... seemed a bit 'ridiculous'
when I thought it over --in the sense of: ridiculously unfeasible, my wild

> Whether the imprecations against finalizers apply also to phantom
> reference finalizers I don't know.

Hmm. IIC the whole idea of Reference objects is to allow more fine-grained
control WRT object finalizing. Where a finalizer is executed *when* an
object is scheduled for GC, period. With the reference types, this control
is left to the programmers --i.e. conditional finalizing.. You could write a
finalizer whose body is totally conditional (enclosed in an if-statement),
but the method would be entered anyway in the case of a 'classic' finalizer,
even if only to perform the test.
By use of the ref types, one can even choose to execute a different kind of
finalizer for different situations, and, more importantly, it separates the
finalizing logic from the logic of the object/class.

So whether the imprecations against finalizers also apply here, depends
totally upon ourselves, it would seem.



Reply via email to