我们想要在 JVM 上运行 C# 代码
我的公司拥有庞大的 C# 代码库。超过一半的代码是我们用于创建、读取、修改、计算和编写 Excel 工作簿的核心引擎。我们经常收到客户和潜在客户的问题,询问我们是否要构建引擎的 Java 版本 - 他们中的许多人对 UI 根本不感兴趣。我们甚至有一些客户不厌其烦地从他们的 Java 应用程序中使用我们的 .NET 库。
因此,我们希望构建核心引擎的 Java 版本,最好不要维护单独的 Java 源代码库。
埃里克·辛克描述了这个问题 http://www.ericsink.com/bos/Geeks_Rule.html很好。我的情况与此类似,只是我们的软件许可证包括免版税部署,这使得 Eric 选择 Mainsoft 对我们来说是不可能的。
我一直在谷歌上搜索类似的现在几年来,每隔几个月就会有一次,没有任何快乐。我花了大约 7 年的时间为 Java 开发类似的软件,我相信我们在核心引擎中使用的 .NET API 可以轻松封装,并且我们可以使用 Java 库完成我们需要的一切。因此,如果我们只有一个 C# -> JVM 编译器,我们就可以为 Java 构建核心引擎,并且我们将不再需要拒绝想要使用它的 Java 开发人员。
我并不是要问 Sun 不做 C# 编译器的技术原因。我认识到 Java 没有属性或无符号 64 位长,等等......为了论证,假设所有这些技术问题都可以通过扩展 JVM 和/或其他方式来解决。
我并不是要求再就为什么一种语言/堆栈可能比另一种更好进行辩论。我们业务的实际情况是,有大量潜在客户在使用每种产品。
Sun 为什么要开发 C# 编译器? (当然是国际海事组织)
使在 Java 平台上运行 C# 代码变得更容易意味着该平台将有更多的开发人员和更多的软件。对于一个平台的成功还有什么更重要的吗?乔纳森·施瓦茨 http://en.wikipedia.org/wiki/Jonathan_I._Schwartz是一个软件人。我将让其他比我聪明的人来决定他是否接受了 Sun 总裁兼首席执行官这一不可能的工作,但在乔纳森加入 Sun 后不久与他会面后,我的印象是他了解软件以及对大型软件的需求。开发商基础。
那么为什么Sun 不开发C# 编译器呢?
-
NIH http://en.wikipedia.org/wiki/Not_Invented_Here综合症?
- 的鬼魂斯科特·麦克尼利 http://en.wikipedia.org/wiki/Scott_McNealy?
- 太多 Java 开发人员不喜欢或不信任与 Microsoft 相关的任何东西?
- 他们同意不作为采取行动的一部分大笔钱 http://www.internetnews.com/bus-news/article.php/3334991?
- ???
一定有一个很好的理由。我只是一生都无法弄清楚它是什么......
首先,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 获得任何帮助。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)