On Feb 1, 2012, at 5:06 AM, #VAISAGH VISWANATHAN THATTAMPARAMBIL# wrote:

> 1.       Backward compatability: You had mentioned that backward compatability was one reason. As in the Collections Framework, is it not possible to enable generics and still compatibility? Did you mean that it would be a lot of work to maintain backward compatability while enabling generics?
> 2.       Performance : Because of type erasure, won’t a generic and non-generic code behave in the same way?
> 3.       Lot of work : This I can’t argue with  J.

Backward compatibility is not a good reason.  The big reasons are (1) efficiency issues and (2) it's a lot of work and (3) I don't like how Sun screwed up generics.  :-)

Some discussion about #1.  Generics tend to promote extreme laziness because they operate over basic types by doing autoboxing.  As a result we see a lot of stuff like this:

	Double d = 4.0
	double i = d + 3;

It's hard to overstate just how evil stuff like this is.  It's unbelievably slow.  This impacts ECJ more than MASON, but we still see it a lot in mistaken models.

For fun, try comparing the following code:

import sim.util.DoubleBag;
import java.util.ArrayList;

public class Test
    {
    public static void main(String[] args)
        {
        DoubleBag d = new DoubleBag();     // comment this out 
        //ArrayList<Double> d = new ArrayList<Double>();  // uncomment this
        for(int i = 0; i < 100000; i++)
            d.add((double) i);
        for(int i = 0; i < 100000; i++)
            for(int j = 0; j < 100000; j++)
                d.set(j, d.get(j) + 1);
        System.err.println(d.get(4));
        }
    }

If I run with DoubleBag (an extensible array of basic doubles), this runs in 23 seconds on my machine.  If I run with ArrayList<Double>, this runs in 829 seconds.  I kid you not.


Some discussion of #3: Generics broke arrays in a big way.  So much so that Sun had to create an Arrays class which generates arrays in a ridiculously roundabout fashion, and inside the code of that class it's filled with @SuppressWarnings tags to prevent Sun's own compiler from compiling about its own code.  :-)  

MASON and ECJ use arrays quite extensively for speed.  All the broken screwiness involved in doing generics with arrays gives me serious pause.

Are these good reasons?  I dunno.  Certainly in the future we're going to add some generics to the MASON API where they'd be useful and really reduce casting.  But internally I'll probably still stick with a generics free approach just so I don't have to waste brainpower as an old-time Java coder.

Sean