A way to opt out of access restrictions on non-exported members.

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Wed Nov 18 10:55:23 UTC 2015


On Wed, Nov 18, 2015 at 1:53 PM, Alan Bateman <Alan.Bateman at oracle.com>

> On 18/11/2015 10:04, Ali Ebrahimi wrote:
> Hi,
> Currently only code inside java.base module can add (qualified)
> exports programmatically.
> Any module can export any of its packages to another module via the API.
> In the EE container case then there are a number of options to explore. It
> would clearly be desirable to aim for services in the medium term. Failing
> that then the EE containers will be creating dynamic configurations and so
> should be able to arrange for the equivalent of the -XaddExports
> command-line option that we have for the boot layer.
> -Alan
For adding exports as I know there is two options:

option 1: public


public Module addExports(String pn, Module target) {
    if (pn == null)
        throw new IllegalArgumentException("package is null");

    if (isNamed()) {
        Module caller = Reflection.getCallerClass().getModule();
        if (caller != this) {
            throw new IllegalStateException(caller + " != " + this);
        implAddExports(pn, target, true);

    return this;

option 2: internal for java.base

jdk.internal.module.Modules.addExports(source, pn, target)

As you can see option 1 is useless, why?

 * If the caller's module is this module then update this module to export
 * package {@code pn} to the given {@code target} module.

 I think for all use cases we would have caller's module != this module
So this don't work.

Option 2 will fail since that is internal for java.base purpose only.

Is there other options? (non-command-line options)


Best Regards,
Ali Ebrahimi

More information about the jigsaw-dev mailing list