我有一個以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