将 SWT 应用程序编译为本机应用程序的优点和缺点
谁成功地将 Java 商业项目编译为本机（例如使用 GCJ 或 Excelsior JET）并可以分享优点和缺点？
我认为有以下优点：
- 速度更快（用户的机器不需要将字节代码编译为本机代码），
- 破解的可能性较小，
- 不需要单独的 Java 运行时
，缺点如下：
- 需要为每个平台进行特殊构建以支持（但这是 SWT 所必需的）已经）
- 像反射这样的一些功能可能不起作用？
- 更难找到错误（堆栈跟踪怎么样）？
Who has successfully compiled a Java business project to native (e.g. using GCJ or Excelsior JET) and can share the pros and cons?
I image following advantages:
- more speed (the user's machine does not need to compile byte code to native code)
- less possibility to hack
- no separate Java runtime required
and following disadvantages:
- needs a special build for each platform to support (but that's required for SWT already)
- some features like reflection might not work?
- harder to locate bugs (what about stacktraces)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我已经使用 Excelsior JET 将 SWT 应用程序编译为本机对于 Windows。
这是不久前的事了，从那时起他们已经极大地改进了该工具，而且 JVM 速度也相应提高了。内存使用量并没有那么多，但现在即使是低端笔记本电脑也有 GB 的 RAM，虽然这可能会让我们的节俭意识感到厌恶，但如果您的小型 GUI 应用程序在一个至少具有 20MB 内存的盒子上使用 20MB 内存，那真的没关系50 倍，尤其是当您考虑到在这种环境中进行开发的优势时。
静态编译的主要原因是启动时间和内存使用。 JET 给了我这些，但代价是构建周期很长，由于动态加载与静态编译冲突而导致缺少类的错误（我相信他们已经改进了很多）和特定于平台的构建（您必须构建Windows 上的 Windows 发行版）。最终，摩尔定律和 JVM 速度使得这些权衡变得不值得，我放弃了这个构建选项。
FWIW，堆栈跟踪和反射都很好，动态类加载也很好，如果您确保编译器知道未静态引用的类。如果您担心反编译，那么混淆器可能会为您提供同样多的帮助。
对于 JET 和创造它的人们，我除了好话之外没有什么可说的。如果您需要这样做，JET 是一款可靠的产品。
I've used Excelsior JET to compile an SWT app to native for Windows.
This was some time ago, and they've improved the tool immensely since then, but JVM speed has since also improved commensurably. Memory usage not so much, but then even low end laptops have GB's of RAM these days and, although it might disgust our sense of frugality, it really doesn't matter if your small GUI app uses 20MB of memory on a box with at least 50x that amount, especially when you factor in the advantages of developing in this sort of environment.
The main reasons to static compile are startup time and memory usage. JET gave me these, but at the expense of a long build cycle, bugs in missing classes due to dynamic loading conflicting with static compilation (this is something I believe they've improved a lot) and platform-specific builds (you must build the Windows distro on Windows). Eventually Moore's Law and JVM speeds made these trade-off's not worth it, and I dropped this build option.
FWIW, stacktraces and reflection are fine, as is dynamic class loading if you make sure the compiler knows about the classes that are not statically referenced. If you're worried about decompilation, well, an obfuscator will likely give you as much mileage.
I have nothing but good things to say about JET and the people that make it though. If you need to do it, JET's a solid product.
我可以想到 2 个缺点
缺点：
开发成本。 Java最初使用解释器来运行代码
这更容易开发。
需要使用其他工具，例如GDB，这要复杂得多。再次，
增加您的开发成本
I can think of 2 cons
Cons:
development costs. Java originally use interpretor to run the code
which is far more easy to develop.
need to use other like GDB which is far more complicated. Again,
increase your development costs