Article:
  What I Hate About Your Programming Language
Subject:   Java; I want a destructor!
Date:   2003-05-18 18:20:29
From:   anonymous2
Response to: Java; I want a destructor!

The purpose of a destructor is to free resources (not just heap memory). Closing files, sockets, database connections, etc., even in the presence of exceptions, without having to remember to try-finally-release them can be quite powerful. Garbage collection is nice and has its place, but isn't a panacea.
Full Threads Newest First

Showing messages 1 through 3 of 3.

  • Java; I want a destructor!
    2003-05-19 03:26:12  anonymous2 [View]

    This is especially true in a object-oriented language. I have a stream. Is it a memory stream or does it represent a file, a socket, or something else that the garbage collector won't release (or that a finalize method will release too late)? If you don't know, then you'll have to remember to try-finally-close that stream. Even when dealing with memory streams. That's convenience?
    • Java; I want a destructor!
      2003-07-08 07:03:53  anonymous2 [View]

      Unfortunately the presence of a destructor poses HUGE problems for a garbage-collected language. The garbage collector can't tell when it's safe to collect an object, it can't just drop all the objects when the program ends, etc. I too missed destructors, but try ... finally ... is a good substitute.

      Don't use finally() (or python's __del__(), for that matter) as you would a destructor. They may never get called. Also, they pose problems for the garbage collector.
      • Java; I want a destructor!
        2006-01-23 23:26:01  bastos [View]

        This is a total falsehood. Destructors in a garbage collected langauge are quite easy indeed. Since telling when memory is ready to be freed up is simply a matter of keeping, and checking, a reference count for that object...calling destructors are obviously simply handled at this point. Is an object being referenced (in use)? No, then lets destroy it, wait, it has a destructor, let's call that first...

        This is why Java *does* give you a destructor. Java destructors however have a problem, and this problem is called by java optimizations. Some of these optimizations are that Java doesn't collect immediately. And java doesn't collect immediately due to the fact that it's not always effective to do so, such as if a bunch of objects were just fell out of reference because a program is about to exit, obviously we'd be freeing them up for nothing in most platforms as they'll get cleaned up by the process ending.

        Also, since java allocates its memory in blocks, it will wait until a threshold is met before it garbage collects what has no reference rather than allocating more memory. This is another one of the many optimizations that has sped java up over the years.

        Below is a simple program, running it and analyzing the output will demonstrate the behavior described above, and set the record straight about java having a destructor:


        import java.util.LinkedList;

        class TestGC {
        static int lastid = 0;

        class MemSucker {
        public int id = 0;

        byte[] Suck = new byte[25000];
        {
        id = ++lastid;
        System.out.printf("memsucker %d created...\n", id);
        }

        protected void finalize () {
        System.out.printf("memsucker %d destroyed...\n", id);
        }
        }

        TestGC () {
        LinkedList <MemSucker> sucklist = new LinkedList <MemSucker> ();

        for (int i = 0; i < 5000; i++) {
        sucklist.add(new MemSucker ());

        if (i % 2 == 0) {
        int id = sucklist.removeFirst().id;
        System.out.printf("marked %d for GC\n", id);
        }
        }
        }

        public static void main (String[] arguments) {
        new TestGC ();
        }
        }