…fail in C#, because operators are early-bound, and the compiler isn’t smart enough to bind them differently for different specializations. Then again, a comparable example will succeed in VB, because VB late-binds its operators.

Are you sure this works in VB.NET? T is not constrained and can be any type, the compiler should not compile to assure type-safety. I cannot get the VB.NET code compiled, with the same error message as the C# version “Operator ‘+’ is not defined for types ‘T’ and ‘T’”, which I think expected.

public T add<T>(T a, T b) { return a+b; }
DoStuff(List<String> list)
DoStuff(Listt<Integer> list)

I would think the same, but when I tried it out, it turned out that if both DoStuff methods return the same type, then it would not compile, as expected, but if they return different types, then it compiled just fine.

 public static String DoStuff(List list) {
    return null;
 }
 public static int DoStuff(List list) {
    return 0;
 }

I don’t understand why it can possibly compile, and there is no “magic” in the generated bytecode.

 public static java.lang.String DoStuff(java.util.List);
 Code:
   0:   aconst_null
   1:   areturn

 public static int DoStuff(java.util.List);
 Code:
   0:   iconst_0
   1:   ireturn

The above does not look like valid bytecode. I’ll need to look at the spec…

public T add<T>(T a, T b) { return a+b; }

DoStuff(List<String> list)
DoStuff(Listt<Integer> list)

My main complaint about C# generics is that arithmetic doesn’t work:

public T add(T a, T b) { return a+b; }

will fail in C#, because operators are early-bound, and the compiler isn’t smart enough to bind them differently for different specializations. Then again, a comparable example will succeed in VB, because VB late-binds its operators.

My main complaint about Java generics is that they break under method polymorphism, since they’re not really different types. A method with the signatures:

DoStuff(List list)
DoStuff(List list)

will fail, despite the fact that you might legitimately need different implementations.

So, given that Java doesn’t support collections of primitive types, the behaviour would seem identical.

Do you mean behavior of generics of reference types in .NET and Java? If it was what you meant, how come it is identical given the fact that type information is erased by the Java compiler?

You only get fair results if you restart your VM between each benchmark, and ideally ‘warm up’ the VM loading in the OS - as most OSs take longer to start the first instance of a process.

It did indeed take ridiculous amount of time in the first run (I recalled it took 27 seconds to finish the 10,000,000 elements for ArrayList of Integer). However, I did run the benchmark several times and only recorded the result when it looked stable. As I rerun the benchmark again many times today, the results are just close to that. Any idea?

If I don’t reply, drop me an email (ricky.clarkson@gmail.com)

Thanks for your consideration, Ricky. Just a suggestion if you are not aware of it: why don’t you subscribe to this entry’s RSS (you can see it at the end of the entry)

By VM instance, I meant the actual running VM. You only get fair results if you restart your VM between each benchmark, and ideally ‘warm up’ the VM loading in the OS - as most OSs take longer to start the first instance of a process. If there’s any overlap between two tests, the JIT may kick in and skew the results. Of course, you could turn the JIT off, but then your results are skewed in a different way.

If I don’t reply, drop me an email (ricky.clarkson@gmail.com). I only spotted this reply because my RSS reader told me that the dzone link had been promoted.

What is the criteria the CLR uses to decide whether to share the code or not?

If a method of generic type or a type parameterized method is already JIT-compiled for a specific reference type, then it will be reused when the code of the same method is needed for any other reference types. The same does not hold for value types since the internal representation of them are different, thus unique method code must exist for each type. For structs, those with the same internal layout will share the same x86 code.

Space inefficiency works out to be time inefficiency, quite often, because of cache misses (lack of memory locality).

I agree, if the space inefficiency is big enough. In the CLR case, the runtime code sharing would, hopefully, prevent excessive space inefficiency.

The benchmarking code is flawed because the same VM instance is used for all code

I did it on JDK 5 - update 11, which is the latest. I believe there is better way to do the benchmark but I do not quite understand why it is flawed. What do you suggest to benchmark to be done differently?

That’s what Bracha’s optional typing is about; worth a Google.

I’ll definitely take a look at that.

You’d need some type that was a List plus a type token for that…

Thanks for sharing the code. This emulation is helpful in several use cases.

Again, thanks a lot for offering your insights into the topic, Ricky.

I assumed the former, and didn’t realise the latter. What is the criteria the CLR uses to decide whether to share the code or not? It is at least interesting that the CLR has the choice as to whether to share the code or not, which the JVM does not have.

“Finally, I see this as an inefficiency of space, not of time.”

Space inefficiency works out to be time inefficiency, quite often, because of cache misses (lack of memory locality).

The benchmarking code is flawed because the same VM instance is used for all code. I haven’t read it properly, because of that, though I appreciate your attention to detail there.

“Finally, I do not see why the compilers should not disallow really ridiculous stuffs like casting a list of int to a list of string.”

Because that cast might be desirable when you are only halfway through generifying some code. It is actually a good thing, if you are working with good programmers, to allow arguably crap code, but to tell the developer how crap the code is. That’s what Bracha’s optional typing is about; worth a Google.

“Let’s say I need to know if an instance of list is a list of String a list of Integer, can I do that with type tokens?”

No. You’d need some type that was a List plus a type token for that. E.g.:

class ListPlusTypeToken<E>
{
public final List<E> list;
public final Class<E> type;

public ListPlusTypeToken(List<E> list,Class<E> type)
{
this.list=list;
this.type=type;
}
}

Have you got hard data that shows that .NET collections are faster, or is this speculation? It would be valid for the Hotspot VM to eliminate casts if it can be certain that they would always pass. Remember that casts are only actually checks at runtime.

The example of really stupid code in Java relies on the developer ignoring compile warnings, i.e., it relies on the intentionally-stupid developer.

One advantage of the erasure approach is that the stupid code is compilable, and testable, so one can generify their code in small stages, rather than having to generify everywhere before testing. Now, that wouldn’t matter so much, because the IDEs have caught up with the language sufficiently, but in the early days of Java 5, the IDEs didn’t know where they were.

Reification is proposed for Java 7.

Marcos - reflection can be emulated through the use of type tokens.

Buu Nguyen - Generics information exists in class files. It doesn’t exist for local variables. Everywhere else it does.