有没有人正在尝试为JVM实现C#?作为一名Java开发者,我一直对C#虎视眈眈,但不愿放弃JVM的可移植性和成熟性,更不用说其多样化的工具库了。
我知道JVM和CLR之间存在一些重要的差异,但是有没有什么因素是无法解决的?
有没有人正在尝试为JVM实现C#?作为一名Java开发者,我一直对C#虎视眈眈,但不愿放弃JVM的可移植性和成熟性,更不用说其多样化的工具库了。
我知道JVM和CLR之间存在一些重要的差异,但是有没有什么因素是无法解决的?
访问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);
}
}
}
Grasshopper 可以将CLR字节码转换为JVM字节码。主要用于Web应用程序,但不提供例如Windows Forms类的JVM实现。看起来有点过时了。网络上谈论的是ASP.NET 2.0、Visual Studio 2008等等。最初由@alex提到。
XMLVM 可以将CLR或JVM字节码作为输入,并产生相应的输出。此外,它还可以输出Javascript或Objective-C。目前仅有Subversion版本,没有正式发布版。"试验性开发版本,不适合在生产环境中使用。"
IKVM 的功能与OP所需的方向相反。它提供了一个在CLR上运行的JVM实现,一个JVM到CLR字节码的转换器和一个为Java生成CLR库方法存根的CLR库。http://www.ikvm.net/uses.html 由@Jon Skeet提到。
为什么不让CLR和JVM并行运行,并尽可能使通信无摩擦?这不是OP想要的,但其他一些答案已经以不同的方式离题了,所以让我们来谈论一下。
RabbitMQ,有一个免费选项,它是用Erlang编写的RPC服务器,具有C#,Java等API库。
jnBridge,许可证对于一些潜在用户来说可能太昂贵了。
gRPC和类似的现代RPC库提供广泛的语言支持,在这些语言中生成客户端库的代码生成器,数据的独立于语言的传输格式,高级功能如级联调用取消等。
一次编写,到处运行 ;)
Haxe编译成C#/CLR、Java/JVM、Javascript、Flash、Python等,为每种目标语言提供互操作机制。在某种程度上可以看作是ActionScript3的继承者。似乎非常可靠,至少有一家公司实际上依赖它。比下面提到的Stab要可信得多。 Stab带来了一些C#功能和Java互操作性。不是很有用,你会获得一些C#功能,但你与之交互的是不使用这些功能的Java代码。该语言相对较为晦涩,可能已经被放弃,没有变得更好的承诺。最初由@Vns提到。 为JVM平台带来了一股清新的空气;)Scala,Kotlin等语言是运行在JVM上的非常好的语言,它们带来了一些C#程序员在Java中可能会错过的功能。特别是Kotlin在JVM世界中感觉像是一个合理的替代品。Scala可能对于一个程序员来说太大了,在短时间内难以适应。
这当然也是一个选择。如果Mono可以直接运行,为什么要转换成JVM呢。首先由@ferhrosa提到。
纽约 — 2014年11月12日 — 微软公司周三通过开源整个服务器端.NET堆栈并将.NET扩展到Linux和Mac OS平台,加强了跨平台开发者体验方面的承诺。
根据这篇新闻稿,Visual Studio 2015将添加对Linux/Mono的支持。
这是Mono项目人员关于.NET源代码集成的博客(2014年11月)。
这是由Microsoft管理的Windows/Linux多平台版本的.Net的一部分。详情请查看https://github.com/dotnet/core。
现在需要尝试使用这些工具/框架,看看是否存在阻力。原作者想要在JVM中使用C#编写代码,使用Grasshopper可能会非常不错。
但如果目标是将C#和Java世界的库混合在一个代码库中,可能效果不太好。
参考资料
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
编写从IL到字节码的转换器可能会更简单。这样,您将自动获得对JVM上任何.NET语言的支持。
然而,这是一个如此明显的想法,如果还没有完成,那么它可能非常困难,或者很难做得好/有用。
看看Grasshopper。它是一个基于Visual Studio的SDK和专利的.NET到Java转换器,可让您在Linux®和其他支持Java的平台上运行.NET Web和服务器应用程序。
我可以看到这个项目没有得到太多的热情,原因有两个。
首先需要认识到的是,在语言的实际特性方面,C# 和 Java 非常接近。C# 和 Java 不仅很接近,而且它们也朝着类似的方向发展。虽然 JVM 目前不支持某些功能,但这并不是真正的问题。你总是可以模拟缺少的部分。我想人们更喜欢等待 Java 得到更多的改进,而不是从头开始创建一个几乎和 Java 相同的东西。当移植准备好时,Java 可能已经赶上了。
其次,开发人员更喜欢使用 C# 的原因并不是它本身,而是围绕它的工具、与 C# 的双向关系以及微软对整个事情的支持。例如,C#-XAML 组合比 JavaFX 更加友好,因为 C# 和 XAML 是互相匹配的(例如,C# 中的 partial classes,在 XAML 中的 bindings 等)。在 JavaFX 上使用 C# 并不能带来太多改进。要在 JVM 上获得 C# 的体验,您需要将工具也移植过来,这是一个更大的项目。甚至 Mono 也不会费心去做。
因此,我对想要在熟悉的工具之上使用更高级语言的Java开发人员的建议是查看现有的JVM语言。
Mono也是一个选择,但我一直对它持怀疑态度。尽管它是C#-.NET和跨平台的,但使用Microsoft的工具构建的东西通常不会在Mono上运行。它本质上是自己的东西。我们将看到微软表示他们将进行合作后会发生什么。