Eclipse IDE是用Java编写的大型桌面应用程序的最佳示例之一.
我见过的大多数Java应用程序通常依赖于批处理或shell脚本来构建具有应用程序类路径的字符串,并使用类路径作为env变量启动JVM.
另一方面,Eclipse依赖于本机启动器.这是为什么 ?这个启动程序的脚本没有做什么?
我记得在大约一年半前读过一篇文章解释说"我们用本地发射器会更好",但是id没有解释发射器的内部工作原理.
在春分发射使用JNI来启动Java虚拟机在同一进程的启动.使用JNI还允许我们在启动屏幕中使用SWT小部件.
实际上,你仍然可以拥有一个脚本,因为启动器可执行文件eclipse.exe自3.3M5以来已被分成两部分:
可执行文件,和
共享库(例如:eclipse_1006.dll).
可执行文件位于eclipse安装的根目录中.
共享库org.eclise.equinox.launcher.[config]
位于plugins目录中的特定于平台的片段中.
将大多数启动器代码移动到存在于片段中的共享库意味着现在可以从更新站点更新启动代码的该部分.此外,从java开始时,可以通过JNI加载共享库以显示启动画面.
如此处所述,您可以在没有本机启动器的情况下启动Eclipse 3.3,
java -jar plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar
请注意,jar文件的名称现在依赖于版本,导致使用确切文件名调用jar的天真脚本,以便在jar文件更新后中断.
相反,您可能希望寻找文件匹配org.eclipse.equinox_*.jar
.值得庆幸的是,Eclipse-wiki包含适用于此情况的脚本模板.
如果要避免修改现有脚本,还可以搜索Equinox Launcher插件,将其复制到Eclipse主目录中,并将副本重命名为startup.jar.
其中一些是特定的窗口,有些是一般的.
与目标平台的本机可用脚本语言中的批处理脚本相比,您的shell集成得到了很大改进.
无需启动额外的进程来执行脚本(如果您将IDE本身编写为构建/测试/部署周期的一部分,则这可能是一个大问题.
可执行文件头通常定义程序的"位数".因此,可执行文件可以明确指示它允许/不允许32位或64位执行.
Windows上的可执行文件可以加密签名.
许多恶意软件/防火墙保护程序维护每个可执行的白名单.因此,当第一次出现eclipse("Eclipse正试图访问互联网"而不是通用的"javaw.exe"时,启动eclipse(它会自动检查Web上的更新)会更好.试图访问互联网".它还允许用户对此行为进行更细粒度的控制.
该过程将在ps /任务管理器上显示为"you_app_name"而不是java -jar"您的jar文件".这样可以更轻松地跟踪/管理错误的流程.在开发环境中有些不常见的东西.
其他答案都是高度技术性的,但在我看来,我认为它的原因很简单:用户体验.
最终用户不必为了使其工作而烦恼.(是的,如果你想使用不同的虚拟机或将args传递给虚拟机等,你可以大惊小怪,但你没有必要).
对于用户而言,没有什么比安装程序更好的了,然后尝试运行它,只是为了得到一个dos框,上面写着"输入java vm的路径",或者更糟糕的是,你双击它并没有任何反应因为你有编辑批处理文件以使其工作.
这是2009年,而不是1996年.没有用户(甚至开发人员!)应该编辑批处理文件以使程序第一次运行.