Java 小程序 - 今天的选择是错误的吗？

Question

我有一些重要的计算代码，需要应用于已下载到浏览器 DOM 中并从用户交互中捕获的数据。我不想公开这段代码。我想知道是否:

1. 编写 Web 服务并通过 WebSocket 或 HTTP 与浏览器通信。权衡是交互速度(从流畅到糟糕)和更高的流量成本。
2. 编写一个 Java 小程序(经过签名以隐藏代码)，将逻辑封装在页面内，并让 JavaScript 与 Java API 进行交互。我在其他地方读到，Java 和 JavaScript 引擎在某些情况下可能会出现死锁。然而，由于我只是计算，所以这不是问题。也许，在多核机器上我可以使用更多线程来分配我的工作。
3. 用 JavaScript 编写。但 JavaScript 很难测试，这一切都在公众的视线中。

诸如 Usability of Java applets on the web 和其他一些问答也令人沮丧。

Java applet 是一种死技术吗？这些天甚至没有关于这个话题的问答!此外，Java 可能并不总是与所有浏览器(桌面、平板电脑或移动设备)捆绑在一起？

是否有更好的方法来完成相同的任务，例如隐藏代码、利用客户端 CPU/RAM、最小化数据流量？

网页基于 JavaScript、HTML5 和 CSS。服务器仅提供 JSON 和 XML。数据包大小为 10-20 KB，并且更新频繁。计算成本高昂且特定于客户端，因此我真的很想使用客户端来完成所有这些工作。

Answer 1

我认为小程序的最大缺点是它假设您有一个 JRE安装在客户端计算机上。这真的是一个可行的假设吗？

当然，您也可以提供下载并安装 JRE，但为什么只为了进行一些计算而费心做这一切呢？我会问自己的另一个问题是，你的客户端可以是手机、平板电脑等吗？如果是这样，也许 JavaScript 是更好的选择。

还有两分钱:)你提到了“开眼JavaScript”您应该明白，保护计算代码的唯一真正方法是将计算放在服务器上。我的意思是，即使您有已编译的二进制代码，Java 的汇编对于熟练的攻击者来说也很容易理解。您提到的混淆(这是混淆，而不是签署 JAR 文件)使其变得稍微困难​​，但仍然不是不可能。

我在这里看到的唯一问题是，如果您有很多客户端同时运行计算，并且您将计算负担放在服务器上，那么它最终可能会崩溃。