c# - 为什么 Sun 不做 C# 到 Java 字节码编译器？

Question

我们想在 JVM 上运行我们的 C# 代码

我的公司拥有庞大的 C# 代码库。超过一半的代码是我们创建、读取、修改、计算和编写 Excel 工作簿的核心引擎。我们经常收到来自客户和潜在客户的问题，询问我们是否要构建我们引擎的 Java 版本——他们中的许多人对 UI 根本不感兴趣。我们甚至有一些客户不厌其烦地从他们的 Java 应用程序中使用我们的 .NET 库。

因此，我们希望构建我们核心引擎的 Java 版本，最好不要维护单独的 Java 源代码库。

Eric Sink很好地描述了这个问题。除了我们的软件许可包括免版税部署这一事实之外，我处于类似的位置，这使得 Eric 选择 Mainsoft 对我们来说是不可能的。

几年来，我每隔几个月就在谷歌上搜索“c# to jvm”之类的东西，但没有任何乐趣。我花了大约 7 年时间为 Java 开发类似的软件，我相信我们在核心引擎中使用的 .NET API 可以很容易地封装，并且我们可以使用 Java 库完成我们需要的一切。因此，如果我们只有一个 C# -> JVM 编译器，我们就可以为 Java 构建我们的核心引擎，并且我们不再需要拒绝想要使用它的 Java 开发人员。

我不是问 Sun 不做 C# 编译器的技术原因。我认识到 Java 没有属性或无符号的 64 位长等......为了论证，假设所有这些技术问题都可以通过扩展 JVM 和/或其他方式来处理。

而且我并不是要求就为什么一种语言/堆栈可能比另一种更好进行另一次辩论。我们业务的实际情况是，每个都有大量潜在客户使用。

Sun 为什么要做 C# 编译器？（当然是国际海事组织）

更容易在 Java 平台上运行 C# 代码意味着更多的开发人员和更多的平台软件。平台的成功还有什么比这更重要的吗？Jonathan Schwartz是一名软件专家。我会让比我更聪明的人来决定他是否担任 Sun 总裁兼首席执行官这一不可能的工作，但在乔纳森加入 Sun 后不久与他会面，我的印象是他了解软件以及对大型软件的需求开发人员的基础。

那么为什么 Sun 不做 C# 编译器呢？

美国国立卫生研究院综合症？
斯科特麦克尼利的幽灵？
太多 Java 开发人员不喜欢或不信任与 Microsoft 相关的任何东西？
他们同意不作为花大价钱的一部分？
？？？

一定有充分的理由。我只是无法为我的生活弄清楚它是什么......

score 38 · Accepted Answer

首先，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 需要 Microsoft 的许可才能实现这些 API。

如果有足够多的客户想要一个具有商业意义的 Java 版本来将您的应用程序移植到 Java，那么就去做，那么您将永远不会通过 C# 到 JVM 编译器从 Sun 获得任何帮助。

score 21 · Accepted Answer

乔·埃里克森写道：

更容易在 Java 平台上运行 C# 代码意味着更多的开发人员和更多的平台软件。

这是一个不真实的说法。在 JVM 上运行 C# 代码不会创建 Java 程序员，它会创建可以在 JVM 上执行的 C# 程序员。它只是扩展了 C# 的范围，假设 JVM 还将任何 microsoft 特定调用（即 win32）转换为平台中立的东西。因此，如果 Sun 将 IL 转换为 Java 字节码，那么它所帮助的唯一群体就是：Microsoft。而且，考虑到 Sun 在最初的 C#-Java 分裂/Visual J++ 诉讼中与微软的历史......

另外，无论您愿意与否，您都必须面对技术上的不可行性。字节码的执行方式存在根本差异，这比是否存在无符号长数据类型更为重要。

如果您必须在非 Microsoft 平台上使用 C#，请使用Mono

score 21 · Accepted Answer

为什么微软不做 C# to Java 字节码编译器？你为什么不做呢？每边都有开放规格...

score 14 · Accepted Answer

“因此，我们希望构建我们核心引擎的 Java 版本，最好不要维护单独的 Java 源代码库。”

基本上，您希望编译未修改的 C# 代码，并让它在纯 Java 环境中运行。

IKVM不是你想要的。 IKVM是三个主要的东西。

一种。ikvm - Java 虚拟机的 CLI 实现（请注意，这使用~~Classpath~~（现在是 OpenJDK）作为 Java 类库）。

湾。ikvmc - 将 java 字节码编译为 CLI 字节码。

C。ikvmstub - 生成调用 CLI 代码的 java 存根类。

请注意，所有这些工具在运行时都依赖于 CLI。你想要的和 IKVM 完全相反，当然是 MVKI (Most Venerable Kompiler Intermediary) :)：

