# Thursday, 05 September 2002
« No Title | Main | No Title »
No Title


Yesterday, Microsoft Research released a beta version of Gyro, which is their implementation of generics for Rotor.

I downloaded it this morning and played with it, and I must say, it's great! This is going to be the killer feature for .NET (once the commercial platform gets it). Unlike the platform that starts with a J, this is actually done right. The Java generics proposal that was floated for 1.4 and then withdrawn was an ugly (nay, disgusting) hack. Gyro is beautiful, I have no other word for it.

I can't wait for this to appear in the commercial platform!

Thursday, 05 September 2002 18:43:29 (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
Thursday, 05 September 2002 10:30:13 (W. Europe Daylight Time, UTC+02:00)

Which proposal for Java was that?

I only know of the proposal by Odersky and Wadler who experimented with the Pizza and GJ
java extensions. I liked that very much. It seemed like a clean extension of java
(the language) only array support was a little bit hacked I believe. One drawback was
that it was based on the existing byte code representation because they wanted to be
backward compatible with old systems but it seemed like it was easy to implement cleanly
if you wanted to break with old byte code (which is reasonable for gcj for example since
that already compiles to native code anyway).

How is this generics extension better than that proposed by Oderski and Wadler?

Friday, 06 September 2002 13:47:52 (W. Europe Daylight Time, UTC+02:00)

The jsr is available at http://www.jcp.org/jsr/detail/14.jsp

A few things that are wrong with it:
- it breaks static type safety
- inefficient
- no runtime type information (generics are based on erasure)
- no support for value types

Gyro has none of these limitations.

Friday, 06 September 2002 09:56:30 (W. Europe Daylight Time, UTC+02:00)

I had a little email exchange with Jeroen about this (in Dutch)
that I like to summarise.
(Jeroen will surely correct my if this is not how he sees it.)

We agree that java byte code is far from ideal to represent generic types
(and to represent non-java object oriented languages in general).
CIL is much nicer especially with the generics extension proposed in the paper
that Jeroen referenced. But since the authors admit that this extension is still
not powerful enough to model the (higher-order) types used in Mercury or Haskell
I don't think this will be the be all/end all of type/byte code systems.
(Which reminds me that I have to check out Parrot <http://www.parrotcode.org/>.)

On a java byte code level Jeroen is right that you lose type safety and efficiency.
But Wadler and Odersky do propose a way to add the type information to a class file
(you will have to add support in the VM and compiler to actually read it). But I think
on the Java programming language level the Generic Types proposal is very nice and
if you ignore java byte code it can certainly be implemented type safe and efficient.
(Although Jeroen told be about boxing/unboxing of primitive (and user defined) types,
which would be very nice to have.)

For people wanting to know more about Generic Java:

Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview