Facsimile Simulation/Emulation Library

The implementation of generics in Java is pathetic! C# was the first of the two languages (let's face it, C# is so similar to Java that one might make the mistake of thinking that C# was merely Microsoft's embraced and extended version) to release a compiler supporting generics - a feature that allows classes and functions to take type parameters, somewhat akin to the templates feature of C++. As a huge fan of the latter, I found the C# implementation intelligent and well thought out, even if it was a little restricted by comparison. Java has been around a lot longer than C#, and has had far more time to formulate a superior generics implementation. It has failed miserably to do so.

Before getting into the details, here's the main problems with Java's generics:

1. At run-time, all generic type information is lost. For example, a Stack <Box> cannot be distinguished (at run-time) from a Stack <Receipt> - they both become just a Stack.
2. At run-time, all type parameter instances are converted to/from Object references, meaning that there is a high upcast/downcast overhead (not to mention a high boxing-unboxing overhead, if using primitive types) when using generics.
3. All instances of generic classes have the exact same static members.
4. It is not possible to throw generic exceptions (generic classes derived from Throwable).

Problem 1 is the biggest and most significant, and is the underlying cause of the other three. The root cause of the problem is that a single generic definition is stored in the .class output file from the Java compiler. When a new generic instance of the class is created, it refers to this same block of code, with only compile-time checking to ensure that it is used consistently. The primary advantage of this method, and the primary excuse for this monumental screw-up, is that no changes needed to be made to the Java Virtual Machine specification in order to support generics. In my mind, the only beneficiaries of this decision are embedded devices that cannot upgrade or patch their virtual machine software.

C#, as a Java clone, faced a similar dilemma. It solved the problem by retaining exact generic type information at run-time (so that a Stack <Box> instance is a distinctly different type of object from a Stack <Receipt> instance) and by only creating a template block of code in the compiler's output file. Whenever a different generic type is required, the .NET virtual machine copies this template definition, at run-time, and modifies it to become the code for this specific generic type. Now, this solution does require more memory, has a slight run-time performance hit and required a new version of the .NET virtual machine specification to support this feature, but it is still a far superior solution to that adopted by Sun. And regular readers will attest that it's not very often that I admire something Microsoft have done! C++, which is free from many of the restrictions inherent in the design of both Java and C# merely creates generic-type specific code at compile time (or, for some implementations, at link time).

Problem 2 is also significant as it degrades run-time performance significantly. Because the same block of code must work for all supported type parameter instances, Java simply stores all type parameter data as Object class references. This means that all data going into storage must be upcast; a process that has almost no run-time overhead. However, when this data is returned, it must be downcast and converted from an Object reference back to a reference to the correct type. This has a much more significant run-time overhead.

Say I want to have a simple, generic queue of objects. I want to add objects to the end of the queue (a push operation) and remove objects from the head of the queue (a pop operation). I'd also like to know how many objects are in the queue. With generics, I can accomplish this as follows:

Main.java:

public class Main
{
    public static void main (String [] args)
    {
        Queue  doubleQueue = new Queue  ();
        Queue  intQueue = new Queue  ();
        doubleQueue.push (new Double (2.0));
        doubleQueue.push (new Double (5.0));
        doubleQueue.push (new Double (8.0));
        intQueue.push (new Integer (2));
        intQueue.push (new Integer (5));
        intQueue.push (new Integer (8));
        try
        {
            System.out.println ("Type of doubleQueue is " +
            doubleQueue.getClass ().getName ());
            while (doubleQueue.size () > 0)
            {
                System.out.println ("Next double in queue is " +
                doubleQueue.pop ().toString ());
            }
            System.out.println ("Type of intQueue is " + intQueue.getClass
            ().getName ());
            while (intQueue.size () > 0)
            {
                System.out.println ("Next integer in queue is " + intQueue.pop
                ().toString ());
            }
        }
        catch (Exception e)
        {
            System.out.println (e.toString ());
        }
    }
}

Queue.java:

public class Queue 
{
    private ListMember  first;
    private ListMember  last;
    private int numMembers;
    public Queue ()
    {
        first = null;
        last = null;
        numMembers = 0;
    }
    public void push (T member)
    {
        ListMember  newMember = new ListMember  (member);
        if (first == null)
        {
            first = newMember;
        }
        else
        {
            last.setNext (newMember);
        }
        last = newMember;
        ++numMembers;
    }
    public T pop ()
    throws Exception
    {
        if (first == null)
        {
            throw new Exception ("Queue is empty");
        }
        T poppedMember = first.getMember ();
        first = first.getNext ();
        if (first == null)
        {
            last = null;
        }
        --numMembers;
        return poppedMember;
    }
    public int size ()
    {
        return numMembers;
    }
}

ListMember.java:

