Implementing C# for the JVM

问题:

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?

回答1:

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.

回答2:

Visit http://code.google.com/p/stab-language

The code below if a Stab language code for JVM

using java.lang;
using stab.query;
public class Test {
   public static void main(String[] args) {
   // Sorts the arguments starting with "-" by length and then using the default   
        // string comparison
        var query = from s in Query.asIterable(args)
                    where s.startsWith("-")
                    orderby s.length(), s
                    select s;
        foreach (var s in query) {
            System.out.println(s);
        }
    }
}

回答3:

Bytecode transpilers

Grasshopper can take a CLR bytecode and transpile it for JVM. Intended primarily for web apps, it does not provide e.g. JVM implementation of Windows Forms classes. Seems somewhat dated, though. The web talks about ASP.NET 2.0, Visual Studio 2008 and so on. First mentioned by @alex

XMLVM can take CLR or JVM bytecode as input and produce either as output. Additionally it can output Javascript or Objective-C. No releases yet, only Subversion. "Experimental development version that is not to be used in a production environment."

IKVM goes in the other direction than OP wants. It provides a JVM implementation running on CLR, a JVM to CLR bytecode transpiler and a CLR library method stub generator for Java. http://www.ikvm.net/uses.html Mentioned by @Jon Skeet

RPC

Why not have CLR and JVM running alongside and make the communication as much frictionless as possible? This is not what the OP wants, but some other answers are already quite off topic in different ways, so let's cover it.

RabbitMQ, has a free option, it is a RPC server written in Erlang with API libraries for C#, Java and more.

jnBridge, the licence may be too expensive for some prospective users.

gRPC, and similar modern RPC libraries offer wide language support, code generation for client libraries in these languages, language independent wire format for data, advanced features like cascading call-cancellation and so on.

Programming languages

Write once, run everywhere ;)

Haxe, compiles to C#/CLR, Java/JVM, Javascript, Flash, Python, … Provides interop mechanisms for each of the target languages. Can be thought about as an ActionScript3 successor to some degree. Seems pretty solid stuff, with at least one company actually depending on it. Much more trustworthy than Stab, mentioned next.

Stab brings some C# features and Java interoperability. Not very useful, you get some C# features, but what you interact with is Java code which does not use them. https://softwareengineering.stackexchange.com/a/132080/45826 The language is relatively obscure, possibly abandoned, with little promise to become better. First mentioned here by @Vns.

Gust of fresh air for the JVM platform ;)

Scala, Kotlin, others, are fairly nice languages running on top of JVM which bring features that a C# programmer may miss in Java. Especially Kotlin feels like a reasonable alternative to C# in the JVM world. Scala may be a bit too large language for a programmer to get comfortable with in a short time.

Mono

That is certainly an option too. Why transpile to JVM if Mono can run it as it is. First mentioned by @ferhrosa

NEW YORK — Nov. 12, 2014 — On Wednesday, Microsoft Corp. reinforced its commitment to cross-platform developer experiences by open sourcing the full server-side .NET stack and expanding .NET to run on the Linux and Mac OS platforms.

According to this press release from which the quote comes, Visual Studio 2015 will add Linux/Mono as a supported platform.

This is a blog written by the Mono project people about it, from the other side: .NET Source Code Integration (November 2014).

.NET Core

A Windows/Linux multiplatform version of (some of) .Net governed by Microsoft. 'nuff said https://github.com/dotnet/core.

Conclusion

It would be now necessary to give these tools/frameworks a try and see how much friction there is. The OP wants to write in C# for the JVM, which may actually work quite well using Grasshopper.

Doing this with the goal to mix C# and Java world libraries in a single codebase may not work so well.

Sources

http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop

回答4:

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.

回答5:

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.

回答6:

An option for cross-platform development in C# could be mono: http://www.mono-project.com/

回答7:

You can use a source-to-source compiler to translate C# into a language than runs on the JVM. For example, there are several C# to Java converters that would allow C# applications to run on the JVM after being translated into Java.

回答8:

This answer may be late for you, but this one is just new. You may want to checkout Kotlin programming language. It offers the syntactic sugars which C# has and its the closest to C# syntax too, other than any Non-Java JVM language. Its from JetBrains.

回答9:

I can see two reasons why this isn't getting much enthusiasm.

The first thing to realise is that, when it comes to the actual features of the language, C# and Java are very close. Not only are C# amd Java close, they are also moving in similar directions. There are some features that the JVM won't currently support out of the box, but that's not the real problem. You can always fake what is missing. I think people prefer waiting for Java to get some more sugar, than to create an Almost-Java from scratch. By the time the port is ready, Java may have decided to catch up.

Secondly, the reason why developers prefer C# isn't so much the language itself, but the tools around it, their two-way relationship with C# and how Microsoft supports the whole thing. For example, the C#-XAML combo is friendlier than JavaFX, because C# and XAML were hacked for eachother (e.g. partial classes in C#, bindings in XAML and more). Using C# on JavaFX doesn't improve much. To get the C# experience on the JVM, you need to also port the tools, and that's a much bigger project. Not even Mono will bother.

So, my advice to a Java developer, who wants to use a fancier language ontop of familiar tools, is to check out the existing JVM languages.

Mono is an option too, but I have always been skeptical of it. Even though it is C#-.NET and cross-platform, things built with Microsoft's tools won't generally work on Mono. It is essentially its own thing. We'll see what happens now that Microsoft said they'll be collaborating.