JEP 208: Java Packager ImprovementsJEP 208: Java Packager ImprovementsAuthorMarty ThompsonOwnerDanno FerrinTypeFeatureScopeJDKStatusClosed / DeliveredRelease8u40ComponentdeployDiscussionopenjfx dash dev at openjdk dot java dot net EffortLDurationLReviewed bySteve NorthoverEndorsed byRichard BairCreated2014/05/13 23:18Updated2015/02/26 14:07Issue8043060Summary
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.
InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
