为JVM实现C＃
有没有人试图为JVM实现C＃？ 作为一名Java开发人员，我一直嫉妒C＃，但不愿意放弃JVM的可移植性和成熟性，更不用说为它提供各种各样的工具了。
我知道JVM和CLR之间有一些重要的区别，但是有没有什么是最好的？
CLR和JVM之间有非常显着的差异。
几个例子：
- Java没有用户定义的值types
- Javagenerics与.NETgenerics完全不同
- C＃的许多方面都依赖于框架元素 – 委托等。即使对于语言方面，也需要移植库。
- Java不支持JVM级别的属性和事件。 你可以伪造一些，但不会是一样的。
- 我不相信即使在JVM级别，Java也没有任何等价于参考传递的参数
- 尽pipe我不确定C＃规范中有多less内存，但是对不同内存模型的微妙处理可能会让人吃惊。
- 一般来说不安全的代码在Java中是不可能的
- 与本地代码的互操作性在JNI和P / Invoke之间是非常不同的。 这对你来说可能不是什么大问题。
- 您必须伪装运算符重载和用户定义的转换
你可能会移植很多的C＃ – 但你会留下一个相当不满意的经验，国际海事组织。
换个angular度来说 ，你知道IKVM吗？ 它允许你在.NET中运行Java代码。
访问http://code.google.com/p/stab-language
下面的代码是用于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); } } } 字节码转发器
蚱蜢可以采取一个CLR字节码，并为JVM进行传输。 主要针对Web应用程序，它不提供例如Windows窗体类的JVM实现。 似乎有些过时，但。 networking讲述了ASP.NET 2.0，Visual Studio 2008等。 首先由@alex提到
XMLVM可以将CLR或JVM字节码作为input并生成输出。 另外它可以输出Javascript或Objective-C。 没有发布，只有Subversion。 “不适用于生产环境的实验开发版本”。
IKVM比OP想要的是另一个方向。 它提供了在CLR上运行的JVM实现，CLR字节码转换器的JVM和Java的CLR库方法存根生成器。 http://www.ikvm.net/uses.html @Jon Skeet提到
RPC
为什么不让CLR和JVM一起运行，并尽可能地使通信无摩擦？ 这不是OP想要的，但是其他一些答案已经以不同的方式出现了，所以我们来讨论一下。
RabbitMQ有一个免费的选项，它是一个用Erlang编写的RPC服务器，带有用于C＃，Java等的API库。
jnBridge ，许可证可能对于一些潜在用户来说太昂贵了。
gRPC和类似的现代RPC库提供了广泛的语言支持，用于这些语言的客户端库的代码生成，用于数据的与语言无关的有线格式，级联呼叫取消等高级function。
编程语言
写一次，到处跑;）
Haxe编译为C＃/ CLR，Java / JVM，Javascript，Flash，Python，…为每种目标语言提供互操作机制。 在某种程度上可以被认为是ActionScript3的继任者。 看起来相当稳固的东西，至less有一家公司实际上依赖于它。 接下来要提到的比Stab更值得信赖。
Stab带来了一些C＃特性和Java互操作性。 不是很有用，你得到了一些C＃特性，但是你所交互的是不使用它们的Java代码。 https://softwareengineering.stackexchange.com/a/132080/45826语言相对隐晦，可能被放弃，很less有希望变得更好。; 首先由@Vns在这里提到。
JVM平台的新鲜空气阵容;）
Scala ， Kotlin等等，都是在JVM之上运行的相当不错的语言，它带来了C＃程序员在Java中可能会错过的特性。 特别是Kotlin在JVM世界中感觉像是一个合理的C＃替代品。 Scala对于程序员来说可能是一个太大的语言，可以在短时间内使用。
单
这当然也是一个select。 如果单声道可以运行，为什么要转换成JVM呢？ 首先由@ferhrosa提到
纽约 – 2014年11月12日 – 微软公司周三强化了对跨平台开发者体验的承诺，开放源代码完整的服务器端.NET堆栈，并将.NET扩展到Linux和Mac OS平台上运行。
根据这篇新闻稿 ，Visual Studio 2015将把Linux / Mono作为一个支持的平台。
这是一个由Mono项目人员撰写的关于它的博客： .NET源代码集成 （2014年11月）。
.NET核心
Microsoft（微软）pipe理的（一些）.Net的Windows / Linux多平台版本。 “nuff说：https：//github.com/dotnet/core 。
结论
现在有必要试一试这些工具/框架，看看有多less摩擦。 OP希望用C＃编写JVM，这可能实际上使用Grasshopper很好。
这样做的目的是在单个代码库中混合使用C＃和Java世界库，可能效果不佳。
来源
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
从IL到字节码编写一个转换器可能会更简单。 这样你就可以自动获得对JVM上任何.NET语言的支持。
但是，这是一个非常明显的想法，如果还没有完成的话，这可能是非常困难的，或者很难做好/有用的。
看蚱蜢 它是一个基于Visual Studio的SDK，并拥有专利的.NET to Java转换器，使您能够在Linux®和其他支持Java的平台上运行.NET Web和服务器应用程序。
在C＃中进行跨平台开发的选项可能是mono： http ： //www.mono-project.com/
这个答案可能会迟到，但这个只是新的。 您可能想要结帐Kotlin编程语言。 除了任何非Java JVM语言之外，它还提供了C＃所具有的语法糖以及最接近C＃语法的语法糖。 它来自JetBrains 。
我可以看到两个原因，为什么这没有得到太多的热情。
首先要认识到的是，就语言的实际function而言，C＃和Java非常接近。 Java不仅与Java密切相关，而且也在朝着类似的方向发展。 有一些JVM目前不支持的function，但这不是真正的问题。 你总是可以伪造缺失的东西。 我认为人们更喜欢等待Java来获得更多的糖，而不是从头开始创build一个几乎是Java的。 在港口准备就绪的时候，Java可能已经决定迎头赶上。
其次，开发人员更喜欢C＃的原因不在于语言本身，而在于围绕它的工具，与C＃的双向关系以及微软如何支持整个事情。 例如，C＃-XAML组合比JavaFX友好，因为C＃和XAML被黑客攻击（例如C＃中的部分类，XAML中的绑定等）。 在JavaFX上使用C＃不会有太大的改进。 为了在JVM上获得C＃的体验，还需要移植工具，这是一个更大的项目。 即使莫诺也不会打扰。
所以，对于想要在熟悉的工具上使用更丰富的语言的Java开发人员，我的build议是检查现有的JVM语言 。
单声道也是一种select，但我一直对此持怀疑态度。 尽pipe它是C＃ – 。NET和跨平台，用微软的工具构build的东西通常不会在Mono上工作。 它本质上是它自己的东西。 现在我们将看到微软表示他们将会合作。
您可以使用源到源编译器将C＃翻译成在JVM上运行的语言。 例如，有几个C＃到Java转换器可以让C＃应用程序在被转换成Java之后在JVM上运行。
