Re: Generics and different interpretations of backwards compatibility

When backward compatibility is mentioned about Java releases, it means that the bytecode is similar to old releases. So new compilers will not generate bytecode which is new. Just the conversion of code like generics to bytecode will be done by the compiler. Other features also need the compiler to generate code. So the VM as such does not need to recognise any new keywords. So the JVM's do not need to change the core.

So what you're saying is that the bytecode that was designed back when Java first came out is set and won't be changed for stuff like generics? And the class file that is generated won't have anything that can't be recognized by previous VMs?

In .NET on the other hand newer bytecode keywords might have been added. So running that code will require different changes in the VM.

This is what I understand. I guess there will have to be changes to the IL and assembly metadata when compiling new features like generics. So you can't load it on previous CLR versions.

Which do you think is better??

I've always understood "backwards compatibility" to mean "be able to run older code on newer platforms without making any changes". This gives you the freedom to make any improvements you want to new stuff as long as older stuff works. And this is what .NET is doing.

Somehow Java is trying to do both things... backwards and forwards. Run old code on newer JVM without problem, and also run newer code on older JVM. But this second part has a catch - you can only use the old APIs. If you want to use new features like API improvements and generics, you will need the newer VM and APIs. I don't see the point. One argument is, there will be a larger installed base, but I mean, you can't use new features so just work with previous APIs and VM.

I'm still confused about something... can you clarify. Is VM and Java API completely separate? So can you use VM 1.5 with API 1.4? I believe this can be done with .NET. If you have the newest version of the CLR, you can use all previous API versions. They plan to have only one CLR in Longhorn.