为 JVM 实现 C#

Implementing C# for the JVM

提问by Rob

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.

是否有人试图为 JVM 实现 C#？作为 Java 开发人员，我一直羡慕 C#，但不愿放弃 JVM 的可移植性和成熟度，更不用说它的各种工具了。

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

我知道 JVM 和 CLR 之间有一些重要的区别，但有什么是引人注目的吗？

采纳答案by Jon Skeet

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

CLR 和 JVM 之间存在非常显着的差异。

A few examples:

几个例子：

• Java doesn't have user-defined value types
• Java generics is completelydifferent 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 languageaspects.
• 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

• Java 没有用户定义的值类型
• Java 泛型与 .NET 泛型完全不同
• C# 的许多方面都依赖于框架的元素 - 委托等。您还需要移植库，即使是语言方面。
• Java 不支持 JVM 级别的属性和事件之类的东西。你可以伪造其中的一些，但它不会是一样的。
• 我不相信 Java 有任何等效于通过引用传递的参数，即使在 JVM 级别
• 尽管我不确定 C# 规范中有多少，但与不同内存模型有关的微妙之处很可能会引起注意。
• 不安全的代码一般在 Java 中可能是不可能的
• JNI 和 P/Invoke 与本机代码的互操作性非常不同。这对你来说可能不是什么大问题。
• 您必须伪造运算符重载和用户定义的转换

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

你可能会移植很多C# - 但是你会得到非常不满意的体验，IMO。

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

反过来说，你知道IKVM吗？它允许您在 .NET 中运行 Java 代码。

回答by alex

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.

看看蚱蜢。它是一个基于 Visual Studio 的 SDK 和获得专利的 .NET 到 Java 转换器，使您能够在 Linux 上运行 .NET Web 和服务器应用程序？和其他支持 Java 的平台。

回答by Daniel Earwicker

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.

编写从 IL 到字节码的转换器可能更简单。这样，您将自动获得对 JVM 上任何 .NET 语言的支持。

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.

然而，这是一个如此明显的想法，如果这还没有完成，它可能非常困难，或者很难做好/有用。

回答by Vns

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

访问http://code.google.com/p/stab-language

The code below if a Stab language code for JVM

下面的代码是 JVM 的 Stab 语言代码

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);
        }
    }
}

回答by ferhrosa

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

C# 跨平台开发的一个选项可能是单声道：http: //www.mono-project.com/

回答by user7610

Bytecode transpilers

字节码转译器

Grasshoppercan 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

Grasshopper可以获取 CLR 字节码并将其转译为 JVM。主要用于 Web 应用程序，它不提供例如 Windows 窗体类的 JVM 实现。不过好像有点过时了。网络谈论 ASP.NET 2.0、Visual Studio 2008 等。@alex 首先提到

XMLVMcan 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."

XMLVM可以将 CLR 或 JVM 字节码作为输入并生成其中之一作为输出。此外，它还可以输出 Javascript 或 Objective-C。还没有发布，只有 Subversion。“不得在生产环境中使用的实验性开发版本。”

IKVMgoes 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.htmlMentioned by @Jon Skeet

IKVM朝着 OP 想要的另一个方向发展。它提供了一个在 CLR 上运行的 JVM 实现、一个 JVM 到 CLR 字节码转译器和一个用于 Java 的 CLR 库方法存根生成器。http://www.ikvm.net/uses.html@Jon Skeet 提到

RPC

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.

为什么不让 CLR 和 JVM 并行运行并使通信尽可能顺畅？这不是 OP 想要的，但其他一些答案已经以不同的方式偏离主题，所以让我们来介绍一下。

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

RabbitMQ，有一个免费选项，它是一个用 Erlang 编写的 RPC 服务器，带有用于 C#、Java 等的 API 库。

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

jnBridge，对于一些潜在用户来说，许可证可能太贵了。

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.

gRPC和类似的现代 RPC 库提供广泛的语言支持、使用这些语言为客户端库生成代码、数据的语言独立线格式、级联调用取消等高级功能等。

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.

