为什么Sun不把C#转换成Java字节码编译器?

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

我的公司有一个大的C#代码库。 超过一半的代码是我们创build,阅读,修改,计算和编写Excel工作簿的核心引擎。 我们经常从客户和潜在客户那里获得问题,询问我们是否打算构build我们的引擎的Java版本 – 他们中的许多人对UI并不感兴趣。 我们甚至有一些客户在Java应用程序中使用我们的.NET库。

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

Eric Sink很好地描述了这个问题 。 除了我们的软件许可证包含免版税的部署之外,我处于类似的位置,因此Ericselect了Mainsoft作为我们的首选。

我几个月来一直在使用“c#to jvm”这样的喜欢,好几年没有快乐。 花了大约7年的时间为Java开发类似的软件,我相信我们在核心引擎中使用的.NET API可以很容易地被封装起来,我们可以使用Java库完成我们需要的一切。 所以,如果我们只有一个C# – > JVM编译器,我们可以构build我们的Java核心引擎,我们将不再需要拒绝那些愿意使用它的Java开发人员。

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

而且,我并不是要求为什么一种语言/堆栈可能比另一种更好。 我们业务的现实是有很多潜在的客户使用他们。

Sun为什么要做C#编译器? (国际海事组织当然)

在Java平台上运行C#代码更容易,这意味着更多的开发人员和更多的平台软件。 有什么更重要的平台的成功? 乔纳森·施瓦茨是一个软件家伙。 我会把它交给别人比我聪明,以决定他是否担任了Sun公司的总裁兼首席执行官,但是他在joinSun之后不久就遇到了Jonathan,我的印象是,他了解软件,需要一个大的开发商的基地。

那么为什么Sun不用C#编译器?

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

一定有一个很好的理由。 我只是不能为我的生活弄清楚它是什么…

首先,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需要微软的权限才能实现这些API。

如果有足够多的客户需要Java版本来将应用程序移植到Java上,那么您就可以通过C#到JVM编译器从Sun获得任何帮助。

Joe Erickson写道:

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

这是一个不真实的陈述。 在JVM上运行C#代码不会创buildJava程序员,它会创build可以在JVM上执行的C#程序员。 它只扩展了C#的范围,假设JVM还将任何微软特定的调用(即win32)翻译成平台中立的东西。 所以如果Sun将IL转换成Java Bytecode,唯一有帮助的是:Microsoft。 而且,鉴于Sun在微软原始C#-Java分裂/ Visual J ++诉讼中的历史……

此外,无论您是否愿意,您都必须面对技术上的不可行性。 在执行字节码的方式上存在根本性的差别,这是比是否有无符号的长数据types更重要的问题。

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

为什么微软不把C#转换成Java字节码编译器? 你为什么不这样做? 有各方打开规格…

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

基本上,您想要修改您的C#代码,并使其在纯Java环境中运行。

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

一个。 ikvm – Java虚拟机的CLI实现(请注意, 这对于Java类库使用Classpath (现在的OpenJDK))。

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

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

请注意,所有这些工具在运行时都依赖于CLI。 你想要的是完全相反的IKVM,这当然是MVKI(最尊敬的Kompiler中介):):

一个。 mvki – 一个CLI虚拟机的Java实现(大概这将使用Mono或DotGNU作为类库)。

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

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

请注意,这些都不会要求在运行时现有的.NET Framework实现,所以它们应该满足您的仅限Java的客户。

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

编辑:基于Mainsoft 的描述 ,它似乎与MVKI类似,尽pipe我不确定它们为类库做了什么,而不像IKVM,它不是FOSS。

http://jsc.sourceforge.net/是交叉编译器,可以将;.NET代码转换为Java(除其他外)。

公开您的.NET API作为ASMX Web服务,你应该很好去。

编辑:对于更多的使用场景,这将是值得研究Windows通信基础(WCF)。 这有内置的,可configuration的安全支持,stream媒体,不同的传输scheme(HTTP,TCP / IP,本地命名pipe道)。 您不受限于SOAP消息编码,但这可能是与Java互操作的最简单的方法。

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

一定有一个很好的理由。 我只是不能为我的生活找出它是什么…

很容易相信,公司是非常重要的非营利组织。 很容易忘记,上市公司唯一的目的就是为股东赚钱。 这是一项法律义务,如果股东不相信他们没有做到这一点,董事/高pipe就被解雇/被起诉。

