近几个月来，ImageJ 发现与应用程序分发、打包和部署相关的问题越来越多。
今年夏天，LOCI 的 ImageJ 团队正在采取几项重大措施，以使ImageJ2 和Fiji 达到最新的 Java 打包和部署标准。
Java 6 的过时
Fiji 仍然搭载 Java 6。但是，Oracle 在 2013 年 2 月停止了对 Java 6 的支持。Java 7 于 2011 年 7 月 28 日发布——差不多四年前了。 Java 8 于 2014 年 3 月 11 日发布，距今已有一年多了。越来越多的人使用 Java 8，许多 ImageJ 插件开发人员希望开始利用强大的新 Java 8 语言功能。
ImageJ 尚未切换到 Java 8 的主要原因是 OS X 平台：Java 7 需要 OS X 10.7“Lion”或更高版本。运行 OS X 10.6“Snow Leopard”的用户无法升级到 Java 7 或 8，而拥有足够旧 Mac 的用户也无法升级到过去的 Snow Leopard，因为它们不满足硬件要求。因此，将 ImageJ 更新为需要 Java 8 将停止在那些旧 Mac 机器上对 ImageJ 的支持。
然而，此时，与 Java 6 相关的问题越来越多（尤其是在 OS X 上，请参阅下一节）：
- 用户在斐济的 Java 6 捆绑版本 (1.6.0_24) 中遇到严重崩溃，而使用 Java 7 或 Java 8 可以避免这种情况。
- ImageJ 使用的越来越多的库正在更新版本中将其版本要求更新为 Java 7。例如，Jython 1.7.0 现在需要 Java 7，因此，只要 ImageJ 继续使用 Java 6 运行，它就只能使用 Jython 1.5.3。
ImageJ 似乎不可避免地很快就会需要切换到 Java 8。至少，Downloads 页面上提供的 ImageJ2 和 Fiji 下载将更新为附带 Java 8 而不是 Java 6。我们正在强烈考虑更新核心 ImageJ2 组件以仅需要 Java 8。ImageJ Updater 将需要更新以支持这些更改。
OS X 上的 Java
Java 在 OS X 上的工作方式发生了根本性的转变。 Apple 不再提供自己的 Java 版本，而是依赖用户自行安装 Java，就像在 Windows 和 Linux 上一样。 Apple Java 的最后一个版本是 Java 6，它已经有两年多不受支持了（见上文）。 OS X 10.9“Mavericks”和 OS X 10.10“Yosemite”未预装 Apple Java 6，事实上，如果存在，则在升级时“卸载”它。 OS X 10.11“El Capitan”将是last OS X release to support Java 6。
此外，打包在 Apple Java 和 OpenJDK 上都能正常运行的 Java 应用程序还存在重大技术挑战（请参阅下一节）。
ImageJ 启动器
ImageJ 项目当前维护 ImageJ Launcher 组件，它是一段复杂的 C 代码，具有多层案例逻辑，旨在支持许多不同的操作系统和 Java 版本。 2008 年初斐济刚刚成立时，还没有合适的跨平台替代方案来启动 Java 应用程序。但如今，情况有所不同：Oracle 提供了一个名为 javapackager 的标准工具以及complete guide for Java application deployment。使用标准打包工具将大大简化 ImageJ 的持续开发，而不是继续维护 ImageJ 的自定义跨平台启动器。
ImageJ2 的独立稳定版下载
目前，ImageJ2 项目本身没有稳定的下载，仅适用于 Fiji 发行版。我们想要改变这一点：Downloads页面上的旗舰下载应该是普通的ImageJ2，斐济的下载在他们自己的页面上提供。需要提供以下下载：
- 应用程序安装程序和捆绑包包括Java 运行时——适用于 Windows、OS X 和 Linux。
- 应用程序安装程序和捆绑包不含 Java 运行时 — 适用于 Windows、OS X 和 Linux。
- 与平台无关的“便携式应用程序”捆绑包（没有 Java 运行时），用于拇指驱动器以及 Raspberry Pi 等其他平台。
使用行业标准工具部署 ImageJ
我们通过 Oracle’s Java packaging mechanism 将 ImageJ 打包为一个独立的应用程序，取得了巨大成功。这种相对较新的打包机制（JavaFX 软件套件的一部分）允许您以四种不同的方式部署 Java 应用程序：
- 作为独立的应用程序，即平台本机启动器（Windows 上的 .exe、OS X 上的 .app 等）
- 作为独立应用程序，即可双击的 JAR 文件。
- 作为 Java Web Start 应用程序
- 作为嵌入式网页，即 Java 小程序。
独立应用程序捆绑包与 ImageJ 最相关（尽管上述所有内容可能对软件开发的各个领域都有用）。借助 Java 的内置捆绑工具，我们将能够提供：
- 适用于 Windows 的本机 .msi 安装程序以及适用于 OS X 的本机 .dmg 和 .pkg 安装程序
- Windows 的 .exe 启动器和 OS X 的 .app 捆绑包
- 继续支持 Linux
- 供开发人员和调试使用的双击 JAR 文件入口点
通过这个新的部署方案，当前的 ImageJ Launcher 将退役。 ImageJ 将失去该启动器的一些功能，但这种更改是值得的，可以避免我们目前因数千行充斥着特定于平台的案例逻辑的本机 C 代码而产生的高维护负担。我们将提供 shell 脚本来涵盖一些最有用的功能，例如以远程调试模式启动 ImageJ。
Java 3D
Java 3D 库是 Java 的一个很棒的附加组件，它提供对 3D 可视化和渲染的支持。 3D Viewer 插件尤其需要它。不幸的是，从历史上看，Java 3D 是通过其自己的安装程序单独分发的，该安装程序必须修改 Java 运行时本身。这种方案意味着我们无法将 Java 3D 作为简单的 JAR 依赖项进行分发，这与 ImageJ 插件使用的其他库不同。因此，3D 查看器开发了自己的 Java 3D 自定义安装程序，以帮助用户更轻松地安装和运行。但 3D 查看器从外部网站下载 Java 3D，最近该网站的停机时间越来越长，这导致用户无法在新安装的设备上成功使用 3D 查看器，导致不断出现错误报告。
幸运的是，近年来，JogAmp团队更新了Java 3D，在底层使用了JOGL库，从而解决了JOGL和Java 3D所需的本机库的部署问题。我们有一个与 Fiji 捆绑在一起的 Java 3D 1.6 预发行版的工作原型，它使 3D 查看器能够工作，而无需用户将 Java 3D 显式安装到其 Java 运行时中。 https://github.com/imagej/imagej2/issues/120 imagej/imagej#120
问题报告
Fiji 附带了一个 Report a Bug 插件，可以向 Fiji BugZilla 发送错误报告。很快，我们将停用该系统，转而使用所有 ImageJ 和 Fiji 组件的 GitHub Issues。 “报告错误”插件将被彻底修改，以将报告发送到 GitHub Issues 上的相应组件，而不是 BugZilla。 （因此，用户不需要创建 Fiji BugZilla 帐户，而是需要拥有 GitHub 帐户。）这将有助于集成我们所有的问题跟踪，以及无缝链接到外部问题跟踪器，例如 Bio-Formats GH 问题跟踪器。 https://github.com/imagej/imagej2/issues/122 imagej/imagej#122
进一步阅读
有关我们在夏季解决的部署相关问题的完整列表，请参阅the list on GitHub issues。
正如你所看到的，这将是一个忙碌的夏天。我们将努力让更新、更强大的 ImageJ 为this fall’s ImageJ conference做好准备！
