优势依赖于在Windows上更快部署,用户只需双击EXE并启动应用程序,而Java必须运行某些命令.
但是EXE实际上不是Java的目的,便携性.
那你觉得Java对EXE的好坏有什么看法？
更新
哇,所以可能与目前的观点相矛盾.我希望你们把JAVA的优点和缺点添加到EXE中.
解决方法
其他人评论了EXE的操作系统特性.我总是想知道为什么人们会选择Java来开发Windows特定的桌面应用程序.因为用于Windows的Visual Studio软件可能会同时进行GUI开发(没有x-plat Java布局可以帮助你)和部署(只是猜测它可以产生EXE)更容易.
OTOH只有你可以说这个用例的最佳开发工具/语言是什么.
至于创建EXE的潜在缺点,我在JavaFAQ on EXEs注意到.
将应用程序打包到可执行文件中有很多好的理由. DanielSjöblom指出：
>它可能不会更快.现代虚拟机不解释字节码,它们实际上使用JIT编译器来生成本机编译代码.查看Sun的站点以获取有关JIT编译器的更多信息.
>静态编译会使应用程序的大小增加多倍,因为您使用的所有库都需要链接到应用程序中.
>您失去了对程序的“免费”升级.只要您的用户下载新的更快的虚拟机,您的应用就会获得速度提升.如果您使用的是exe,则无法获得此优惠.
Jon A. Cruz详细介绍了创建exe所需的开发过程中的一些额外步骤.他指出开发人员需要本机exe需要：
>从供应商处验证最新版本的编译产品.如果发现严重错误,则在解决这些问题之前,不能将其用于构建运输产品.每次从供应商处发布修订时都需要完成的工作.
>通过质量保证周期提交软件.一旦工程师认为事情已经完成,就需要对其进行验证.因此,产品的每个发货版本和更新都需要经历完整的测试周期.
>此外,由于本机编译是针对每个目标平台,因此需要针对每个目标平台完全执行QA周期,这需要增加所需的工作量.
>货架空间.也许现在不是什么大不了的事,但可能会.
>然后需要让所有客户升级到正确的版本.要么有免费更新(在这种情况下业务需要承担产生更新的成本),或者需要处理客户端而不是所有更新.
Jon进一步指出：当您发布标准Java字节码时,VM问题是平台或VM供应商的责任.但是,当您发送已编译的二进制文件时,它们将成为您的责任(即使它们实际上是供应商编译产品中的错误).
…
当然,我是部署Java富客户端应用程序的首选.正在使用Java Web Start.以点式形式提供web-start的一些好处/功能：
>闪屏
>桌面集成
>文件关联
>自动更新(包括延迟下载和更新的程序控制)
>本地人和他人的分区按平台,体系结构或Java版本下载的其他资源,
>运行时环境的配置(最小J2SE版本,运行时选项,RAM等)
>使用扩展轻松管理公共资源
..
随着应用逐渐转变,我决定突出自动更新.在磁盘上传递给应用程序.通过网络提供,自动更新变得越来越普遍. JWS仍然提供了最好的更新体验(非常可配置,对用户来说几乎是透明的)我见过.
当然,JWS适用于可用于Java的桌面PC的操作系统.
更新
..does Java web apps require internet connection?
(注意,名称是’Java Web Start’.)
当然可以.至少对于初始安装.可以指定更新检查以继续启动以前安装的应用程序版本.如果用户当前未连接.
但是,(据我估计)有更多的机器(如上网本)没有CD / DVD驱动器,没有互联网连接.如果您想要销售到更大的市场,请访问网络以提供应用程序.