Sun使Java免费,因为它可以帮助销售他们从Java赚钱的硬件。 IBM使Java免费,因为它可以帮助他们在咨询上赚更多的钱。

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

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

玩的开心。

  1. 必须打破检查的exception。
  2. 必须find一种方法来实现委托(就像加载时间之前添加的单方法接口一样)。

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

乔,我build议你调查IKVM 。 你可能会发现那里的东西,抓挠你的痒

如果我正在做跨平台跨语言支持的工作,我会创build一个“通用api”,因为语言的语法类似,所以可以使翻译变得简单。 然后,不要直接从核心调用java或.net apis,而要调用你的'common api',这将实现你所需要的java和.net apis。 这样你可以创build一个跨语言的沙箱。 由于java和c#中的主要差异是对象定义,我将通过反映C#dll来获取这些内容,然后重构构造,那么可以很容易地让解释器运行并实现函数体并将属性转换为getter setters已经知道文件的结构。 这当然是假定.net 2.0,3.0和3.5中的一些function变得很难“解释”

这将是复杂的,但可能不像手工重buildjava核心那么复杂,并且必须有两个团队分别对它们进行操作。 如果这个想法引发了一些启发,我可以创build一个。 我真的很想看到一个更简单稳定的单声道安装为Mac。

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

简单。 因为Sun不想被微软起诉。 虽然我们作为程序员可能没有看到可行的诉讼理由,但要记住,微软是一个比Sun更大的公司,并且有能力为他们提供帮助。

所幸SUN还是比微软更开放的地位。 如果存在这样的需求,无论是开源还是第三方都可以为Java编译器,而Sun也不用担心。

JACIL是一个显然是死的项目,试图做IKVM的反向。 也许一些有动力的人可以用它作为一个可行的.Net到JVM编译器的起点。

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

build议创build这样一个实现:采取莫诺或GNU的C#前端。 不要打扰你自己写。

我发表了一个评论,应该是一个真正的答案:

目前在JVM上实现C#规范在技术上是不可能的。 C#支持指针,无符号types,用户定义的值types,真正的generics,传递引用和其他东西的负载。 对于非常类似C#的JVM语言,请查看Stab 。

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

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

警告blurb跟着….

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

我知道这可能不是你想要的,但是这里有一些可能的select(如果不是你的话)可能对别人有用。

  1. C:你可以尽可能多的移植到C中。现在,你可以用C#和Java(以及任何其他可以和C通信的语言)做一个包装,这使得它在编程时感觉自己的语言是原生的。 现在的问题是,你(或他们,根据你的许可证)必须build立每个平台的C部分。

  2. Fantom * :根据他们的主页编程语言是:

    • 便携式:在浏览器中编写可移植到Java VM,.NET CLR和JavaScript的代码。
    • 熟悉:语法Java和C#程序员将会感受到Fantom的进化语法。
    • 面向对象:Obj的所有子类。 值types,当你需要的性能。
    • function:function和封闭被烘烤在。
    • 静态和dynamictypes:不喜欢极端 – 走在路中间。
  3. haXe *:我(发音hex)是跨平台的语言编译为其他语言。 不久,将支持C#和Java。 目前支持:

    • Javascript:你可以将一个haXe程序编译成一个.js文件。 您可以通过自动完成支持来访问types化的浏览器DOM API,并且在编译时parsing所有的依赖关系。

    • Flash:你可以将一个haXe程序编译成一个.swf文件。 haXe与Flash Player 6到10兼容,具有“旧”Flash 8 API或最新的AS3 / Flash9 + API。 haXe提供非常好的性能和语言function来开发Flash内容。

    • NekoVM:您可以将haXe程序编译为NekoVM字节码。 这可以用于服务器端编程,例如dynamic网页(使用Apache的mod_neko),也可以用于命令行或桌面应用程序,因为NekoVM可以embedded并扩展其他一些DLL。

    • PHP:你可以编译一个haXe程序到.php文件。 这将使您能够使用haXe等高级严格types的语言,同时与您现有的服务器平台和库完全兼容。

    • C ++:现在可以使用所需的Makefiles从haXe源代码生成C ++代码。 这对于创build本地应用程序非常有用,例如在iPhone开发中。

    Haxe社区。 (2011年3月11日)。 haXe介绍。 检索2011年1月29日,从http://haxe.org/doc/intro

    您可以在这里了解更多关于HaXe为何有用的信息

*我从来没有使用这种语言,我不知道这会工作得如何。