我有一个以C＃编写的现有库，它封装了一个低得多的TCP/IP API，并将从服务器（专有二进制协议）传出的消息暴露为.NET事件。我还为一个对象提供方法调用，该对象处理方便.NET类型（如System.DateTime）的编组复杂性，直至API需要的二进制编码和固定长度结构（用于将消息发送到服务器）。在.NET库的基础上构建了大量现有的应用程序（内部使用并由第三方使用）。比从C＃移植到Java更好的选择吗？
最近，我们已经找到了一个不想做抽象TCP/IP本身的所有工作的人，但他们的环境是严格的非Windows（我假设* nix，但我不是100％肯定），他们已经暗示他们的理想将会是Java可以调用的东西。
什么来支持他们的需求的最佳途径，而不必对我说：
- 代码移植到现在，Java（包括非托管的DLL，我们目前的P/Invoke成解压）
- 不得不保持两个独立的代码基地前进（即使相同的bug修复和功能增强两次）
我考虑过的一件事是将大部分核心TCP/IP功能一次性写入更多跨平台（C/C++）和n将我的.NET库改为这个（P/Invoke？）之上的一个薄层，然后在它上面写一个类似的瘦Java层（JNI？）。
优点：
- 我主要是把我的时间写的东西只有一次。
缺点：
- 大部分的代码现在是不受管理 - 世界不是结束，而不是从一个生产力点理想（对我来说）。
- 更长的开发时间（不能将C＃套接字代码移植到C/C++就像移植到Java一样快）[这是多么真实？]
- 此时，基础API大部分被包装并且库非常稳定，所以可能没有太多新的开发 - 将当前代码移植到Java并且在将来不得不偶尔修正错误或新开两个新字段可能并不是那么糟糕。
- 我的现有客户端应用程序的潜在不稳定性，而它们运行的版本在其下面发生了巨大变化。 （关于我的头顶，我可以想到32/64位问题，字节顺序问题，以及端口期间可能出现的一般错误等）
我简要考虑过的另一个选项是以某种方式单声道到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的&单间（方法&代表等）不容易直接的接口支持，可以考虑使用类似ZeroMQ协议缓存，或Apache节俭作为邮件格式。由于ZeroMQ支持不同的传输，这将在进程内，进程间和网络上运行。
我已经标记了你的答案是正确的，因为我的要求最终改变了。但是，我对此并不满意 - 在进行广泛的需求分析后，仍然可能会出现这种互操作性需求的情况，所以我仍然希望能有更好的答案。 – 2011-05-12 15:14:29
简短的回答：不，我认为没有比从c＃移植到Java更好的选择:)但是这可能不是一个合适的解决方案，因为客户需要代码，他愿意付多少钱等等。 – 2011-05-12 16:50:19