一种。mvki - CLI 虚拟机的 Java 实现（大概这将使用Mono或DotGNU作为类库）。

湾。mvkic - 将 CLI 字节码编译为 Java 字节码。

C。mvkistub - 生成调用 Java 的 CLI 存根类

请注意，这些都不需要 .NET Framework 在运行时的现有实现，因此它们应该会让您的纯 Java 客户满意。

不幸的是，据我所知 MVKI 不存在，所以你最好做一个手动端口（这将不可避免地更清洁，尽管更多的工作）。

编辑：根据Mainsoft的描述，它似乎类似于 MVKI，但我不确定它们对类库做了什么，而且与 IKVM 不同，它不是 FOSS。

score 10 · Accepted Answer

http://jsc.sourceforge.net/是 ac# 交叉编译器，可以将 .NET 代码转换为 Java（除其他外）。

score 7 · Accepted Answer

将您的 .NET API 公开为 ASMX Web 服务，您应该一切顺利。

编辑：对于更频繁使用的场景，值得研究 Windows Communication Foundation (WCF)。这具有对安全性、流式传输、不同传输方案（HTTP、TCP/IP、本地命名管道）的内置、可配置支持。您不仅限于 SOAP 消息编码，但这可能是与 Java 互操作的最简单方法。

我不太确定您的确切情况，但是如果您正在处理大文件并且 .NET 代码和 Java 代码都在本地运行，您可以使用 .NET 将文件保存到用户的硬盘驱动器然后获取它来自您的 Java 应用程序。

score 3 · Accepted Answer

一定有充分的理由。我只是无法为我的生活弄清楚它是什么......

很容易相信，公司是非营利组织，以您的利益为重。很容易忘记，上市公司的唯一目的是为股东赚钱。这是一项法律义务，如果股东不相信他们没有这样做，董事/行政人员将被解雇/起诉。

Sun 之所以免费提供 Java，是因为它有助于销售他们的硬件，而这正是它通过 Java 赚钱的方式。IBM 免费提供 Java 是因为它可以帮助他们在咨询中赚到更多的钱。

如果 Sun 将钱花在 C# 转换器上，它将如何收回这笔钱并获利。想象一下，您必须说服 Sun 的股东。如果可以，Sun 将制作一个 C# 转换器。

score 3 · Accepted Answer

我想知道 Mono 项目是否可以通过针对 JVM 而不是从头开始开发和维护自己的虚拟机来减少自己的工作量。开发工作可能集中在 C# 交叉编译器和将 .NET 库的无尘室实现移植到 JVM 上。有点像 Mainsoft 所做的开源版本。然后，您可以在同一 JVM 中启用 Java 和 C# 代码之间的语言间调用，并部署用 C# 编写的 Applet 和 Java Web Start 应用程序。

score 2 · Accepted Answer

我知道这可能不是您想要的，但这里有一些可能的替代方案（如果不是对您而言）可能对其他人有用。

C：你可以尽可能多地移植到 C。现在你可以用 C# 和 Java（以及任何其他可以与 C 通信的语言）制作一个包装器，让它在编程时感觉与他们的语言是原生的。现在的问题是您（或他们，取决于您的许可证）必须为每个平台构建 C 部分。
Fantom*：一种编程语言，根据他们的主页，是：
- 可移植性：编写可移植到浏览器中的 Java VM、.NET CLR 和 JavaScript 的代码。
- 熟悉：语法 Java 和 C# 程序员会对 Fantom 的进化语法感到熟悉。
- 面向对象：Obj 的所有子类。需要性能时的值类型。
- 函数式：函数和闭包被嵌入。
- 静态和动态类型：不喜欢极端 - 走中间路线。
Haxe *：（发音为 hex）是编译成其他语言的跨平台语言。很快将支持 C# 和 Java。目前支持：
- Javascript：您可以将 Haxe 程序编译为单个 .js 文件。您可以访问具有自动完成支持的类型化浏览器 DOM API，所有依赖项都将在编译时解析。
- Flash：您可以将 Haxe 程序编译为 .swf 文件。Haxe 与 Flash Player 6 到 10 兼容，具有“旧”Flash 8 API 或最新的 AS3/Flash9+ API。Haxe 提供了非常好的性能和语言特性来开发 Flash 内容。
- NekoVM：您可以将 Haxe 程序编译为 NekoVM 字节码。这可用于服务器端编程，例如动态网页（使用 mod_neko 用于 Apache），也可用于命令行或桌面应用程序，因为 NekoVM 可以使用其他一些 DLL 嵌入和扩展。
- PHP：您可以将 Haxe 程序编译为 .php 文件。这将使您能够使用高级严格类型的语言，例如 haXe，同时保持与现有服务器平台和库的完全兼容性。
- C++：您现在可以使用所需的 Makefile 从您的 Haxe 源代码生成 C++ 代码。这对于创建本地应用程序非常有用，例如在 iPhone 开发中。
哈希社区。（2011 年 3 月 11 日）。哈克斯介绍。检索于 2011 年 1 月 29 日，来自http://old.haxe.org/doc/intro

