将 GUI 置于单独的进程中
我目前正在为我创建的 Java 应用程序开发 GUI。我想将 GUI 保留在与客户端其他部分分开的进程中。其背后的理由是：
- 降低崩溃的风险。例如，GUI 中的 OutOfMemoryError 不会导致客户端的其余部分崩溃。
- 我“免费”获得一个 API。如果我稍后想要允许其他人以编程方式访问客户端，我可以让他们使用 GUI 所使用的相同 API。
- 我正在 SWT 中编写 GUI，并使用 IntelliJ 创建客户端。由于 Eclipse 具有更好的 SWT 支持，因此将它们分开是有意义的，这样我就可以使用 Eclipse 来处理 GUI 代码，而使用 IntelliJ 来处理其余的事情。
我现在的问题是：我应该使用什么技术将客户端的界面暴露给 GUI？首先想到的是 RMI。然而，这样做的缺点是 API 仅限于 Java。我也不确定 RMI 是否适合大规模部署（例如，它如何处理本地防火墙？）。不过，我还不想排除这种可能性。
我还应该提到，我还有一些部署要求：
- 必须能够以非管理员身份运行。
- 必须能够处理严格的本地防火墙限制。
- 部署必须是自动的（它是一个大型消费者应用程序）并且可以在 Windows、Mac OS X 和 Linux 上运行。
考虑到这些限制，您会使用什么解决方案？
I'm currently developing a GUI for a Java-application that I've created. I would like to keep the GUI in a separate process from the rest of the client. The rationale behind this is:
- Reduced risk of crashing. E.g. a OutOfMemoryError in the GUI won't crash the rest of the client.
- I get an API "for free". If I later on want to allow other people to programmatically access the client I can just let them use the same API that the GUI is using.
- I'm writing the GUI in SWT and the client is created using IntelliJ. Since Eclipse has a lot better SWT-support it makes sense to keep them separate, so that I can use Eclipse for the GUI-code and IntelliJ for the rest.
My question is now: what technology should I use to expose the client's interface to the GUI? RMI is what came to mind first. However, that has the disadvantages of restricting the API to be Java only. I'm also not sure about how well suited RMI is for large scale deployment (e.g. how does it handle local firewalls?). However, I don't want to rule it out just yet.
I should also mention that I have some deployment-requirements as well:
- Must be able to run as non-admin.
- Must be able to handle restrictive local firewall-restrictions.
- Deployment must be automatic (it's a large scale consumer-app) and work on Windows, Mac OS X and Linux.
Given these restriction what solution would you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不久前我也遇到过同样的情况，只不过后端是Python，GUI是java。
需要考虑的要点：
您可能会发现 JSON-RPC 很有用：它是对单独程序的远程方法调用的标准。
总而言之，我很难说什么对你来说是最好的。我最终避免了 RPC，并为后端提供了一个简单的命令行界面；输出作为 JSON 对象写入临时文件和 STDERR。我觉得这是一个很好的决定，因为它使程序之间的接口非常简单且解耦。
I faced this same situation a while back, except that the back-end was in Python, and the GUI was in java.
Important points to consider:
You might find JSON-RPC useful: it's a standard for remote method calls to separate programs.
All in all, it's hard for me to say what would be best for you. I ended up avoiding RPC, and gave the back-end a simple command-line interface; output was written to temp files and STDERR, as JSON objects. I feel that this was a good decision because it kept the interface between the programs very simple and uncoupled.