如何隔离 Java 中不受信任的本机代码？
我有一个我不信任的 C 库（从某种意义上说，它可能经常崩溃）。我从 Java 进程中调用它。
为了防止 C 库导致整个 Java 应用程序崩溃。下来，我认为最好为这个库生成一个专用的 java 进程，并让它与 Java 应用程序交互。通过套接字编程或RMI。然后，如果发生崩溃，我可以生成另一个并继续处理。
ProcessBuilder 是正确的方法吗？或者还有其他更简单的方法吗？
谢谢！
I have a piece of C library that I don't trust (in the sense that it might crash frequently). I am calling this from a Java process.
To prevent the crash in C library bringing the whole Java app. down, I figured it will be best if I spawn a dedicated java processes for this library, and let it interface with the Java app. through socket programming or RMI. Then, if a crash happens, I can just spawn another one and continue processing.
Is ProcessBuilder the way to go? Or are there any other easier ways?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，将本机代码托管在单独的 Java 进程中是保护应用程序免受本机代码影响的唯一方法。
至于更简单的方法，只有细微的实现差异。例如，不从 Java 应用程序生成代码，并将本机代码包装在配置为自动启动的本机包装器中。如果您了解 C 和套接字知识，这将简化解决方案。在这种方法中，RMI 并不是最佳选择。
即使你用Java包装本机代码，我仍然不会选择RMI。我在 WAN 上使用 Windows 时遇到了网络问题。如果可能的话，我会让沟通保持简单。如果数据太复杂，也许一个基本的序列化库。如果您选择 XML 路线，有几种选择。这是多余的，但您也可以嵌入 http 服务器和 Web 服务层。我不知道您的系统要求，但
恢复会带来各种挑战。如果它停止响应，您是否会生成另一个进程...您愿意这样做多少次...Java 的进程管理还有很多不足之处。
Yes, hosting the native code in a separate Java process is the only way to protect your application from native code.
As for easier ways, just minor implementation differences. For example, not spawning the code from your Java application and wrapping the native code in a native wrapper that is configured to auto-start. This would simplify the solution, if you have knowledge of C and sockets. In this approach, RMI wouldn't be the best choice.
Even if you wrap the native code in Java, I still wouldn't pick RMI. I have run into networking problems with Windows on WANs. I would keep the communication simple if possible. If the data is too complicated, maybe a basic serialization library. There are a few choices if you go down the XML route. It's overkill, but you could also embed an http server and web services layer. I don't know your system requirements, bu
Recovery is going to create a variety of challenges. If it stops responding, do you just spawn another process...how many times are you willing to do that... Process management from Java, leaves a lot to be desired.
我不知道有更简单的方法。
对于父级和子级之间的交互，我不会使用 RMI 或套接字 - 我会使用子级的标准输入和输出流，可通过 Process 对象访问。这是简单、高效且私密的。您可以像使用套接字流一样使用流，但无需考虑身份、地址、身份验证等。您可以自己编写协议，或者使用 Thrift 或 Protocol Buffers 之类的东西从实体定义构建协议。
I don't know of an easier way.
For the interaction between the parent and the child, i wouldn't use RMI or sockets - i'd use the child's standard input and output streams, accessible through the Process object. This is simple, efficient, and private. You can use the streams exactly as you would socket streams, although without any considerations of identity, addresses, authentication, and so on. You can write a protocol yourself, or use something like Thrift or Protocol Buffers to build a protocol from entity definitions.
如果性能不是问题，并且其他应用程序有可能访问您的“本机”服务，那么我会采用 RESTful 或其他某种面向 Web 服务的方式。至于崩溃时的重新生成，正如其他人提到的那样，只需将进程生成为服务，您就可以开始了。
如果您的应用程序是唯一会访问此本机服务的实体，那么我更愿意采用 RMI 方式，而不是纯套接字方式。在我看来，RMI 非常适合进程间通信（其中进程是 Java 进程）。 RMI 具有“可激活”远程对象的概念，根据您的要求（崩溃时自动生成），这将是一个自然的选择。此外，如果使用 RMI，您的应用程序将通过明确定义的 Java 接口而不是临时协议契约与本机进程进行对话（这可以使用其他高级解决方案（如 Web 服务）来实现，但在原始套接字方面确实很痛苦） 。
顺便说一句，JFTR，我们正在我们的生产应用程序中使用这个策略，并且效果很好，YMMV。 :-)
If performance isn't an issue and if there is a possibility of other applications hitting your "native" service, I'd go the RESTful or some other sort of web service oriented way. As far as re-spawning on crashes are concerned, as others have mentioned, just spawn the process as a service and you should be good to go.
If your application is the only entity which would be hitting this native service, then I'd prefer to go the RMI way as opposed to the pure socket way. IMO, RMI is a natural fit for inter-process communication (where the processes are Java processes). RMI has the concept of an "activatable" remote object which would be a natural fit given your requirements (auto-spawn on crash). Also, if using RMI, your application would speak with the native process through well defined Java interfaces rather than ad-hoc protocol contracts (which can be achieved using other high level solutions like web services but a real pain when it comes to raw sockets).
BTW, JFTR, we are using this strategy with our production app and it is working out quite well, YMMV. :-)