Вызов метода java в узле js

Вызов метода java в узле js

Это большой вопрос. В целом, существует несколько подходов к взаимодействию языков:

  1. Выполнение кода в полностью отдельных, изолированных программах / процессах и использование межпроцессного взаимодействия (IPC) или других сетевых протоколов (TCP или протоколы более высокого уровня, построенные поверх TCP, такие как HTTP, часто с API-интерфейсом REST или какой-либо системой RPC ) для отправки информации между двумя процессами, которые были написаны на разных языках.

  2. «Транспортировка» одного языка в другой (например, с помощью транспортеров JSweet или TeaVM для преобразования кода Java в код JavaScript), а затем создание одного приложения / процесса из исходного кода на одном языке вместе с перенесенным кодом с другого языка. (который теперь на том же языке, что и другой код, встроенный в это конечное приложение).

  3. Использование общего промежуточного языка и низкоуровневых «родных» интерфейсов, которые позволяют коду взаимодействовать. Большинство языков имеют некоторую форму взаимодействия с C (потому что C является общим знаменателем, поддерживаемым большинством операционных систем). Хотя это не будет работать с клиентским JavaScript (хотя некоторые принципы по-прежнему актуальны для Native Client (NaCL)), с NodeJs вы можете вызывать код C, используя node-gyp и cwrap . Как только вы окажетесь на земле C, вы можете позвонить в Java, используя собственный интерфейс Java (JNI) (хотя сделать возможным вызов кода Java из C с использованием JNI, вероятно, будет проще, если SWIG автоматически сгенерирует большую часть шаблона для этого для вы, а не прямо писать в спецификации JNI).

Как и все вещи, есть компромиссы для различных подходов:

  • Подход № 1:
    • Плюсы:
      • относительно простой
      • работает практически с любым языком программирования
      • каждая подсистема полностью изолирована от другой
      • каждая система может быть отлажена на идиоматическом языке
    • Минусы:
      • должен определить общий протокол
        • может привести к избыточному, дублированному коду
        • протоколы должны быть синхронизированы
        • изменения должны быть обратно совместимы, иначе они будут нарушены
        • ПРИМЕЧАНИЕ: буферы протокола могут помочь с этим
      • издержки сериализации / десериализации
      • канал может добавить другие издержки (например, при обмене данными между процессами через Интернет, а не на одном компьютере через сокет домена UNIX)
      • должен учитывать безопасность коммуникационного механизма
        • шифрование данных между подсистемами
        • контроль доступа к конечным точкам
  • Подход № 2:
    • Плюсы:
      • нет затрат на сериализацию / десериализацию
      • может отлаживать финальную систему, используя идиомы для целевого языка
    • Минусы:
      • не все языки могут переноситься с одного на другой
      • даже если транспортер поддерживает два языка:
        • часто поддерживает только подмножество языка
        • возможно, потребуется исправить / изменить код, чтобы он мог перемещаться
        • может понадобиться починить / модифицировать транспортер
        • немного другая семантика в транспиляции может привести к незаметным, удивительным ошибкам
      • нет изоляции между подсистемами
  • Подход № 3:
    • Плюсы:
      • нет затрат на сериализацию / десериализацию
      • больше поддержки, чем подход № 2
      • нет необходимости переписывать оригинальный код на любом языке
    • Минусы:
      • должен стать экспертом в эзотерических инструментах, таких как SWIG
      • результат очень сложно отлаживать
        • трассировки стека для кода NodeJS неожиданно содержат код C, JVM, Java
        • инструменты отладки не могут легко охватить языки (например, могут в конечном итоге пройти через код JVM, интерпретирующий Java, а не проходить через реальный код Java)
      • владение объектами, сборка мусора между языками может привести к неожиданным / трудным для обработки ошибкам, если семантика владения неправильно закодирована
      • различные модели потоков между языками или другие семантические несоответствия между языками могут сделать всю систему глючной / трудной для отладки

Используя системы с подходом № 1 и подходом № 3 (а также с прослушиванием систем, использующих подход № 2), я настоятельно рекомендую использовать подход № 1, где это возможно; только если вы посчитаете несостоятельными издержки сериализации (и не сможете оптимизировать протокол / механизм связи для решения этой проблемы), я рискну отправиться в другие воды. При этом подход № 2 может быть успешным, если языки очень похожи (например, перенос из TypeScript в JavaScript), и подход № 3 может быть успешным, если использование этого механизма очень ограничено по объему (например, просто необходимо раскрыть один из них). маленькая, но часто вызываемая / чувствительная к производительности функция таким образом).

Понравилась статья? Поделиться с друзьями:
JavaScript & TypeScript
Adblock
detector