我的公司有一个庞大的C＃代码库。超过一半的代码是我们创建，阅读，修改，计算和编写Excel工作簿的核心引擎。我们经常从客户和潜在客户那里得到问题，询问我们是否要构建我们引擎的Java版本 - 其中许多人对UI都不感兴趣。我们甚至有一些客户在他们的Java应用程序中使用我们的.NET库时遇到了麻烦。
因此，我们希望构建一个Java版本的核心引擎，理想情况下不需要维护单独的Java源代码库。
Eric Sink described this problem非常好。除了我们的软件许可包含免版税部署这一事实外，我处于类似的位置，这使得Eric选择Mainsoft对我们来说是不可能的。
几年来，我每隔几个月一直在搜索"c# to jvm"这样的人，但没有任何喜悦。花了大约7年时间开发类似的Java软件，我相信我们在核心引擎中使用的.NET API可以轻松封装，我们可以使用Java库完成我们所需的一切。所以，如果我们只有一个C＃ - ＆gt; JVM编译器我们可以构建我们的Java核心引擎，我们不再需要拒绝那些想要使用它的Java开发人员。
我不是要求Sun为什么不做C＃编译器的技术原因。我认识到Java没有属性或无符号64位长等等......为了论证，只需假设所有这些技术问题都可以通过扩展JVM和/或其他方法来处理。
我并没有要求再讨论为什么一种语言/堆栈可能比另一种语言/堆栈更好。我们业务的现实是有很多潜在客户使用它们。
在Java平台上更轻松地运行C＃代码意味着更多开发人员和更多平台软件。对平台的成功有什么更重要的吗？ Jonathan Schwartz是一个软件人。我会把它留给比我更聪明的人来决定他是否担任Sun的总裁兼首席执行官，但是在他加入Sun之后不久就遇到了Jonathan，我的印象是他了解软件以及对大型软件的需求开发人员基础。
必须有充分的理由。我不能为我的生活弄清楚它是什么......
答案 0 :(得分：37)
首先，Sun没有动力在JVM上实现C＃编译器，因为它们具有非常相似的称为Java编程语言的东西。
它也不像实现编译器那么简单，因为Java标准类库与.net基类库不同。您最终必须将所有.NET API调用更改为Java API调用。
Micrsoft有一个名为J＃的产品，用于Java到.NET的转换，但最终没有人使用它，因为API仅限于Java 2之前的API，因此它几乎没用。如果Sun实现了.NET BCL的部分内容，那将是相同的，因为只有它的核心部分是标准化的和免版税的。像ASP.NET和WPF，WCF等部分不是ECMA标准的一部分，所以Sun需要微软的许可才能实现这些API。
如果有足够多的客户希望java版本具有商业意义，将您的应用程序移植到java，那么就可以通过C＃到JVM编译器从Sun获得任何帮助。
答案 1 :(得分：20)
Microsoft 为什么不对C＃进行Java字节码编译？为什么不你呢？每一方都有公开的规格......
答案 2 :(得分：20)
Joe Erickson写道：
更容易在C＃上运行C＃代码 Java平台意味着更多开发者 以及该平台的更多软件。
这是一个不真实的陈述。在JVM上运行C＃代码不会创建Java程序员，它会创建可以在JVM上执行的C＃程序员。它只扩展了C＃的范围，假设JVM还将任何微软特定的调用（即win32）转换为平台中立的东西。因此，如果Sun将IL转换为Java字节码，那么它唯一可以帮助的是：Microsoft。而且，鉴于Sun在最初的C＃-Java分裂/ Visual J ++诉讼中与微软的历史......
另外，无论您是否愿意，您都必须面对技术上的不可行性。字节码的执行方式存在根本区别，这些问题远比是否存在无符号长数据类型更重要。
如果您必须在非Microsoft平台上安装C＃，请使用Mono
答案 3 :(得分：14)
“因此，我们希望构建一个Java版本的核心引擎，理想情况下不需要维护单独的Java源代码库。”
基本上，您希望编译未修改的C＃代码，并使其在仅Java环境中运行。
IKVM 不是你想要的。 IKVM是three main things。
一个。 ikvm - Java虚拟机的CLI实现（注意Java类库的this uses Classpath（现在是OpenJDK））。
湾ikvmc - 将java字节码编译为CLI字节码。
℃。 ikvmstub - 生成调用CLI代码的java存根类。
请注意，所有这些工具都依赖于运行时的CLI。你想要的只是IKVM的反面，当然是MVKI（最尊敬的Kompiler中介）:)：
一个。 mvki - CLI虚拟机的Java实现（可能会使用Mono或DotGNU作为类库。）
湾mvkic - 将CLI字节码编译为Java字节码。
℃。 mvkistub - 生成调用Java
的CLI存根类请注意，这些都不需要在运行时现有的.NET Framework实现，因此它们应该让您的Java客户满意。
不幸的是，据我所知MVKI不存在，所以你最好做一个手动端口（虽然工作量更大，但不可避免地更干净。）
编辑：基于Mainsoft的the description，它似乎与MVKI相似，但我不确定他们为类库做了什么，与IKVM不同，它不是FOSS。
答案 4 :(得分：10)
http://jsc.sourceforge.net/是一个c＃交叉编译器，可以将.NET代码转换为Java（以及其他内容）。
答案 5 :(得分：6)
将您的.NET API公开为ASMX Web服务，您应该好好去。
编辑：对于更多繁重的使用场景，值得研究Windows Communication Foundation（WCF）。它具有内置的可配置支持，可用于安全性，流式传输，不同的传输方案（HTTP，TCP / IP，本地命名管道）。您不仅限于SOAP消息编码，但这可能是与Java互操作的最简单方法。
我对你的确切场景不太确定，但是如果你正在处理大文件并且.NET代码和Java代码都在本地运行，你可以使用.NET将文件保存到用户的硬盘上。然后从Java应用程序中获取它。
答案 6 :(得分：3)
我想知道Mono项目是否可以通过定位JVM而不是从头开发和维护自己的虚拟机来减少自己的工作量。开发工作可能集中在C＃交叉编译器上，并将.NET库的洁净室实现移植到JVM。有点像Mainsoft所做的开源版本。然后，您可以在同一JVM中启用Java和C＃代码之间的语言间调用，并部署使用C＃编写的Applet和Java Web Start应用程序。
答案 7 :(得分：3)
必须有充分的理由。我不能为我的生活弄清楚它是什么......
很容易相信公司是非营利组织，它们关注您的利益。人们很容易忘记，上市公司的唯一目的是为股东赚钱。这是一项法律义务，如果股东不相信他们没有这样做，董事/高管就会被解雇/被起诉。
Sun使Java免费，因为它有助于销售他们的硬件，从而从Java赚钱。 IBM使Java免费，因为它可以帮助他们在咨询方面赚更多钱。
如果Sun要在C＃转换器上花钱，它将如何赚回来并赚取利润。想象一下，你必须说服Sun的股东。如果可以，Sun将制作一个C＃转换器。
答案 8 :(得分：1)
我知道这可能不是你想要的，但是这里有一些可能的选择（如果没有你）可能对其他人有用。
C：您可以尽可能多地移植到C.现在您可以使用C＃和Java（以及任何其他可以与C通信的语言）创建一个包装器，使其在编程时感觉自己的语言。现在的问题是你（或者他们，根据你的许可证）必须为每个平台构建C部分。
Fantom*：一种编程语言，根据其主页， 是：
- Portable：在浏览器中编写可移植到Java VM，.NET CLR和JavaScript的代码。
- 熟悉：语法Java和C＃程序员会对Fantom的进化语法感到宾至如归。
- 面向对象：来自Obj的所有子类。需要性能时的值类型。
- 功能：烘焙功能和封闭。
- 静态和动态类型：不喜欢极端 - 走在路中间。
Haxe * :(发音为hex）是跨平台语言，可编译为其他语言。很快将支持C＃和Java。它目前支持：
Javascript：您可以将Haxe程序编译为单个.js文件。您可以使用自动完成功能访问键入的浏览器DOM API 支持，所有依赖项将在编译时解决 时间。
Flash：您可以将Haxe程序编译为.swf文件。 Haxe与闪存播放器6到10兼容，具有“旧”Flash 8 API 或最新的AS3 / Flash9 + API。 Haxe提供非常好的性能 用于开发Flash内容的语言功能。
NekoVM：您可以将Haxe程序编译为NekoVM字节码。这可以用于服务器端编程，例如动态网页 （使用mod_neko for Apache）以及命令行或桌面 应用程序，因为NekoVM可以嵌入和扩展一些 其他DLL。
PHP：您可以将Haxe程序编译为.php文件。这将使您能够使用高级严格类型的语言，如haXe 同时保持与现有服务器平台的完全兼容性 和图书馆。
C ++：您现在可以使用所需的Makefile从Haxe源代码生成C ++代码。这对于创建本机非常有用 应用程序，例如在iPhone开发中。
Haxe社区。 （2011年3月11日）。 Haxe简介。 2011年1月29日检索自http://old.haxe.org/doc/intro
您可以详细了解Haxe有用的原因here。
*我从未使用过这种语言，我不知道这种方法有多好。
答案 9 :(得分：0)
如果我正在做跨平台跨语言支持之类的事情，我会创建一个'common api'，因为语法类似于语法，你可以很容易地使翻译器。然后，不是直接从核心调用java或.net apis，而是调用你的'common api'，它将重新实现你需要的java和.net apis。通过这种方式，您可以创建一个跨语言沙箱。由于java和c＃的主要区别是对象定义，我会通过反映C＃dll来获得那些，然后重构构造，然后很容易让解释器运行并实现函数体并将属性转换为getter setters已经知道文件的结构。这当然是假设.net 2.0，3.0和3.5中的一些功能变得非常难以“解释”
这将是复杂的，但可能不像手工重建java中的核心那么复杂，并且必须有2个团队单独处理它们。如果这个想法激发了一些灵感，我可能会创造一个。我真的很想看到一个更简单稳定的单声道安装mac。
基本上我认为基于一组常见api类的代码级解释器可以在一到两周内与团队一起编写。
答案 10 :(得分：0)
我认为您会发现Mainsoft, Enterprise Edition工具允许您在Java JVM下运行大多数/可能所有的.NET代码 ...似乎更专注于ASP。 NET但会允许C＃。它已经有一段时间了，可惜他们没有更好地宣传它！
警告模糊如下......
Mainsoft®是Java-.NET 支持互操作性的软件 移动的IT组织 支持Java的平台，例如Linux 同时保留现有投资 在.NET代码和技能。该软件 无缝集成到Visual Studio®开发环境， 启用C＃和Visual Basic 开发人员迅速发展和 维护服务器和Web应用程序 在Windows，Java EE平台上运行 或两者，从而减少应用 开发和维护成本， 生产时间和总成本 所有权。
答案 11 :(得分：0)
简单。因为Sun宁愿不被微软起诉。虽然我们作为程序员可能看不到诉讼的可行理由，但请记住，微软是一家比Sun更大的公司，并且有能力让他们老去。
幸运的是，Sun公司处于比微软更开放的地位。如果存在这样的需求，无论是开源还是第三方都可以使这个Java和Sun的编译器不需要加热。答案 12 :(得分：0)
JACIL是一个显然已经死亡的项目，试图与IKVM相反。也许一些有动力的人可以将它作为可行的.Net到JVM编译器的起点。
答案 13 :(得分：0)
答案 14 :(得分：0)
我想更好的问题是为什么不你将C＃写入Java字节码编译器，如果你想要存在的话。等待企业霸主做某事是个坏主意。
建议创建这样的实现：采用Mono或.GNU的C＃前端。不要费心写自己的。
答案 15 :(得分：0)
您可以在同一个解释器中运行您的.NET代码和Java代码！有关示例用例，请参阅IKVM基于.NET的JVM和Boo and Java wiki页面（使用基于.NET的Boo语言编写使用Java库的应用程序）。
答案 16 :(得分：0)
我做了一个应该真正答案的评论：
此时在技术上不可能在JVM上实现C＃规范。 C＃支持指针，无符号类型，用户定义的值类型，真正的泛型，按引用传递以及其他内容的加载。对于类似C＃的JVM语言，请查看Stab。
Mainsoft假装它。我相信他们需要付出巨大的努力。
答案 17 :(得分：0)
玩得开心。