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

[Ali Ebrahimi]

Hi,

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

>
> 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

Module.addExports

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

    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?
because

/**
 * 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