Совместимость Java и C#

Я большой поклонник Бережливость - стека взаимодействия от Facebook. Вы сказали, что их код, вероятно, будет работать на одной машине, поэтому это может быть излишним, но вы все равно можете его использовать.

Я использовал JNBridge (http://www.jnbridge.com/jnbpro.htm) в относительно простом проекте, где у нас было клиентское приложение .NET, использующее относительно значительный jar-файл, полный логики бизнес-объектов, которую мы не хотели переносить. Он работал неплохо, но я бы не сказал, что мы полностью использовали возможности JNBridge.

Я слышал хорошие отзывы о ИКВМ, JVM, созданной с помощью .NET.

Лед от ZeroC - это действительно высокопроизводительный корпоративный уровень взаимодействия, который поддерживает, среди прочего, Java и .net. Я думаю об этом как об обновленной Corba - у нее даже есть свой собственный объектно-ориентированный язык определения интерфейса, называемый Ломтик (как IDL Corba, но на самом деле вполне читаемый).

Набор функций обширен, предлагая гораздо больше, чем веб-сервисы, но очевидно, что это не открытый стандарт, поэтому решение не стоит принимать легкомысленно. Сгенерированный код, который он выплевывает, тоже несколько уродлив ...

У Кайла правильный подход, когда он спрашивает о взаимодействии. Не существует «правильного» ответа без знания вероятных шаблонов использования.

Любое архитектурное решение - особенно на этом уровне - это компромисс.

Вы должны спросить себя:

• Какие сообщения необходимо передавать между системами?
• Какими типами данных нужно делиться?
• Есть ли важное требование для поддержки сложных объектов модели или примитивы + массивы подойдут?
• какой объем данных?
• Как часто будут происходить взаимодействия?
• Какая допустимая задержка связи?

Пока у вас не будет понимания ответов или потенциальных ответов на эти вопросы, будет сложно выбрать архитектуру реализации. Как только мы узнаем, какие факторы важны, будет намного проще выбрать более подходящие варианты реализации, которые отражают требования работающей системы.

Я понимаю, что вы говорите о программах на одной машине, но мне всегда нравилась идея передачи сообщений в XML через HTTP.

Ваш сервер может быть веб-сервером, готовым принимать полезные данные XML. Ваш клиент может отправлять HTTP-сообщения с XML в теле и получать HTTP-ответ с XML в нем.

Одна из причин, по которой мне это нравится, заключается в том, что HTTP является настолько широко используемым протоколом, что легко принимать или создавать запросы HTTP POST или GET на любом языке (в случае, если вы решите изменить язык клиента или сервера в будущем). HTTP и XML существуют уже давно, поэтому я думаю, что они останутся здесь надолго.

Еще одна причина, по которой мне это нравится, заключается в том, что ваш сервер может использоваться и другими клиентами, если они знают HTTP и XML.

Если они являются отдельными программами и работают как независимые приложения, вы можете использовать сокеты. Я знаю, что определить протокол связи немного сложно, но это будет довольно просто.

Однако, если у вас есть всего две отдельные программы, но вы хотите запускать их как одно приложение, то я думаю, что IKVM - лучший подход, как предлагает marxidad.

Я автор jni4net, межпроцессного моста с открытым исходным кодом между JVM и CLR. Он построен на базе JNI и PInvoke. Код C / C++ не требуется. Надеюсь, это вам поможет.

Похоже, что здесь задавался очень похожий вопрос о переполнении стека (я искал в Google разделяемую память java windows):

Эффективная передача данных с Java на C++ в windows

Из ответа я предлагаю вам изучить:

"Your fastest solution will be memory mapping a shared segment of memory, and them implementing a ring-buffer or other message passing mechanism. In C++ this is straight forward, and in Java you have the FileChannel.map method which makes it possible."