Sun 为什么不做一个 C# 到 Java 字节码的编译器？

Why doesn't Sun do a C# to Java byte code compiler?

提问by Joe Erickson

We Want to Run Our C# Code on the JVM

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

My company has a large C# code base. Well over half of this code is our core engine for creating, reading, modifying, calculating and writing Excel workbooks. We frequently get questions from customers and potential customers asking whether we are going to build a Java version of our engine - many of them are not at all interested in the UI. We even have a few customers who have taken the trouble to use our .NET library from their Java applications.

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

So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base.

因此，我们希望构建核心引擎的 Java 版本，理想情况下无需维护单独的 Java 源代码库。

Eric Sink described this problemvery well. I am in a similar position except for the fact that our software license includes royalty free deployment, making Eric's choice of Mainsoft a nonstarter for us.

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

I have been Googling the likes of "c# to jvm"every few months for several years now with no joy. Having spent ~7 years developing similar software for Java, I am confident that the .NET APIs we use in our core engine could easily be encapsulated and we could accomplish everything we need using the Java libraries. So, if we only had a C# -> JVM compiler we could build our core engine for Java and we would no longer have to turn away Java developers who would like to use it.

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

I am not asking for the technical reasons why Sun does not do a C# compiler. I recognize that Java has no properties or an unsigned 64 bit long, etc... For the sake of argument, just assume that all of these technical issues could be dealt with by extending the JVM and / or other means.

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

And I am not asking for yet another debate on why one language / stack might be better than the other. The reality in our business is that there are plenty of potential customers using each.

而且我并不是要就为什么一种语言/堆栈可能比另一种更好进行另一场辩论。我们业务中的现实是，有很多潜在客户在使用它们。

Why Should Sun do a C# Compiler? (IMO of course)

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

Making it easier to run C# code on the Java platform means more developers and more software for the platform. Is there anything more important to the success of a platform? Jonathan Schwartzis a software guy. I will leave it to others smarter than me to decide whether or not he took on an impossible job as President and CEO of Sun, but having met with Jonathan shortly after he joined Sun my impression is that he understands software and the need for a large base of developers.

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

So Why Doesn't Sun do a C# Compiler?

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

1. NIHsyndrome?
2. The ghost of Scott McNealy?
3. Too many Java developers dislike or distrust anything related to Microsoft?
4. They agreed not to as part of taking the big bucks?
5. ???

1. NIH综合征？
2. 斯科特麦克尼利的鬼魂？
3. 太多 Java 开发人员不喜欢或不信任与 Microsoft 相关的任何内容？
4. 他们同意不作为拿大钱的一部分？
5. ？？？

There must be a good reason. I just cannot for the life of me figure out what it is...

一定有充分的理由。我终其一生都无法弄清楚它是什么......

采纳答案by Tim

Firstly Sun has zero incentive to implement a C# compiler on the JVM because they have something very similar called the Java programming language.

首先，Sun 在 JVM 上实现 C# 编译器的动机为零，因为它们具有非常相似的东西，称为 Java 编程语言。

Its also not really as simple as just implementing a compiler as the Java standard class libraries are not the same as the .net Base Class Libraries. You would end up having to change all the .NET API calls to Java API calls.

它也并不像实现编译器那么简单，因为 Java 标准类库与 .net 基类库不同。您最终不得不将所有 .NET API 调用更改为 Java API 调用。

Micrsoft had a product called J# which was meant to be for Java to .NET conversion but in the end no one used it as the API was limited to pre Java 2 API so it was mostly useless. It would be the same if Sun implemented parts of the .NET BCL, as only the core portions of it are standardised and royalty free. Parts like ASP.NET and WPF, WCF etc are not part of the ECMA standards and so Sun would need Microsofts permission to implement those API's.

Micrsoft 有一个名为 J# 的产品，它旨在用于 Java 到 .NET 的转换，但最终没有人使用它，因为 API 仅限于 Java 2 API 之前，所以它几乎没用。如果 Sun 实现了 .NET BCL 的部分内容，情况也会一样，因为只有其中的核心部分是标准化的且免版税。像 ASP.NET 和 WPF、WCF 等部分不是 ECMA 标准的一部分，因此 Sun 需要 Microsoft 的许可才能实现这些 API。

If enough customers want a java version to make business sense to port your application to java then do it, you just wont ever get any help from Sun via a C# to JVM compiler.

如果有足够多的客户希望 Java 版本具有商业意义，以便将您的应用程序移植到 Java 中，然后就这样做，那么您将永远无法通过 C# 到 JVM 编译器从 Sun 那里获得任何帮助。

回答by Randolpho

Joe Erickson wrote:

Making it easier to run C# code on the Java platform means more developers and more software for the platform.

乔·埃里克森写道：

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

This is an untrue statement. Running C# code on the JVM does not create Java programmers, it creates C# programmers who can execute on a JVM. It only expands the reach of C#, assuming the JVM also translates any microsoft specific calls (i.e. win32) into something that is platform neutral. So if Sun translates IL to Java Bytecode, the only group it helps is: Microsoft. And, given Sun's history with Microsoft during the original C#-Java schism/Visual J++ lawsuits...

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

