为什么Sun不做C＃到Java字节码编译器？ [英] Why doesn't Sun do a C# to Java byte code compiler?

问题描述

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

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.

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

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

Eric Sink 描述了这个问题。我在一个类似的位置，除了我们的软件许可证包括免费的部署，使Eric的选择Mainsoft是一个非快速的我们。

Eric Sink described this problem very 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.

我一直在谷歌的 c＃to jvm几个月几年现在没有喜悦。花了大约7年时间为Java开发类似的软件，我相信我们在核心引擎中使用的.NET API很容易被封装，我们可以使用Java库完成我们所需要的一切。所以，如果我们只有一个C＃ - > JVM编译器，我们可以构建我们的Java核心引擎，我们不再需要舍弃那些想使用它的Java开发人员。

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.

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

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.

我并不要求进一步讨论为什么一种语言/堆栈可能比另一种更好。我们的业务的现实是有大量的潜在客户使用每个。

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.

在Java平台上运行C＃代码更容易，意味着更多的开发人员和更多的平台软件。有什么更重要的平台的成功吗？ Jonathan Schwartz 是一个软件人。我会把它留给比我更聪明的人来决定他是否担任Sun的总裁兼首席执行官不可能完成的工作，但是在他加入Sun之后不久就遇到了Jonathan，我的印象是他理解软件和需要一个大

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 Schwartz is 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.

1. NIH 综合征？


2. 幽灵< a href =http://en.wikipedia.org/wiki/Scott_McNealy =nofollow noreferrer> Scott McNealy ？


3. 太多Java开发人员不喜欢或不信任与Microsoft有关的任何内容？


4. 他们同意不要参与大钱？

1. NIH syndrome?
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. ???

必须有一个好的理由。我只是不能为我的生活弄清楚是什么...

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

推荐答案

首先太阳没有激励实现一个C＃编译器在JVM上，因为他们有一些非常相似的称为Java编程语言。

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

它也不像真正简单的实现一个编译器作为Java标准类库不一样.net基类库。您最终必须将所有.NET API调用更改为Java API调用。

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.

Micrsoft有一个称为J＃的产品，用于Java到.NET的转换，但最终没有人使用它，因为API仅限于Java 2之前的API所以它大多是无用的。这将是相同的，如果Sun实施的.NET BCL的部分，因为只有它的核心部分是标准化和免版税。像ASP.NET和WPF，WCF等部分不是ECMA标准的一部分，所以Sun需要Microsoft的权限来实现这些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.

如果足够的客户想要一个java版本，使你的应用程序移植到java的商业意义，那么做它，你只是不会得到任何帮助从Sun通过C＃到JVM编译器。

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.

这篇关于为什么Sun不做C＃到Java字节码编译器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！