> -----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 imagination) > 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. Cheers, Andreas
