Joe*_*son 46 .net c# java compiler-construction jvm
我的公司有一个庞大的C#代码库.超过一半的代码是我们创建,阅读,修改,计算和编写Excel工作簿的核心引擎.我们经常从客户和潜在客户那里得到问题,询问我们是否要构建我们引擎的Java版本 - 其中许多人对用户界面并不感兴趣.我们甚至有一些客户在他们的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和/或其他方法来处理.
而且我并没有要求再讨论为什么一种语言/堆栈可能比另一种语言/堆栈更好.我们业务的现实是有很多潜在客户使用每个.
在Java平台上运行C#代码更容易,这意味着更多的开发人员和更多的平台软件.对平台的成功有什么更重要的吗？乔纳森施瓦茨是一个软件家伙.我会把它留给比我更聪明的人来决定他是否担任Sun的总裁兼首席执行官,但是在他加入Sun之后不久就遇到了Jonathan,我的印象是他了解软件以及对大型软件的需求开发人员的基础.
一定有充分的理由.我不能为我的生活弄清楚它是什么......
Tim*_*Tim 38
首先,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获得任何帮助.
Ran*_*pho 21
Joe Erickson写道:
在Java平台上运行C#代码更容易,这意味着更多的开发人员和更多的平台软件.
这是一个不真实的陈述.在JVM上运行C#代码不会创建Java程序员,它会创建可以在JVM上执行的C#程序员.它只扩展了C#的范围,假设JVM还将任何微软特定的调用(即win32)转换为平台中立的东西.因此,如果Sun将IL转换为Java字节码,那么它唯一可以帮助的是:Microsoft.而且,鉴于Sun在最初的C#-Java分裂/ Visual J ++诉讼中与微软的历史......
此外,无论您是否愿意,您都必须面对技术上的不可行性.字节码的执行方式存在根本区别,这些问题远比是否存在无符号长数据类型更重要.
如果您必须在非Microsoft平台上安装C#,请使用Mono
Cha*_*ert 21
为什么Microsoft不对C#进行Java字节码编译？为什么不,你做了吗？每边都有开放的规格......
Mat*_*hen 13
"因此,我们希望构建一个Java版本的核心引擎,理想情况下不需要维护单独的Java源代码库."
基本上,您希望编译未修改的C#代码,并使其在仅Java环境中运行.
一个.ikvm - Java虚拟机的CLI实现(请注意,这为Java类库使用Classpath(现为OpenJDK)).
湾 ikvmc - 将java字节码编译为CLI字节码.
C.ikvmstub - 生成调用CLI代码的java存根类.
请注意,所有这些工具都在运行时依赖于CLI.你想要的是与IKVM完全相反的东西,它当然是MVKI(最尊敬的Kompiler Intermediary):):
一个.mvki - CLI虚拟机的Java实现(可能会使用Mono或DotGNU作为类库).
湾 mvkic - 将CLI字节码编译为Java字节码.
C.mvkistub - 生成调用Java的CLI存根类
请注意,这些都不需要在运行时现有的.NET Framework实现,因此它们应该让您的Java客户满意.
不幸的是,据我所知MVKI不存在,所以你最好做一个手动端口(这将不可避免地更干净,虽然更多的工作).
编辑:根据Mainsoft 的描述,它似乎与MVKI相似,虽然我不确定他们为类库做了什么,而且与IKVM不同,它不是FOSS.
将您的.NET API公开为ASMX Web服务,您应该很高兴.
编辑:对于更多繁重的使用场景,值得研究Windows Communication Foundation(WCF).它具有内置的可配置支持,可用于安全性,流式传输,不同的传输方案(HTTP,TCP/IP,本地命名管道).您不仅限于SOAP消息编码,但这可能是与Java互操作的最简单方法.
我不太确定你的具体情况,但是如果你正在处理大文件并且.NET代码和Java代码都在本地运行,你可以使用.NET将文件保存到用户的硬盘驱动器然后获取它来自您的Java应用程序.