Haxe，编译为 C#/CLR、Java/JVM、Javascript、Flash、Python ……为每种目标语言提供互操作机制。在某种程度上可以被认为是 ActionScript3 的继承者。看起来非常可靠的东西，至少有一家公司实际上依赖它。比Stab 更值得信赖，接下来会提到。

Stabbrings 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/45826The language is relatively obscure, possibly abandoned, with little promise to become better. First mentioned here by @Vns.

Stab带来了一些 C# 特性和 Java 互操作性。不是很有用，您会获得一些 C# 功能，但是您与之交互的是不使用它们的 Java 代码。https://softwareengineering.stackexchange.com/a/132080/45826该语言相对晦涩，可能已被废弃，几乎没有希望变得更好。@Vns首先在这里提到。

Gust of fresh air for the JVM platform ;)

JVM 平台的新鲜空气;)

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.

Scala、Kotlin等是运行在 JVM 之上的相当不错的语言，它们带来了 C# 程序员在 Java 中可能会错过的功能。特别是 Kotlin 感觉像是 JVM 世界中 C# 的合理替代品。对于程序员来说，Scala 可能是一种太大的语言，无法在短时间内适应。

Mono

单核细胞增多症

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

这当然也是一种选择。如果 Mono 可以按原样运行它，为什么要转换为 JVM。@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.

纽约 — 2014 年 11 月 12 日— 周三，微软公司通过开源完整的服务器端 .NET 堆栈和扩展 .NET 以在 Linux 和 Mac OS 平台上运行，加强了其对跨平台开发人员体验的承诺。

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

根据引用的新闻稿，Visual Studio 2015 将添加 Linux/Mono 作为支持的平台。

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

这是 Mono 项目人员写的一篇关于它的博客，来自另一边：.NET 源代码集成（2014 年 11 月）。

.NET Core

.NET 核心

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

由 Microsoft 管理的（部分）.Net 的 Windows/Linux 多平台版本。'nuff 说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.

现在有必要尝试一下这些工具/框架，看看有多少摩擦。OP 想用 C# 为 JVM 编写代码，实际上使用 Grasshopper 可能会很好地工作。

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

这样做的目标是在单个代码库中混合 C# 和 Java 世界库可能效果不佳。

Sources

来源

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

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

回答by LEMUEL ADANE

This answer may be late for you, but this one is just new. You may want to checkout Kotlinprogramming 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.

这个答案对你来说可能晚了，但这个答案是新的。您可能想查看Kotlin编程语言。除了任何非 Java JVM 语言之外，它提供了 C# 所具有的语法糖，也是最接近 C# 语法的语法糖。它来自JetBrains。

回答by Chris

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.

首先要意识到的是，就语言的实际特性而言，C# 和 Java 非常接近。C# 和 Java 不仅接近，它们也在朝着类似的方向发展。有一些 JVM 目前不支持开箱即用的功能，但这不是真正的问题。你总是可以伪造缺少的东西。我认为人们更喜欢等待 Java 获得更多的糖，而不是从头开始创建一个几乎 Java。当端口准备好时，Java 可能已经决定迎头赶上。

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 Monowill bother.

其次，开发人员喜欢 C# 的原因与其说是语言本身，不如说是围绕它的工具、他们与 C# 的双向关系以及 Microsoft 如何支持整个事情。例如，C#-XAML 组合比 JavaFX 更友好，因为 C# 和 XAML 是相互攻击的（例如，C# 中的部分类、XAML 中的绑定等等）。在 JavaFX 上使用 C# 并没有太大改进。要在 JVM 上获得 C# 体验，您还需要移植工具，这是一个更大的项目。甚至Mono也不会打扰。

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.

因此，对于想要在熟悉的工具之上使用更高级语言的 Java 开发人员，我的建议是查看现有的JVM 语言。

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.

Mono 也是一种选择，但我一直对此持怀疑态度。尽管它是 C#-.NET 和跨平台的，但使用 Microsoft 工具构建的东西通常无法在 Mono 上运行。它本质上是它自己的东西。我们将看看现在微软表示他们将合作会发生什么。

回答by Anderson Green

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

您可以使用源到源编译器将 C# 翻译成在 JVM 上运行的语言。例如，有几个C# 到 Java 转换器允许 C# 应用程序在转换为 Java 后在 JVM 上运行。