Implementing C# for the JVM

Viewed 28744

Is anyone attempting to implement C# for the JVM? As a Java developer, I've been eyeing C# with envy, but am unwilling to give up the portability and maturity of the JVM, not to mention the diverse range of tools for it.

I know there are some important differences between the JVM and CLR but is there anything that is a showstopper?

9 Answers

There are very significant differences between the CLR and the JVM.

A few examples:

  • Java doesn't have user-defined value types
  • Java generics is completely different to .NET generics
  • Many aspects of C# depend on elements of the framework - delegates etc. You'd need to port the library as well, even for language aspects.
  • Java doesn't support things like properties and events at a JVM level. You could fake some of this, but it wouldn't be the same.
  • I don't believe Java has any equivalent to pass-by-reference parameters, even at the JVM level
  • Subtleties to do with the different memory models would quite possibly bite, although I'm not sure how much is in the C# spec.
  • Unsafe code in general probably isn't possible in Java
  • Interoperability with native code is very different between JNI and P/Invoke. This probably isn't much of a problem for you.
  • You'd have to fake operator overloading and user-defined conversions

You could probably port a lot of C# - but you'd be left with a pretty unsatisfactory experience, IMO.

Going the other way, are you aware of IKVM? It allows you to run Java code in .NET.

It might be simpler to write a converter from IL to bytecode. That way you'd automatically get support for any .NET language on the JVM.

However, this is such an obvious idea that if this hasn't already been done, it's probably extremely hard, or hard to do well/usefully.

Look at Grasshopper. It is a Visual Studio-based SDK and patented .NET to Java converter that enables you to run .NET Web and server applications on Linux® and other Java-enabled platforms.

Related