scolebourne at joda.org
Mon Sep 12 22:11:46 UTC 2016
This seems reasonable.
On 12 September 2016 at 16:09, Mark Reinhold <mark.reinhold at oracle.com> wrote:
> 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. 
> Define two new JAR-file manifest attributes , `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
> . 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  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
> Add-Exports-Private: java.base/java.lang java.base/java.lang.invoke
> to the `MANIFEST.MF` file of its executable JAR file.
>  http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest
>  http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html#JAR_Manifest
>  See the nearby proposal for #ReflectiveAccessToNonExportedTypes
>  http://projects.spring.io/spring-boot/
More information about the jigsaw-dev