javascript - 在 Node js 中调用 java 方法

Question

这个问题在这里已经有了答案:





Call java program from Node.js application

(5 个回答)


9 个月前关闭。




我正在尝试从 node js 调用在 java 中定义的函数。

示例:

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

和一个 Node js文件

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

我可能完全错了，但我正在尝试从 node js 访问 java 函数。

Answer 1

这是一个很好的问题。一般来说，语言互操作有以下几种方式:

在完全独立的、隔离的程序/进程中运行代码，并使用进程间通信 (IPC) 或其他网络协议(protocol)(TCP 或建立在 TCP 之上的更高级协议(protocol)，如 HTTP，通常使用 REST-ful API，或某种形式的 RPC 系统) 在用不同语言编写的两个进程之间发送信息。

将一种语言“转译”为另一种语言(例如，使用 JSweet 或 TeaVM 转译器将 Java 代码转换为 JavaScript 代码)，然后从一种语言的原始代码与另一种语言的转译代码一起创建单个应用程序/进程(现在与构建到最终应用程序中的其他代码使用相同的语言)。

使用允许代码互操作的通用中间语言和低级“ native ”接口(interface)。大多数语言都与 C 有某种形式的互操作(因为 C 是大多数操作系统支持的公分母)。虽然这不适用于客户端 JavaScript(尽管一些原则仍然与 Native Client (NaCL) 相关)，但对于 NodeJ，您可以使用 node-gyp 调用 C 代码。和 cwrap .进入 C 领域后，您可以使用 Java Native Interface (JNI) 调用 Java。 (尽管通过让 SWIG 为您自动生成大部分样板，而不是直接写入 JNI 规范，可以使用 JNI 从 C 调用 Java 代码可能更容易实现)。

与所有事情一样，各种方法也需要权衡:

方法#1:

优点:

相对直接

几乎适用于任何编程语言

每个子系统彼此完全隔离

每个系统都可以用语言惯用的方式调试

缺点:

必须定义共享协议(protocol)

可能导致冗余、重复的代码

协议(protocol)必须保持同步

更改必须向后兼容，否则会破坏

注意:protocol buffers可以帮助解决这个问题

序列化/反序列化开销

channel 可以增加其他开销(例如，如果进程之间通过 Internet 进行通信，而不是通过 UNIX 域套接字在同一台机器上进行通信)

必须考虑通信机制的安全性

子系统之间的数据加密

端点的访问控制

方法#2:

优点:

没有序列化/反序列化开销

可以使用目标语言的习语调试最终系统

缺点:

并非所有语言都可以从一种语言转换为另一种语言

即使转译器支持两种语言:

通常只支持语言的一个子集

可能需要修复/修改代码以允许它转译

可能需要修复/修改转译器

转译中略有不同的语义会导致微妙的、令人惊讶的错误

子系统之间没有隔离

方法#3:

优点:

没有序列化/反序列化开销

比方法#2 更多的支持

无需用任何一种语言重写原始代码

缺点:

必须成为 SWIG 等深奥工具的专家

结果很难调试

NodeJS 代码的堆栈跟踪突然包含 C、JVM、Java 代码

调试工具不容易跨语言(例如可能最终单步执行解释 Java 的 JVM 代码，而不是单步执行实际的 Java 代码)

对象所有权，如果所有权语义未正确编码，跨语言垃圾收集可能会导致令人惊讶/难以处理的错误

语言之间的不同线程模型或语言之间的其他语义不匹配会使整个系统出错/难以调试

使用过方法#1 和方法#3 的系统(以及使用方法#2 的系统听说过)，我强烈建议尽可能使用方法#1；只有当您发现序列化开销站不住脚(并且您无法优化通信协议(protocol)/机制来处理该问题)时，我才会冒险进入其他领域。话虽如此，如果语言非常相似(比如从 TypeScript 到 JavaScript 的转换)，方法 #2 可以成功，如果这种机制的使用范围非常有限(例如只需要公开一个小但经常调用/性能敏感的功能，以这种方式)。