Plus, you have to face the technical infeasibility, whether you want to or not. There are fundamental differences in the way the bytecodes are executed that are far more important issues than whether or not there's an unsigned long datatype.

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

If you must have C# on a non-Microsoft platform, use Mono

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

回答by Chase Seibert

Why doesn't Microsoftdo a C# to Java byte code compiler? Why don't youdo it? There are open specs on each side...

为什么微软不做一个 C# 到 Java 的字节码编译器？为什么不，你做了吗？每边都有开放的规格......

回答by Joshua

Have fun.

玩得开心。

1. Must break checked exceptions.
2. Must find a way to implement delegates (which are like single-method interfaces added no earlier than load time).

1. 必须中断已检查的异常。
2. 必须找到一种方法来实现委托（就像不早于加载时间添加的单方法接口）。

回答by Charles Duffy

You canrun your .NET code and Java code in the same interpreter! See the IKVM.NET-based JVM, and the Boo and Javawiki page for an example use case (using the .NET-based Boo language to write applications using Java libraries).

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

回答by Rad

Joe, I suggest you investigate IKVM. You might find something there that scratches your itch

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

回答by davogones

Expose your .NET API as ASMX web services and you should be good to go.

将您的 .NET API 公开为 ASMX Web 服务，您应该很高兴。

EDIT: For more heavy-usage scenarios, it would be worth looking into Windows Communication Foundation (WCF). This has built-in, configurable support for security, streaming, different transport scenarios (HTTP, TCP/IP, local named pipes). You are not restricted to SOAP message encoding, but that would probably be the easiest way to interop with Java.

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

I'm not too sure about your exact scenario, but if you're dealing with large files and the .NET code and Java code are both running locally, you can just save the file to the user's hard drive using .NET and then fetch it from your Java app.

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

回答by Matthew Flaschen

"So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base."

“因此，我们希望构建我们核心引擎的 Java 版本，理想情况下无需维护单独的 Java 源代码库。”

Basically, you want to compile your C# code unmodified, and have it run in a Java-only environment.

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

IKVM is notwhat you want. IKVMis three main things.

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

a. ikvm - CLI implementation of a Java virtual machine (note that this uses Classpath(now OpenJDK) for the Java class library).

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

b. ikvmc - Compiles java bytecode to CLI bytecode.

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

c. ikvmstub - Generates java stub classes that call CLI code.

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

Note that all of these tools depend on CLI at runtime. What you want is exactly the opposite of IKVM, which is of course MVKI (Most Venerable Kompiler Intermediary) :):

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

a. mvki - Java implementation of a CLI virtual machine (presumably this would use Monoor DotGNUfor the class library).

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

b. mvkic - Compiles CLI bytecode to Java bytecode.

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

c. mvkistub - Generates CLI stub classes that call Java

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

Note that none of these would require an existing implementation of the .NET Framework at runtime, so they should be satisfactory to your Java-only customers.

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

Unfortunately, as far as I know MVKI does not exist, so you're best off doing a manual port (which would inevitably be cleaner, albeit more work).

不幸的是，据我所知 MVKI 不存在，所以你最好做一个手动移植（这将不可避免地更干净，尽管需要更多的工作）。

Edit: Based on the descriptionof Mainsoft, it appears to be similar to MVKI, though I'm not sure what they do for the class library, and unlike IKVM it's not FOSS.

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

回答by AnthonyLambert

I think you will find that the Mainsoft, Enterprise Editiontool allows you to run most/maybe all your .NET code under the Java JVM... Seems to be focused more on ASP.NET but will allow C#. It has been available for some time, pity they don't publicize it better!

我想你会发现Mainsoft, Enterprise Edition工具允许你在 Java JVM 下运行大部分/也许所有的 .NET 代码......似乎更专注于 ASP.NET 但允许 C#。已经有一段时间了，可惜他们没有更好地宣传它！

Warning blurb follows....

警告简介如下......

Mainsoft? is Java-.NET interoperability software that enables IT organizations to move to Java-enabled platforms such as Linux while preserving existing investments in .NET code and skills. The software integrates seamlessly into the Visual Studio? development environment, enabling C# and Visual Basic developers to rapidly develop and maintain server and Web applications that run on Windows, Java EE platforms or both, thereby reducing application development and maintenance costs, time-to-production and total cost of ownership.

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

回答by AnthonyLambert

If i was doing something like cross platform cross language support, I would create a 'common api' since the languages are similar in syntax you could make a translator easy enough. Then instead of calling java or .net apis directly from the core, you would call your 'common api' which would re implement the java and .net apis you would need. In this way you could create a cross language sandbox if you will. Since the main differences in java and c# are object definitions, I would get those by reflecting the C# dlls, and then reconstruct the constructs, then it would be easy to have an interpreter run through and implement the function bodies and convert properties to getters setters already knowing the structure of the files. This of course is assuming .net 2.0, some of the features in 3.0 and 3.5 become very difficult to 'interpret'

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

It would be complex, but probably not as complex as reconstructing a core in java by hand, and having to have 2 teams working on them seperatly. If this idea sparks some inspiration i might create one. I would really rather see a simpler stable mono installation for mac.

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

Basically I think a code level interpreter based on a set of common api classes is something very possible to write with a team in a week or two.

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