您可以在此处了解有关 Haxe 为何有用的更多信息。

*我从来没有使用过这种语言，我不知道它的效果如何。

score 1 · Accepted Answer

我做了一个真正应该是答案的评论：

目前在 JVM 上实现 C# 规范在技术上是不可能的。C# 支持指针、无符号类型、用户定义的值类型、真正的泛型、按引用传递以及其他内容的加载。对于非常类似于 C# 的 JVM 语言，请查看Stab。

Mainsoft伪造它。我相信这需要他们付出巨大的努力。

score 0 · Accepted Answer

玩得开心。

必须打破已检查的异常。
必须找到一种方法来实现委托（就像在加载时间之前添加的单方法接口）。

score 0 · Accepted Answer

您可以在同一个解释器中运行您的 .NET 代码和 Java 代码！有关示例用例（使用基于 .NET 的 Boo 语言使用 Java 库编写应用程序），请参阅基于IKVM .NET 的 JVM 和Boo 和 Java wiki 页面。

score 0 · Accepted Answer

0

乔，我建议你调查一下 IKVM。你可能会在那里找到能挠痒痒的东西

于 2009-01-30T05:01:18.600 回答

score 0 · Accepted Answer

我想您会发现Mainsoft 企业版工具允许您在 Java JVM 下运行大部分/可能所有 .NET 代码……似乎更关注 ASP.NET，但允许 C#。已经有一段时间了，可惜他们没有更好地宣传它！

警告信息如下....

Mainsoft® 是 Java-.NET 互操作性软件，它使 IT 组织能够迁移到 Linux 等支持 Java 的平台，同时保留对 .NET 代码和技能的现有投资。该软件无缝集成到 Visual Studio® 开发环境中，使 C# 和 Visual Basic 开发人员能够快速开发和维护在 Windows、Java EE 平台或两者上运行的服务器和 Web 应用程序，从而降低应用程序开发和维护成本，缩短开发时间。生产和总拥有成本。

score 0 · Accepted Answer

如果我正在做跨平台跨语言支持之类的事情，我会创建一个“通用 api”，因为这些语言在语法上相似，你可以让翻译器变得足够简单。然后，您无需直接从核心调用 java 或 .net api，而是调用您的“common api”，这将重新实现您需要的 java 和 .net api。如果愿意，您可以通过这种方式创建一个跨语言沙箱。由于 java 和 c# 的主要区别是对象定义，我会通过反映 C# dll 来获得这些，然后重构构造，然后很容易让解释器运行并实现函数体并将属性转换为 getter setter已经知道文件的结构。这当然是假设 .net 2.0，3.0 和 3.5 中的某些功能变得非常困难'

这会很复杂，但可能不如手动在 java 中重建一个核心那么复杂，并且必须有 2 个团队单独工作。如果这个想法激发了一些灵感，我可能会创造一个。我真的宁愿看到一个更简单的稳定单声道安装 mac。

基本上，我认为基于一组常见 api 类的代码级解释器很可能在一两周内与团队一起编写。

score 0 · Accepted Answer

简单的。因为 Sun 宁愿不被微软起诉。虽然我们作为程序员可能认为没有可行的诉讼理由，但请记住，微软是一家比 Sun 大得多的公司，并且有能力控制他们。

不过幸运的是，Sun 比微软更开放。如果存在这样的需求，开源或第三方都可以为 Java 制作这个编译器，Sun 就不必承担责任。

score 0 · Accepted Answer

JACIL是一个明显已死的项目，它试图与 IKVM 相反。也许一些有动力的人可以将它作为一个可行的 .Net 到 JVM 编译器的起点。

score 0 · Accepted Answer

我想更好的问题是，如果你想要一个存在的话，你为什么不写一个 C# 到 Java 字节码编译器。等待企业霸主做某事是个坏主意。

创建这样一个实现的建议：采用 Mono 或 .GNU 的 C# 前端。不要费心自己写。

c# - 为什么 Sun 不做 C# 到 Java 字节码编译器？

我们想在 JVM 上运行我们的 C# 代码

Sun 为什么要做 C# 编译器？（当然是国际海事组织）

那么为什么 Sun 不做 C# 编译器呢？

18 回答 18

Related

Reference