Интеграция / связь приложений Java и приложений C ++ - PullRequest
4 голосов
/ 06 июля 2011

У нас есть две базы кода, одна написана на C ++ (MS VS 6), а другая на Java (JDK 6). В поисках творческих способов заставить обоих говорить друг с другом.


Подробнее:

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

Пока что рассматриваются следующие варианты:

  • ноль MG
  • RPC
  • 1017 * CORBA *
  • JNI
  • Компиляция Java в собственный код, а затем связывание

По сути, кроме последнего пункта, это сводится к выбору между различными способами достижения межпроцессного взаимодействия между приложением Java и приложением C ++. Все еще открыты для других творческих предложений!

Если вы уже пытались сделать это или что-то подобное, пожалуйста, сообщите свои предложения, извлеченные уроки, ловушки, которых следует избегать, и т. Д.


Кто-то, несомненно, в скором времени укажет, что на этот вопрос нет единственно правильного ответа. Я думал, что все равно воспользуюсь коллективным опытом сообщества SO и надеюсь получить много отличных ответов.

Ответы [ 4 ]

1 голос
/ 07 июля 2011

Поскольку вы используете Windows, я бы рекомендовал использовать DDE (Dynamic Data Exchange) .Есть библиотека Java, доступная с Java Parts .

1 голос
/ 06 июля 2011

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

Я настоятельно рекомендую не использовать CORBA, RMI и аналогичные реализации удаленных вызовов процедур, в основном потому, что, по моему опыту, они имеют большой вес и потребляют много ресурсов.Если вы хотите что-то похожее на RMI, я бы порекомендовал что-то более легкое для передачи сообщений, но не для реальных объектов (как в случае с RMI).Например, вы можете использовать буферы протокола в качестве формата сообщения, а затем просто сериализовать их туда и обратно через обычные сокеты.

Кит Хо упомянул XML или JSON, но буферы протокола значительно более эффективны, чем любой из этих форматов, а также имеют понятия обратной совместимости, встроенные непосредственно в язык определения.

1 голос
/ 06 июля 2011

Используйте Jacob (http://sourceforge.net/projects/jacob-project), JCom (http://sourceforge.net/projects/jcom) или j-Interop (http://j -interop.org ) и используйте COM для связи.

0 голосов
/ 06 июля 2011

Не знаю, сколько данных и какой тип данных вы хотите передавать и передавать.Но чтобы упростить этот путь, я предлагаю использовать XML или Json на основе протокола HTTP.

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

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

поправьте меня, если я не прав

...