JEP 282: jlink: The Java Linker
Author | Jean-Francois Denise |
Owner | Jim Laskey |
Created | 2015/07/16 12:55 |
Updated | 2016/03/14 16:06 |
Type | Feature |
Status | Proposed to Target |
Component | tools / jlink |
Scope | SE |
JSR | TBD |
Discussion | jigsaw dash dev at openjdk dot java dot net |
Effort | L |
Duration | L |
Priority | 2 |
Reviewed by | Alan Bateman, Alex Buckley, Iris Clark, Jim Laskey, Mark Reinhold |
Endorsed by | Brian Goetz |
Release | 9 |
Issue | 8131679 |
Blocks | JEP 275: Modular Java Application Packaging |
Depends | JEP 261: Module System |
Relates to | JEP 220: Modular Run-Time Images |
Summary
Create a tool that can assemble and optimize a set of modules and their dependencies into a custom run-time image as defined in JEP 220. Define a plugin mechanism for transformation and optimization during the assembly process, and for the generation of alternative image formats.
Non Goals
This JEP does not commit the resulting tool to generate anything other than a modular run-time image. The plugin mechanism can be used to generate other image formats.
It is not a goal of this JEP to define a standard or supported API for plugins. Instead, the plugin API will be strictly experimental. A future JEP may re-visit this topic once experience has been obtained using the plugin API defined by this JEP.
Motivation
JEP 261 defines link time as an
optional phase between the phases of compile time (the javac
command)
and run time (the java
run-time launcher). Link time requires a linking
tool that will assemble and optimize a set of modules and their
transitive dependencies to create a run-time image or executable.
Link time is an opportunity to do whole-world optimizations that are otherwise difficult at compile time or costly at runtime. An example would be to optimize a computation when all its inputs become constant (i.e., not unknown). A follow-up optimization would be to remove code that is no longer reachable.
Description
A basic invocation of the linker tool, jlink
, is:
$ jlink --modulepath <modulepath> --addmods <modules> --limitmods <modules> --output <path>
where:
--modulepath
is the path where observable modules will be discovered by the linker; these can be modular JAR files, JMOD files, or exploded modules--addmods
names the modules to add to the run-time image; these modules can, via transitive dependencies, cause additional modules to be added--limitmods
limits the universe of observable modules--output
is the directory that will contain the resulting run-time image
The --modulepath
, --addmods
, and --limitmods
options are described
in further detail in JEP 261.
Other options that jlink
will support include:
--help
to print a usage/help message, including usage of plugins--version
to print version information--plugins-modulepath
to specify the module path where plugin modules are located
Plugins
The plugin API will be strictly experimental and may be the subject of a future JEP.
jlink
gathers the classes, native libraries, and configuration files
into a set of resources. These resources are fed through a pipeline of
transformers, which are defined by plugins. Each transformer may
transform the resources into new resources before they are fed to the
next transformation in the pipeline. After all transformers have been
applied, the tool feeds the final set of resources to an image builder.
Example built-in plugins that jlink
will provide:
- Compress class files
- Strip debug attributes from class files
- Order resources to reduce file access latency at startup
Other plugins that may be developed:
- Pre-verification of bytecodes
- Post-image generation processing
Plugins are packaged as modules and placed on the plugin module path,
which is specified by the --plugins-modulepath
option. Plugins can add
command-line options to jlink
so that they can be enabled and
configured. For example, the strip debug plugin adds the option
--strip-java-debug
to the command-line interface.
Open design issues
Should
jlink
do service binding? It may be confusing for users to havejlink
do service binding by default. An alternative is an additional command-line option to do service binding, or an option to add the service providers for specific service types.The execution order of plugins, and how the ordering is described, is not yet settled.
Alternatives
The alternative to a linking tool is to use platform-specific JDK and JRE image-build scripts. This approach would make it difficult to create custom run-time images.
Testing
Beyond the expected set of unit tests to exercise the tool and the
experimental plugin API, the JDK build will regularly exercise jlink
by
creating the JDK and JRE run-time images.
Risks and Assumptions
The set of requirements for the tool is not complete at this time. The tool's extensibility is expected to evolve.
Dependences
This JEP depends on the module system that will be specified by JSR 376 (Java Platform Module System) and implemented by JEP 261: Module System.
The initial implementation of JEP 220 in JDK 9 uses a custom build-time tool to construct JRE and JDK images. That tool will be replaced by
jlink
.Pre-verification requires a final
jlink
phase to generate whole-world class-dependency data. This pre-verification data will be added to the final run-time image byjlink
.