A DESCRIPTION OF THE REQUEST :
As it stands, reference objects are only useful when it comes to cleaning data structures or releasing resources since the referent will get garbage collected whatever the code dealing with the reference queue does.
However, it could be interesting if the program was notified whenever a given object is collectible while not having the object finalized before nor automatically collected afterwards. The main idea is to be able to set the object back to a strongly reachable state which could prove very interesting when dealing with objects caching.

JUSTIFICATION :
Objects pooling is probably one of the most efficient optimisation technique to boost java applications featuring intense data structures modifications and/or dynamic connectivity . The Real-time framework embedded in JADE provides stunning performances and there is no need to wonder why JDBC now officially features Connection pooling.
Pooling is useful and unavoidable for large projects. Unfortunately, using pools and a garbage collector are quite tedious: pooling brings us back down to the good old new/delete scheme of C++. When you get an object from a pool, you do need to put it back or, else, it will get collected. This leads to cumbersome coding with finally blocks all around and object state controls. You end up writing the same code over and over and over again.
Most frustrating of all, the garbage collector is perfectly able to do the job for us. All we need is a new degree of reachability which can be switched back to strongly reachable.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
VOCABULARY

Let us call this new status "re-usably reachable". Of course, we need a new class derived from java.lang.ref.Reference, let us call it "ReusableReference".

REACHABILITY:

Going from strongest to weakest, the different levels of reachability reflect the life cycle of an object. They are operationally defined as follows:

    * An object is strongly reachable if it can be reached by some thread without traversing any reference objects. A newly-created object is strongly reachable by the thread that created it.
    * An object is softly reachable if it is not strongly reachable but can be reached by traversing a soft reference.
    * An object is weakly reachable if it is neither strongly nor softly reachable but can be reached by traversing a weak reference.
    * An object is re-usably reachable if it is neither strongly, softly nor weakly reachable but can be reached by traversing a reusable reference. When the reusable references to a re-usably reachable object are cleared, the object becomes eligible for finalization.
    * An object is phantom reachable if it is neither strongly, softly, weakly nor re-usably reachable, it has been finalized, and some phantom reference refers to it.
    * Finally, an object is unreachable, and therefore eligible for reclamation, when it is not reachable in any of the above ways.

CLASS DESCRIPTION:

java.lang.ref
Class ReusableReference<T>

java.lang.Object
  extended by java.lang.ref.Reference<T>
      extended by java.lang.ref.ReusableReference<T>

public class ReusableReference<T>
extends Reference<T>

 Reusable reference objects, which are enqueued before their referents get finalized. Reusable references are most often used for object pooling.

 Reusable references sharing the same referent are organized into a re-usability list which is chronologically ordered so that the oldest reference created is first and the most recently created is last. If the garbage collector determines at a certain point in time that the referent of a re-usability list is re-usably reachable, then at that time or at some later time it will enqueue the first reference of the list.

Once the first reusable reference has been queued, two cases may occur:
    * the reference gets cleared. It is then removed from the re-usability list. If the list is now empty, the object is eligible for finalization. If not, the first reference in the list will get queued at some later time.
    * the referent is retrieved by calling the get method of the reusable reference, in which case the referent switches back from re-usably reachable to strongly reachable, thus preventing it from being collected.

 Classes that require special actions to be performed before being re-used must implement a special method with this exact signature:

 private void reuseObject();

 It will get called whenever the object passes from re-usably reachable to strongly reachable, that is right before being returned by the get method of a queued reusable reference.

---------- BEGIN SOURCE ----------
/*
 * A little example of what could be possible.
 *
 * I purposively ignored exceptions thrown for clarity,
 * so the code is not usable as is.
 *
 * This is a very na?ve pool with no size limit
 *
 */

public class Pool<T> {

    // List of references
    private final LinkedList<ReusableReference<T>> list =
      new LinkedList<ReusableReference<T>>();

    // Queue of references (the actual pool)
    private final ReferenceQueue<T> queue =
      new ReferenceQueue<T>();

    // Class
    private final Class<? extends T> classDesc;

    // Constructor
    public Pool(Class<? extends T> classDesc) {

        this.classDesc = classDesc;
    }

    // get a new instance
    public T getNewInstance() {

        synchronized(queue) {

                 if (queue.pool()!=null)
                   return queue.remove().get();
         }

         // No object in the pool
         // so let us create one
        T object = classDesc.newInstance();

         // Reference it and add it to the list
        synchronized(list) {

                 list.add(new ReusableReference(object,queue))
         }

        return object;
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
C++ memory management style programming.
###@###.### 10/11/04 18:30 GMT