我一直在思考如何将Java项目转换为EXE
。
优点在于更快地在Windows上部署,用户只需双击EXE
,应用程序就会启动,而使用Java时,他必须运行某些命令。
但是EXE
并不是Java的初衷,即可移植性。
那么,你认为Java转EXE是好还是坏的想法?
我在这里找到了一些有趣的文章here。
更新
哇,到目前为止有很多相互矛盾的观点。我希望你们能添加JAVA转EXE的优缺点。
我一直在思考如何将Java项目转换为EXE
。
优点在于更快地在Windows上部署,用户只需双击EXE
,应用程序就会启动,而使用Java时,他必须运行某些命令。
但是EXE
并不是Java的初衷,即可移植性。
那么,你认为Java转EXE是好还是坏的想法?
我在这里找到了一些有趣的文章here。
哇,到目前为止有很多相互矛盾的观点。我希望你们能添加JAVA转EXE的优缺点。
由于我的专业是Java Web Start,它用于启动带有GUI的桌面应用程序,请将我的建议视为主要针对这些类型的应用程序。
Jon进一步指出:当您发送标准Java字节码时,VM问题是平台或VM供应商的责任。但是,当您发送已编译的二进制文件时,它们成为您的责任(即使它们实际上是供应商编译产品中的错误)。
...
..Java Web应用程序需要互联网连接吗?
请注意,名称为“Java Web Start”。
当然需要。至少在初始安装时需要。如果用户当前未连接,则可以指定更新检查以继续启动先前安装的应用程序版本。
但是,在我看来,没有CD / DVD驱动器的机器(例如Netbook)比没有互联网连接的机器更多。 如果想要销售更大的市场,请考虑使用网络提供应用程序。
这取决于您的需求。我们为客户编写了一个小型条形码客户端扫描应用程序。他们在两台Windows PC上运行它。他们很高兴拥有自己熟悉的exe文件。我们使用Java编写了它,并为他们创建了一个EXE文件。
双方都对此感到满意 - 那么为什么不这样做呢?
如果有充分的理由支持它,而且除了教条主义之外没有任何反对意见,那么在我看来是可以的。
我是您所链接文章的作者,很高兴您觉得它有趣!
正如我的文章所述,并且其他人在他们的回答中已经指出的那样,有多种简化Java应用程序部署的方法 - JNLP、EXE包装器、捆绑私有JRE的安装程序等等。但是真正的本地编译是唯一提供保护Java反编译工具的选项——您根本不会发布字节码。
当然,这并不能使您的代码逆向工程和篡改变得不可能,只是需要更多的技能和时间成本。
就应用程序性能而言,如果您针对嵌入式系统,则本地编译可以产生巨大的差异。这也适用于内存和磁盘占用空间,尽管影响较小。在桌面上,您通常会获得更好的启动速度,但在大多数其他情况和方面,结果将取决于您的应用程序。
这个链接背后的页面是由一家销售将Java编译成本地代码的产品的公司编写的。我不会仅凭此作出决定。
问题还说exe具有更好的用户体验,因为用户只需双击即可启动应用程序。
使用可执行的jar文件是可能的。实际上,在Java运行时中使用标准工具非常容易。您只需向一个jar文件添加清单,并指定含有主要内容的类。您还可以相对于主jar文件的位置指定其他jar文件的类路径。您还可以将图像指定为资源,以用作启动画面。
例如:
Class-Path: lib/derby.jar lib/derbytools.jar lib/jcalendar-1.3.2.jar l
ib/joda-time-1.4.jar lib/log4j-1.2.14.jar lib/looks-2.2.1.jar lib/swi
ng-layout-1.0.jar
SplashScreen-Image: resources/splash.png
Main-Class: com.you.pkg.app.Main
根据用户群体而定。如果他们与技术有关,那么给他们一个可以通过双击运行的 .jar
文件是移动性的好主意。
如果您的用户不太懂技术,但仍需要在多个平台上运行,则将其包装为 Windows 的 exe
和 Mac 的 .app
。
重要提示:建议编写一个脚本将其打包成 exe,这样每次有新版本时就可以运行它。