Garbage-collecting the cloned objects

Question

public class Clone implements Cloneable {
public static void main(String[] arg) {
Clone i0, i1;
i0 = new Clone();
System.out.println("Created: " + i0);
try{
i1 = (Clone)i0.clone();
System.out.println("Cloned: " + i1);
} catch(CloneNotSupportedException e){
e.printStackTrace();
i0 = null;
i1 = null;
System.gc();
public Object clone() throws CloneNotSupportedException {
return super.clone();
public void finalize() {
System.out.println("Finalizing " + this);
With the example above you can notify that with Hotspot VM of JDK1.3 the
finalize() method will not be called for the cloned object; though,
running the sample with the classic VM, the finalize() will be
called for both objects.
Bypassing the finalize() can be made intended, in order to avoid
multiple "release" or "close" calls on the same object, eg. if the
finalize() has to close a file or a JDBC-connnection. But then why
is it called in the classic VM? Is it sure that the cloned object
too will be garbage-collected?

Answer 1

Here's the proper way to write a clone() method:
public Object clone() {
    try {
        return super.clone();
    } catch (CloneNotSupportedException e) {
        throw new RuntimeException(e);
}There's no reason for a clone() method to declare that it throws CloneNotSupportedException. Doing so just makes code that uses the clone() method more complicated unnecessarily.
Here's the proper way to write a finalizer:
protected void finalize() {
    try {
        // perform subclass cleanup
    } finally {
        super.finalize();
You should always make finalize() protected to help ensure that only the garbage collector calls it, and it should always call super.finalize() to ensure that the superclass finalization can happen.
Now, to your question. There's no way to guarantee that an object will be garbage collected or finalized. In fact, finalizers are so notoriously hard to write correctly that Java 2 added PhantomReferences to allow a simpler way to clean up objects.
If you want an object to release resources, such as closing a file or releasing a database connection, provide a close() or dispose() or release() method in the class and close the resources there. Even if you could guarantee that your finalizer is called or if you used PhantomReference queues to perform cleanup, this cleanup would probably not happen in a timely manner. Finalizers are not C++ destructors -- if you need to release resources, add a method to do that.