桌面Java没有AdobeAIR本机扩展的替代方案

背景

我们有一个由Java后端支持的AIR客户端应用程序

在我们的应用程序中，我们有一个复杂的数据网格，可以一次捕获大量数据。每个单独的数据单元可能会触发繁重的计算/处理。这将重复发生，直到用户满意并保存最终版本

某些处理的本质要求很大一部分由Java完成。再加上大量的用户，我们肯定会遇到服务器性能问题

我们需要将大部分处理移到客户端

问题

现在，当用户提交最后一组输入时，服务器将在持久化它们之前执行最后一次计算。这意味着我们需要一组Java类来执行所有需要的计算/处理

因为我们已经在编写Java类，所以最好是在客户端将它们作为库重用，而不是在Flex中重新编写它们并同时维护它们

我们认为AdobeAIR的本机扩展是完美的——直到我们发现Windows上只支持DLL。由于我们的交付机制（Java库没有.exe），我们也不能使用NativeProcess

问题

到目前为止，我们已经尝试过Merapi，但考虑到它已经停用了一段时间，我们担心将来的兼容性。我们想知道Merapi是否还有其他替代品

---

或者更好的方法是，尝试在AIR应用程序和Java库之间创建一个通信桥梁来解决这个问题。

您有一些选择，这取决于您愿意做多少工作

<强>如果你愿意考虑除Flex以外的其他事情…<强> < /P> 您可以选择小程序，因为：

它在浏览器中运行，可以与应用程序通信，并使用客户端上的浏览器资源执行计算

或者，这是我最喜欢的，您可以编写一个Java Webstart部署的桌面应用程序。这将完全在客户端上运行，不会消耗服务器上的资源，可以通过RMI或简单的消息与服务器通信，尽可能接近本机桌面应用程序并自行更新，因此不会出现部署问题

第三个选项更为棘手，但从理论上讲，您可以使用类似GWT的东西用Java编写应用程序，然后通过GWT将其转换为Javascript应用程序。这在浏览器中运行，但有严重的局限性，我的拙见是，GWT Javascript几乎不可读，难以定制

备选方案：

将应用程序编写为标准web应用程序，并使用Javascript在客户端执行计算。问题是您将无法重用Java类

结论（应该阅读，最谦逊的意见）

---

总而言之，通过Webstart部署的Java桌面应用程序看起来是最好的解决方案。它将允许您重新使用计算代码，并将极大地利用客户端资源。

为什么不能用Java开发客户端应用程序呢？这是因为我们的产品位于一个内部框架上，使用Flex作为前端。因此，我们必须坚持使用类似的方法。我们必须坚持使用Flex的一个主要原因是我们必须重用所有Flex接口代码（我们有一个动态UI引擎）。如果我们抛弃Flex，这意味着我们必须重新创建UI引擎。我们知道，我们可以用其他技术来实现这一点，但不幸的是，这些都是限制因素。我想你当时只能使用空气，我看不到解决办法。你可能想开始研究另一种解决方案。是的，我们已经用Merapi做了一些可行的事情，但是这个项目现在似乎不活跃了。因此，我们正在探索其他选择，包括使用NativeProcess作为解决方案。祝您好运，请在找到答案时添加答案，它将在将来帮助他人。