Hejlsberg Talk About Generics in C# and Java

An anonymous reader writes "artima.com has a very interesting interview with Anders Hejlsberg - the Borland guy now at Microsoft who can best be defined as MR C# - doing all the stuff that Borland wouldn't let him do. He discusses generics in C#, Java (1.5) and C++. Naturally there is the chance of bias but he does raise some interesting points againt Java's generics. Specifically that Java's genericised collections will have to box all primitive types as full objects, whereas C# does not. This is a big performance plus for C#. Java created the primitive types in the first place to address performance concerns but appears to be stepping sideways here. I can't help wondering if Sun has taken this approach to get the syntatic sugar in the language without requiring a bytecode change, but perhaps in a future VM version will allow primitive generics (obvioulsy forcing a bytecode regeneration)?"

Boxing in Java

[Ianoo]

Primitive types are boxed in C#, just automatically wrapped and unwrapped as required. But what he seems to fail to realise is that Java 1.5 is introducing this too, so that I will be able to define method(Object obj) and type method(12) and will receive a boxed Integer type. This should work fairly for generics too (I hope).

Why Generics?

[HaiLHaiL]

I'm a Java developer of 4 years and I'm unimpressed by generics. Why have all those 's dirtying up my code, only to enforce strong typing on my collections? If strong typing is really important, I can create my own strongly-typed collection. Otherwise, there's something called GOOD CODING, along with runtime exceptions, which enforce it. I don't see the need for all that extra ugly syntax just to enforce it at compile time.

Re:Boxing in Java

[drkich]

Yes, C# does auto-boxing for the user. However, his point was that the Generics will not auto-box the primitive inside of an object.

So for instance if you have a List, you can not place an Integer with out unboxing it. Vice-versa, if you have a List you can not place an int into with out boxing it.

However if you have a List you can place an int into it directly without boxing it.

Re:Boxing in Java

[jovlinger]

Automatic boxing and unboxing will be identical to manual boxing from a performance standpoint.

I got the impression that C# could actually use generics to instantiate the array at type int, rather than type Integer with autoboxing.

It does seem any "performance" argument is bogus

[spitzak]

Not having to "box primitives" is certainly an advantage in that it makes the language cleaner. So I think C# is better because of this. But I find it hard to believe that this "improves performance". I would think the whole reason for treating primitives differently is to improve performance, as they can go through optimized code rather than the path taken by normal user-defined objects. So a collection of boxed primitives in Java may be slower than non-boxed primitives in C#, but this was done so that a collection of normal objects is faster.

Though really, I want to know why these languages have to be written so "primitives" are special at all. I would really like to be able to subclass an int or other built-in, and having "methods" on an int would be nice (even if you can't define new ones). The main reason is so you don't have to rewrite if you change your mind about whether type A is a primitive or something you define. Can't the byte compiler do a bit of work so any fast-path for the primitive can be used, without building in such restrictions to the syntax?

Oh, the irony!

[joelparker]

...we do fairly aggressive code sharing
where it makes sense, but we are also very
conscious about not sharing where you want
the performance.

Welcome to the Microsoft business model. :)

Re:It does seem any "performance" argument is bogu

[dustman]

The types of performance problems you're talking about are orders of magnitude away from the performance problems that users percieve when using Java applications though.

I disagree here.

Think of Moore's law, processor speeds, etc... Java is a fast enough language for doing just about anything a user needs to do. Even if java were only 25% as fast as native code, that would be 2 cycles of Moore's law, 36 months, 3 years ago. (And, java is much faster than 25% of C, check here [bagley.org])

3 years ago, users were all doing the same things they are doing today.

A couple of exceptions apply, of course: scientific computing, games, etc, tax the hardware pretty heavily.

But, the primary reason that Java is perceived as slow by users is the terrible speed of the GUI.

All the widgets are implemented in Java directly. This is almost like the same exception as game software, since all this rendering code involves moving around lots of memory, etc...

The GUI matters more than anything to user perception of slowness.

An old 14mhz 68000 amiga often "felt" faster than a 50mhz 386, because the amiga's os/gui were very responsive, while the 386 was running win3.1

Look at the recent developments with the linux kernel. Compare X responsiveness with a preemptible low-latency kernel, and how the whole machine "feels" better.

By going with preemption and low-latency, the overall throughput of the machine is actually slightly slower. But it feels loads better.

C# and the .NET framework use native code libraries for the GUI. It will never have the same perception of "slowness" that java has.

Re:It does seem any "performance" argument is bogu

[Anonymous Coward]

One other area where java gets a bad rap for being slow is in startup time. I write a lot of small java apps and continually loading the jvm adds about a second to the startup time on my machine. I've gotten around this by creating a RAM disk at startup and copying the jvm executable and jars over. This gets rid of the noticeable startup time. JVMs should come with the option of loading into memory at startup...it would help dispell the myth that java, by nature is too slow.

But you're right about the GUI...that's the single biggest fuck up that Sun made. IBM has done better as SWT comes pretty close to being fully responsive (though it still makes it possible to be unresponsive if you write bad code.)