2016-08-19 6 views
3

Я пытаюсь вызвать функцию, определенную в java от узла js.Вызов метода java в узле js

Пример: Файл

public class A{ 
public void show(){ 
    System.out.prntln("Invoked from Node JS"); 
} 
} 

и узел расслоение плотной

console.log("In Node JS"); 
//define calling A like A a = new A(); 
a.show(); 

я могу быть совершенно неправильно, но я пытаюсь получить доступ к функции Java от узла JS.

+0

Вы не можете просто вызвать функции на других языках. Вам нужно будет отправить сообщение/сигнал в вашу java-программу через Socket или что-то еще, а затем проанализировать это сообщение в вашей java-программе. – byxor

+0

Java и Javascript - это два совершенно разных языка ... вы можете попробовать и запустить C++ или Ruby, а не шанс, который Node понимает. –

+2

@BrandonIbbotson, в то время как это, вероятно, лучший способ сделать это, это также можно сделать непосредственно через промежуточный интерфейс C и вызовы JNI. –

ответ

5

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

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

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

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

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

  • Подход # 1:
    • Плюсы:
      • относительно прямолинейные
      • работы с почти любым языком программирования
      • каждая подсистема полностью изолирована от другой
      • каждой системы может быть отлажена в языке идиоматического образом
    • Против:
      • должен определить общий протокол
        • может привести к излишнему, дублированный код
        • протоколы должны храниться в синхронизации
        • изменения должны быть обратными mpatible или он сломается
        • Примечание: protocol buffers может помочь с этим
      • сериализации/десериализации накладных
      • канал может добавить другие накладные расходы (например,если связь между процессами через Интернет, в отличие от на той же машине через сокет домена UNIX)
      • должны учитывать безопасности и надежности механизма связи
        • шифрование данных между подсистемами
        • контроля доступа конечных точек
  • подход № 2:
    • Плюсы:
      • нет накладных сериализации/десериализации
      • отлаживать выпускную систему с использованием идиомы для целевого языка
    • Минусы:
      • не все языки могут transpile от одного к другому
      • , даже если трансилер поддерживает два языка:
        • часто поддерживает только подмножество языка
        • может понадобиться, чтобы исправить/изменить код, чтобы позволить ему transpile
        • может понадобиться, чтобы исправить/изменить transpiler
        • немного другой семантикой в ​​transpilation может привести к тонким, удивительные ошибки
      • нет изоляции между подсистемами
  • Подход № 3:
    • Плюсы:
      • нет сериализации/десериализации накладных
      • более
      • поддержки, чем подход # 2
      • нет необходимости переписывать исходный код на любом языке
    • Минусов:
      • должно стать экспертом в эзотерических инструментах, таких как SWIG
      • результат очень трудно отлаживать
        • stacktraces для NodeJS кода внезапно содержат C, JVM, Java код
        • отладки не легко охватывают языки (например,может в конечном итоге пошагового JVM кода интерпретации Java, а не пошагового фактического кода Java)
      • собственность объектов, сбор мусора по языкам может привести к удивительным/трудно обрабатывать ошибки, если собственность семантика не кодируются правильно
      • различные модели многопоточности между языками или других семантических несоответствий между языками может сделать всю систему багги/трудно отлаживать

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

Смежные вопросы