public class ListMember 
{
    private T member;
    private ListMember  nextMember;
    public ListMember (T newMember)
    {
        member = newMember;
        nextMember = null;
    }
    public void setNext (ListMember  newNextMember)
    {
        nextMember = newNextMember;
    }
    public ListMember  getNext ()
    {
        return nextMember;
    }
    public T getMember ()
    {
        return member;
    }
}

When executed, this code produces the following output:

Type of doubleQueue is Queue
Next double in queue is 2.0
Next double in queue is 5.0
Next double in queue is 8.0
Type of intQueue is Queue
Next integer in queue is 2
Next integer in queue is 5
Next integer in queue is 8

However, here is some equivalent code that represents what the Java compiler actually emits when fed the above source. Note the complete lack of any generic syntax:

Main.java:

public class Main
{
    public static void main (String [] args)
    {
        Queue doubleQueue = new Queue ();
        Queue intQueue = new Queue ();
        doubleQueue.push (new Double (2.0));
        doubleQueue.push (new Double (5.0));
        doubleQueue.push (new Double (8.0));
        intQueue.push (new Integer (2));
        intQueue.push (new Integer (5));
        intQueue.push (new Integer (8));
        try
        {
            System.out.println ("Type of doubleQueue is " +
            doubleQueue.getClass ().getName ());
            while (doubleQueue.size () > 0)
            {
                System.out.println ("Next double in queue is " +
                ((Double) doubleQueue.pop ()).toString ());
            }
            System.out.println ("Type of intQueue is " + intQueue.getClass
            ().getName ());
            while (intQueue.size () > 0)
            {
                System.out.println ("Next integer in queue is " + ((Integer)
                intQueue.pop ()).toString ());
            }
        }
        catch (Exception e)
        {
            System.out.println (e.toString ());
        }
    }
}

Queue.java:

public class Queue
{
    private ListMember first;
    private ListMember last;
    private int numMembers;
    public Queue ()
    {
        first = null;
        last = null;
        numMembers = 0;
    }
    public void push (Object member)
    {
        ListMember newMember = new ListMember (member);
        if (first == null)
        {
            first = newMember;
        }
        else
        {
            last.setNext (newMember);
        }
        last = newMember;
        ++numMembers;
    }
    public Object pop ()
    throws Exception
    {
        if (first == null)
        {
            throw new Exception ("Queue is empty");
        }
        Object poppedMember = first.getMember ();
        first = first.getNext ();
        if (first == null)
        {
            last = null;
        }
        --numMembers;
        return poppedMember;
    }
    public int size ()
    {
        return numMembers;
    }
}

ListMember.java:

public class ListMember
{
    private Object member;
    private ListMember nextMember;
    public ListMember (Object newMember)
    {
        member = newMember;
        nextMember = null;
    }
    public void setNext (ListMember newNextMember)
    {
        nextMember = newNextMember;
    }
    public ListMember getNext ()
    {
        return nextMember;
    }
    public Object getMember ()
    {
        return member;
    }
}

Even the output is the same:

Type of doubleQueue is Queue
Next double in queue is 2.0
Next double in queue is 5.0
Next double in queue is 8.0
Type of intQueue is Queue
Next integer in queue is 2
Next integer in queue is 5
Next integer in queue is 8

In fact, when using Sun's javac compiler on Ubuntu Linux, the .class output files for both versions of the Main class are identical!

With this example, one might wonder about the benefits of programming with generics at all!

The third problem, unlike the other three, is likely to cement the current generics behavior. Once developers have come to rely on this behavior, their applications are going to break if Java's generics are ever fixed. Generally, language developers do not like to break existing code with new releases, so everyone will likely just have to live with this inferior implementation indefinitely.

The problem is this: if I have a generic class that has static data, then I expect each generic type to have its own copy of that static data. However, Java keeps a single copy of the static data for all generic types. Consider the following:

public class X <T>
{
    private static int count;
}

If you've done generic programming with either C++ or C#, then you'll know that X <Car>.count is a different object to X <Truck>.count. However, in Java they are identical. If you want to have common static data to your generic types, then you can easily derive your generic class from a base class that will contain the common static data. But if you want to make your static data unique to each generic type, then - in Java - you're stuffed.

As for the fourth problem, for me this is fairly minor. I'm sure that generic exceptions have their uses - such as presenting faulty type parameter data from generic classes - but the lack of this feature is relatively minor compared to the other three.

I'm sure that there are long-time Java gurus gnashing their teeth in anger at this blog, but the truth must be told. Although it will break the applications of some early adopters, Java's generics must be fixed.

Now that Sun has decided to release Java as free software, my hope is that the free software community will put matters to rights as soon as possible. If not (and Sun are going to stay in charge of the official branch of the software, after all), then I may have to consider going back to C# and .NET or picking some completely different language...