Issue summary
-------------
#AddExportsInManifest -- Using a command-line option such as
`--add-exports` to make JDK-internal APIs available to existing code is
difficult, if not impossible, for applications that are delivered as
executable JAR files. To ease migration, consider allowing such a JAR
file to include the equivalent of such options in its `MANIFEST.MF`
file. [1]
Proposal
--------
Define two new JAR-file manifest attributes [2], `Add-Exports` and
`Add-Exports-Private`. Each attribute can occur at most once, in the
main section of a `MANIFEST.MF` file. The parameter of each attribute is
a space-separated list of slash-separated module-name/package-name pairs.
At run time the presence of a pair `m/p` in the value of each attribute
is interpreted as follows:
- If `m/p` is listed in the value of the `Add-Exports` attribute then
package `p` of module `m` is exported to all unnamed modules, as if
by invoking the `Module::addExports` method. This makes all of
package `p`'s public elements immediately accessible to code in
unnamed modules.
- If `m/p` is listed in the value of the `Add-Exports-Private`
attribute then package `p` of module `m` is exported to all unnamed
modules and its non-public elements are made available for deep
reflection, as if by invoking the `Module::addExportsPrivate` method
[3]. This makes all of package `p`'s public elements immediately
accessible to code in the unnamed module, and all of its non-public
elements accessible to code in unnamed modules via the
`setAccessible` method of the core reflection API.
In contrast to language-level module declarations some sloppiness is
allowed in the values of these attributes, as is traditional in JAR-file
manifests. A particular module-name/package-name pair can be listed more
than once in either of these attributes. It can also be listed in both
attributes, in which case the package will be exported privately. A
module or package specified in such a pair need not actually exist in
the run-time module graph.
These attributes are interpreted only in the main executable JAR file
of an application, i.e., in the JAR file specified to the `-jar`
command-line option of typical Java run-time launchers. They are
ignored in all other JAR files.
As an example, the Spring Boot framework [4] uses `setAccessible` to
access a protected `defineClass` method of `java.lang.ClassLoader` and
a private constructor of `java.lang.invoke.MethodHandles.Lookup`. An
application that uses Spring Boot can be made to work by adding the
line
Add-Exports-Private: java.base/java.lang java.base/java.lang.invoke
to the `MANIFEST.MF` file of its executable JAR file.
[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest
[2] http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html#JAR_Manifest
[3] See the nearby proposal for #ReflectiveAccessToNonExportedTypes
[4] http://projects.spring.io/spring-boot/