有什么比从C#移植到Java更好的选择？

Question

我有一个用C#编写的现有库,它包含一个更低级别的TCP/IP API,并将来自服务器(专有二进制协议)的消息作为.NET事件公开.我还在一个对象上提供方法调用,该对象处理将方便的.NET类型(如System.DateTime)编组到API所需的二进制编码和固定长度结构(用于传递到服务器的消息)的复杂性.在这个.NET库之上构建了相当数量的现有应用程序(内部和第三方使用).

最近,我们已经找到了一个不想自己完成抽象TCP/IP的所有工作的人,但他们的环境严格来说不是Windows(我假设是*nix,但我不是100%肯定)他们已经暗示他们的理想是可以从Java调用的东西.

什么是支持他们要求的最佳方式,我不必:

1. 现在将代码移植到Java(包括我们当前P/Invoke进行解压缩的非托管DLL)
2. 必须保持两个单独的代码库前进(即进行两次相同的错误修复和功能增强)

我考虑过的一件事是将大部分核心TCP/IP功能重写为更多跨平台(C/C++),然后将我的.NET库更改为一个薄层(P /调用？),然后在它上面写一个类似的瘦Java层(JNI？).

优点:

• 我大部分时间都只花时间写东西.

缺点:

• 大多数代码现在都是不受管理的 - 不是世界末日,但从生产力的角度来看并不理想(对我来说).
• 更长的开发时间(无法将C#套接字代码移植到C/C++中,只需移植到Java)[这是多么真实？]
• 此时,底层API主要是包装的,并且库非常稳定,因此可能没有太多新的开发 - 将当前代码移植到Java然后不得不偶尔进行错误修复可能不是那么糟糕或将来两次曝光新字段.
• 我现有的客户端应用程序在运行它们的版本时可能会出现不稳定的变化.(在我的脑海中,我可以想到32/64位问题,字节序问题以及端口期间可能出现的一般错误等)

我简要考虑的另一个选择是以某种方式将Mono绑定到Java,以便我可以利用我已有的所有现有C#代码.尽管开发人员的体验对于那些不得不使用它的Java开发人员来说有多顺畅,但我并不太了解.我很确定大多数代码应该在Mono下运行没有问题(禁止解压缩P/Invoke,它应该只是移植到C#).

我理想情况下不想在我的代码和客户端Java应用程序之间添加另一层TCP/IP,管道等,如果我可以帮助它(因此WCF到Java端的WS-DeathStar可能已经出局).我从来没有用Java做过任何认真的开发,但我感到自豪的是,这个库目前是第三方开发人员整合到他的应用程序中的一块蛋糕(只要他当然运行.NET: )),我希望能够为任何想要相同体验的Java开发人员保持同样的易用性.

因此,如果有人对我提出的3个选项有意见(端口到Java并维护两次,移植到C并为.NET和Java编写瘦语言绑定,或者尝试集成Java和Mono),或者任何其他建议我'我喜欢听他们说话.

谢谢

编辑:在与客户的开发人员直接对话(即删除破碎的电话AKA销售部门)后,要求已经发生了很大变化,以至于这个问题不再适用于我的直接情况.但是,我会把问题保持开放,希望能够产生更好的建议.

在我的特定情况下,客户端实际上除了Solaris之外还运行Windows机器(现在还没有？)并且很高兴我们在库顶部编写应用程序(Windows服务)并提供更简化和更小的应用程序用于编码的TCP/IP API.我们将他们的简单消息转换为下游系统理解的格式,并将传入的响应转换回来供他们使用,以便他们可以通过他们的Java应用程序继续与这个下游系统连接.

在考虑了几周之后再回到原来的情景,我还有一些评论:

• 如果您事先知道需要支持多种语言/平台,那么可能是一种基于C语言的可移植库,其中包含不同的语言绑定.

• 在*nix上,单个进程可以同时托管Java运行时和Mono运行时吗？我知道在早期版本的.NET中你不能在同一个进程中有两个不同的.NET运行时,但我相信他们已经用.NET 4解决了这个问题？如果可能的话,两者之间如何沟通？理想情况下,您需要像静态方法调用这样简单的事情以及用于提升响应的委托.

• 如果Java和Mono(方法和委托等)之间没有简单的直接接口支持,可以考虑使用ZeroMQ和Protocol Buffers或Apache Thrift作为消息格式.由于ZeroMQ支持不同的传输,因此可以在进程内,进程间和网络上工作.

Answer 1

在决定实施之前，花更多时间确定需求。在您知道需要什么之前，您没有任何选择设计的标准。

例如，如果它是非 Windows 环境，那么在其中的任何位置使用 .NET 就没有意义。