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＃编译器？（当然是IMO）

使在Java平台上运行C＃代码更加容易，意味着有更多开发人员和该平台更多的软件。平台的成功还有什么更重要的吗？乔纳森·施瓦茨（Jonathan
Schwartz）是一名软件专家。我将由比我更聪明的人来决定他是否担任Sun总裁兼首席执行官一项不可能的工作，但是在加入Sun不久后与Jonathan会面时，我的印象是他了解软件并且需要大量软件。开发人员基础。

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

1. NIH综合征？
2. 斯科特·麦克尼利（Scott McNealy）的幽灵？
3. 太多的Java开发人员不喜欢或不信任与Microsoft相关的任何内容？
4. 他们同意不承担大笔费用吗？
5. ???

一定有一个很好的理由。我只是无法为自己的生活弄清楚它是什么…

Answer 1

首先，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，然后这样做，您将永远不会从Sun通过C＃到JVM编译器获得任何帮助。