Java 到 EXE 好还是坏主意？
我长期以来一直想知道如何将 Java 项目转换为 EXE。
其优点在于在Windows上的部署速度更快，用户只需双击EXE，应用程序就会在使用Java的情况下启动，他有运行某些命令。
但是EXE实际上并不是Java的可移植性的初衷。
那么您认为 Java 到 EXE 好还是坏？
我在此处发现了一些有趣的文章。
更新
哇，到目前为止可能存在矛盾的观点。我希望你们能补充一下 JAVA 到 EXE 的优点和缺点。
I have been wondering for a long time about converting Java projects to EXE.
The advantages relies in the faster deployment on Windows where the user simply double clicks the EXE and the application is launched where is with Java, he has to run certain commands.
But EXE is really not what the Java was intended for which is portability.
So what do you think, Java to EXE good or bad idea?
I found some interesting article here.
Update
Wow, so may contradicting views so far. I would like you guys to add the pros and cons of the JAVA to EXE.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
因为我的专业知识是 Java Web Start，它用于启动桌面应用程序。对于 GUI，请考虑我的建议，主要针对这些类型的应用程序。
其他人对 EXE 的操作系统特定性质进行了评论。我总是想知道为什么人们选择 Java 来开发 Windows 特定的桌面应用程序，因为 Windows 的 Visual Studio 软件可能会同时进行 GUI 开发（没有 x-plat Java 布局让你低头）和部署（只是猜测它可以生成 EXE）更容易。
OTOH 只有您才能说出适合此用例的最佳开发工具/语言。
至于创建 EXE 的潜在缺点，我在 EXE 上的 JavaFAQ 中指出。
有很多充分的理由不将应用程序打包为可执行文件。 Daniel Sjöblom 指出：
Jon A. Cruz 详细介绍了创建 exe 所需的开发过程中的一些额外步骤。他指出，制作本机 exe 的开发人员需要：
Jon 进一步指出：当您发布标准 Java 字节码时，VM 问题是平台或 VM 供应商的责任。但是，当您发布编译的二进制文件时，它们就成为您的责任（即使它们实际上是供应商编译产品中的错误）。
...
当然，我部署Java富客户端应用程序的首选。正在使用 Java Web Start。以点形式表述 Web-start 的一些优点/功能：
JWS 提供了许多吸引人的功能，包括但不限于：
..
随着应用程序的逐渐转变，我决定强调自动更新。在磁盘上传递给应用程序。通过网络交付，自动更新变得越来越普遍。 JWS 仍然提供了我见过的最好的更新体验（非常可配置，对用户来说大部分是透明的）。
当然，JWS 可在可使用 Java 的台式电脑操作系统上运行。
更新
（请注意，名称是“Java Web Start”。）
当然可以。至少对于初始安装来说是这样。可以指定更新检查以继续启动以前安装的应用程序版本。如果用户当前未连接。
但是，（据我估计）没有 CD/DVD 驱动器的机器（例如上网本）比没有互联网连接的机器要多。 如果您想向更大的市场销售，请寻求网络来交付应用程序。
Since my expertise is with Java Web Start, which is for launching desktop apps. with a GUI, please consider my advice to be targeted mostly at those types of apps.
Other people have commented on the OS specific nature of an EXE. I always have to wonder why people choose Java to develop Windows specific desktop apps., since the Visual Studio software for Windows would probably make both GUI development (no x-plat Java layouts to bend your head around) and deployment (just guessing it can produce an EXE) easier.
OTOH only you can say what is the best development tool/language for this use-case.
As to the potential disadvantages of creating an EXE, I note at the JavaFAQ on EXEs.
There are a number of good reasons not to package your application in an executable. Daniel Sjöblom notes:
Jon A. Cruz details some of the extra steps in the development process required to create an exe. He points out that developers making native exe's need to:
Jon notes futher: When you ship standard Java bytecodes, VM problems are the responsibility of the platform or VM vendor. However, when you ship compiled binaries, they become your responsibility (even if they're actually bugs in the vendor's compilation product).
...
Of course, my first choice for deploying Java rich client apps. is using Java Web Start. Putting some of the benefits/features of web-start in point form:
JWS provides many appealing features including, but not limited to:
..
I decided to highlight auto-update since with the gradual shift from apps. delivered on disk to apps. delivered over a network, auto-update is becoming more common. JWS still provides the best update experience (very configurable, mostly transparent to the user) I've seen.
And of course, JWS works on OS' for desktop PCs for which Java is available.
Update
(Note that name is 'Java Web Start'.)
Sure it does. At least for the initial installation. Update checks can be specified to continue to launch the previously installed version of the app. if the user is not currently connected.
But then, (in my estimation) there are more machines (such as Netbooks) with no CD/DVD drive, than there are without internet connections. If you want to sell to the larger market, look to the network to deliver the app.
这取决于您的需求。我们在这里为我们的客户编写了一个小型条形码客户端扫描仪应用程序。他们在两台 Windows PC 上运行它。他们很高兴拥有众所周知的 exe 文件。我们用 Java 对其进行编码并为它们创建了一个 EXE 文件。
双方都对此感到满意——那为什么不这样做呢？
当有充分的理由并且除了教条主义之外没有什么反对的时候，那么我认为这是可以的。
It depends on your needs. We had written a little barcode client scanner app here for our customer. They run it on two Windows-PCs. They are happy having their well-known exe-files. We coded it in Java and created an EXE-file for them.
Both parties are happy with it - so why not doing it?
When there are good reasons for it and nothing against it except dogmatism then it is ok in my opinion.
我是您链接到的文章的作者 - 很高兴您发现它很有趣！
正如我的文章所述，以及其他人在其答案中已经指出的那样，有多种方法可以简化 Java 应用程序的部署 - JNLP、EXE 包装器、捆绑私有 JRE 的安装程序等等。但真正的本机编译是唯一同时提供针对 Java 反编译器的保护的选项- 你根本不发送字节码。
当然，这并不意味着对代码进行逆向工程和篡改是不可能的，只是在所需的技能和时间方面成本更高。
就应用程序性能而言，如果您的目标是嵌入式系统，本机编译可以产生很大差异。这也适用于内存和磁盘占用空间，尽管程度较小。在桌面上，您通常会获得更好的启动效果，但在大多数其他场景和方面，结果将取决于您的应用程序。
I am the author of the article you linked to - glad you've found it interesting!
As my article states, and as others have already pointed out in their answers, there are multiple ways to simplify deployment of Java apps - JNLP, EXE wrappers, installers bundling a private JRE, and so on. But true native compilation is the only option that also provides protection against Java decompilers - you simply do not ship the bytecodes.
Of course, that does not make reverse engineering of and tampering with your code impossible, just much more costly in terms of required skillset and time.
As far as application performance is concerned, native compilation can make a big difference if you target embedded systems. This also applies to memory and disk footprint, albeit to a smaller extent. On the desktop you would typically get better startup, but in most other scenarios and aspects the results would depend on your app.
如果有充分的理由为什么不呢？即使 Eclipse 在 Windows 上也有一个 EXE（以及 Linux、Mac 等平台相关的二进制文件），当然你会失去可移植性，但如果这不重要，那就继续吧。
更新
问题是你想通过创建一个exe来实现什么：
方便：Windows上的用户更喜欢点击图标，对于非极客来说尤其如此。另一方面，非极客并不关心链接在启动 exe 或其他东西时在内部做什么。您也可以为非本机 Java 应用程序提供应用程序图标。替代方案是
性能：如果将 Java 应用程序编译为本机解决方案，您可能会获得一些性能提升，但这取决于您使用的技术。例如，Swing 往往很慢，但将其编译为本机却相当棘手。如果您使用 SWT 而不是已经使用本机组件的 Swing，则无需进一步进行本机编译。另一方面，最近的 JVM 性能非常好，可以将 java 编译为本机，进一步改善性能瓶颈。这是在后台默默完成的，您无需担心。
Sum：在某些情况下，它可能是唯一的解决方案，但如果您选择正确的技术，将会有许多基于 Java 的替代解决方案来达到相同的目标。
If it has a good reason why not? Even Eclipse has an EXE on windows and (and platform dependent binaries for linux, mac, etc) Of course you loose portability but if that is not important then go ahead.
UPDATE
The question is what do you want to achieve by creating an exe :
Convenience : users on windows prefer to click on icons, this is especially true for the non geeks. On the other hand non geeks don't care what the link does internally if it starts up an exe or something else. You can have an application icon for non native Java applications too. The alternatives would be
Performance : If you compile your Java application into a native solution you may gain a bit on performance but it depends on what technology you use. For example Swing tends to be slow but compiling that to native is rather tricky. If you use SWT instead of Swing that is already using native components therefore no need for further native compilation. On the other hand recent JVMs perform very well and can compile java to native to further improve the performance bottlenecks. This is done silently on the background you dont need to worry about that.
Sum : in some cases it might be the only solution, but if you choose the right technologies there will be many Java based alternative solutions to reach the same goal.
问题中链接后面的页面是由一家销售将 java 编译为本机代码的产品的公司编写的。我不会仅以此为基础做出决定。
问题还说exe的优点是更好的用户体验，因为用户只需双击即可启动应用程序。
对于可执行的 jar 文件是可能的。事实上，使用 java 运行时中的标准工具实际上非常容易。您只需将清单添加到 jar 文件，并指定其中包含 main 的类。您还可以在类路径中指定相对于主 jar 文件位置的其他 jar 文件。您还可以指定用作启动屏幕的图像作为资源。
例如，
如果您使用 Netbeans 中的基本 ant 项目，它将为您完成除闪屏之外的所有操作。如果您出于某种原因想要手动完成所有这些操作，请确保您了解清单文件的格式，它有点挑剔。
The page behind the link in the question is written by a company that sells products that compile java to native code. I would not base a decision on that alone.
The question also says that the advantage of the exe a better user experience, because the user can just double click to launch the application.
That is possible with executable jar file. In fact, its actually quite easy with standard tools in the java runtime. You just have to add a manifest to a jar file, and specify the class with the main in it. You can also specify other jar files in the classpath relative to the location of the main jar file. You can also specify an image to use as a splash screen as a resource.
e.g.
The basic ant project in Netbeans will do all but the spash-screen for you if you use it. If your some reason you want to do all of that by hand, make sure you understand the format of the manifest file, its a bit finicky.
作为 Linux、mac、Solaris 用户，我认为这是个坏主意。
如果您想在 Windows 上更快地部署，只需创建安装程序。
As Linux, mac., Solaris user I think this is bad idea.
If you want faster deploy on windows, just create installer.
Jar 文件提供了许多好处，包括：
紧凑：整个应用程序（即所有类文件）存储在一个存档文件中（如果需要，可以合并图像和声音文件）。
易于使用：该应用程序可以通过双击运行。
压缩：jar 格式允许您压缩文件以实现高效存储。
安全性：您可以对 jar 文件的内容进行数字签名。识别您签名的用户可以选择授予您的软件安全权限，否则它不会拥有这些权限。
我不会转换为exe。
大多数 Windows 应用程序从 .exe 文件运行（Word、Internet Explorer、FireFox、NetBeans...）
Java 本身不支持这样做，因为可执行文件将依赖于平台（即它不能在 Mac 上运行）
但是，有（免费）应用程序可以为您执行此操作。
Jar files provide many benefits including:
Compact: The whole application (i.e. all the class files) is stored in one archive file (which can incorporate image and sound files if required).
Ease of use: The application can be run by double-clicking.
Compression: The jar format allows you to compress your files for efficient storage.
Security: You can digitally sign the contents of a jar file. Users who recognise your signature can then optionally grant your software security privileges it wouldn't otherwise have.
I would not convert to exe.
Most Windows applications run from a .exe file (Word, Internet Explorer, FireFox, NetBeans, ...)
Java itself has no support for doing this as the executable file will then be platform dependent (i.e. it won’t run on Macs)
However, there are (free) applications that can do this for you.
Minecraft 做到了，所以这一定是个好主意！
抛开所有笑话，请理解您正在寻找的不是“转换”，而是使用自定义启动器。您链接的文章很好地解释了不同的方法以及每种方法的优缺点。一般来说，它需要创建启动器的额外工作（以及针对每个不同操作系统架构的不同版本），但它为您提供了更多的控制权（版本检查是一个很好的功能，您也可以更新应用程序 jar 而不是很容易，就像《我的世界》那样）。总的来说，如果您认为值得付出努力并且在可移植性方面有（一点）损失，那么这是一个好主意。
编辑：如果您不需要下面的方法提供的真正漂亮的额外功能，那么您应该使用“自定义 Java 启动器和包装器”方法。
Minecraft does it, so it must be a good idea!
All jokes aside, understand that it's not 'conversion' that you are looking for, but using a custom launcher. The article you linked does a nice job of explaining the different approaches and pros/cons of each. As a general idea, it requires the extra work of creating the launcher (and a different version for each different OS architecture), but it gives you a little more control (version checking is a nice feature, also you may update the application jar rather easily, like Minecraft does). Overall it's a good idea if you think it's worth the effort, and the (little) loss in portability.
Edit: the 'Custom Java Launchers And Wrappers' approach is the one that you should use if you don't need the really nifty extra features offered by those below it.
取决于用户群。如果它们无论如何都与技术相关，那么为它们提供一个
.jar文件（可以通过双击运行）对于移动性来说是一个好主意。如果您的用户不太懂技术，但您仍然需要它在多个平台上运行，则将其包装为 Windows 的
exe和 Mac 的.app。重要：我建议制作一个脚本将其包装到 exe 中，以便每次有新版本时运行它。
Depends on the user base. If they are tech-related in anyway then giving them a
.jarfile (which could be run by double click) is a good idea for mobility.If your users are less techy but you still need it to run on multiple platforms then wrap it as
exefor Windows and as.appfor Mac.Important: I would suggest making a script to wrap it into exe, so you run it each time you have a new version.