JEP 208: Java Packager Improvements

Summary

Provide additional features and bundlers and an improved native-platform experience in the Java Application Packager.

Goals

Continue the evolution of the Java Packager started in 8u20. The 8u20 release updates the existing JavaFX Packager to ensure that it is able to create application bundles containing a native launcher and private JRE for both Swing and FX applications, and ensures that the tool may be adapted to work with all common IDEs. The next update is intended to improve the user experience further by adding requested features, additional bundlers, improved API, and improved native-platform fidelity.

Non-Goals

Adoption of the tool by major IDE vendors is outside the scope of these requirements.

Motivation

The existing application-bundling capability in the FX Packager has limitations in its support for app-store and non-FX applications, and is limited in flexibility when it is used as part of an existing build process. These enhancements to the work already in progress for 8u20 will simplify integration into IDEs and existing build scripts, and will address shortcomings in existing app store support.

Description

• Support command-line arguments comparable to JNLPs (RT-37766)

Currently the stand-alone applications created by the packager only handle command-line parameters passed in by command-line invocation of the program. (These are just the commands following the class name; JVM options are handled via another channel). We would add configuration options so that if no command-line options are passed in then a default set of options will be provided in its place. This is similar to how JNLP handles these options; adding support for this is necessary in order to create self-contained applications from JNLP files.

• Update the native launcher for self-contained applications so all supported platforms (Windows, Mac, Linux) use the same native source (RT-28833)

Currently the native launcher that is used by the packager is written in C++ on Windows, Objective-C on Mac, and C on Linux. It is very difficult to fix bugs and add new features because none of the source can be shared between the three platforms. If and when Solaris is added, or any other platform in the future, this problem will become exponentially more difficult. To single-source the launcher, platform-specific code will be implemented in a library of functions and classes. The core launcher code will be implemented once and will be the same for all platforms, relying on the platform-specific code to provide the appropriate functionality for each platform.

• Provide a user-friendly run-time API for self-contained applications to adjust JVM options (RT37767)

One of the facilities of the current launcher is a set of "user JVM options" that are alterable by the installed environment to customize the JVM at launch. This is useful in the case of the JVM heap size, or for debugging. It is, however, accessed via an arcane handoff with the Java preferences API. This feature would create some utility classes to provide a facade between the developer's Java code and the native launcher in order to update the user JVM options. For backward compatibility the current java.util.prefs technique will be supported. If a new facility is introduced in the single-source launcher then the backward-compatibility support will be a read-once-and-migrate step transparent to the application, otherwise it will be supported bidirectionally.

• Allow self-contained application packages to bundle multiple programs/entry points in the same installer package (RT-36118 and RT-34187, tangentially RT-35215)

Some applications are best deployed as an application suite, e.g., Adobe CS Suite or Microsoft Office. Currently there is only support for one application inside a bundle. Developers have requested the ability to have multiple applications within a bundle. On Windows and Linux this will be implemented by having multiple launchers (e.g., word.exe and PowerPoint.exe) that will share the same JVM. On Mac there are limited options to allow multiple applications in the same '.app' bundle, so this may not be supported on the Mac platform.

• Self-contained Mac applications currently require the JRE from the JDK; support bundling the standalone Mac JRE. (RT-35388)

Currently there is a problem where the Mac packager can only package a JRE found within the JDK. While non-redisiributable portions are stripped out, the unmistakable signature of the JDK file structure remains. This enhancement would allow the JRE to be used as the packaged runtime, making adjustments for the file-structure differences between the two packages.

• To address automated build problems, add an option to the Mac DMG bundler to remove all customizations. (RT-37769)

On Mac OS, the packager supports building a DMG that has a background image and a symlink to the application's folder to allow the user to easily drag and drop the application bundle for installation. The packager build process of generating a DMG that has a background and a symlink requires automating the Finder on the build machine, which can cause problems if other applications interrupt the automation of Finder and for example focus other windows. This is particularly annoying for developers building on their own machines because during the packager builds they cannot do other things such as read their email. If we provide the ability to make a simple DMG that does not have a background image or a symlink then this feature would cause less issues and be more usable.

• Installers for self-contained applications should be able to register file associations on the native platform as part of the install. (RT-23918)

JNLP allows the association of file extensions to a particular JNLP program. No such facility exists in self-contained applications. Implement the needed logic to support, at a minimal, the level of support found in JNLP.

Testing

Currently there is no testing of native code besides functional tests which test the entire product. When single-sourcing the launcher, native unit tests will be implemented at the same time as well as additional functional tests for things that are not testable with unit tests such as the splash screen.

Dependences

Single-sourcing the native launcher should be done before we create an API for the JVM options, create the splash screen, and make the Mac work with the JRE and not just JDKs. The reason is that the affected code from the older version of the launchers will be totally re-written for the single-source launcher.