A different feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Andrew Dinn]

Hi Peter,

On 12/07/16 17:51, Peter Levart wrote:
> I'll try to question the proposal for
> #ReflectiveAccessToNonExportedTypes from a different angle.

Thanks you for doing so. This is a very helpful summary of the issues at
stake here and I find your proposal interesting although I don't think I
am the one to critique it.

> The proposal extends the language of module declaration with "exports
> dynamic" variant of export. Like classical plain "exports", the dynamic
> variant comes in unqualified and qualified flavor.
> 
> 1st I'll question the qualified flavor.
> . . .
>  In my opinion, qualified "exports
> dynamic" has no weight. Plain qualified export is enough for the same
> purpose.

Yes, I agree. The ability to qualify dynamic exports doesn't add any
value when it comes to dealing with the problem for which dynamic
exports was proposed as a solution.

> 2nd I'll question the unqualified flavor of "exports dynamic".
> . . .
> It is
> a compromise. And users are forced to make a compromise too. Either they
> use qualified exports with fear that they will not list a module that
> may be used at runtime and will want to rightfully access the types or
> they use unqualified "exports dynamic" and fear that some unauthorized
> module accesses their types at runtime.

I drew this same conclusion for the same reason.

> Is there an alternative?

I sincerely hope so (and I suspect one is coming right on cue ... ;-)

> Remember J2EE and infamous deployment descriptors? Despite the hatred
> towards those XML files that had to be composed somehow at "deployment"
> time, J2EE acknowledged the fact that there is not only an app
> developer, but also a "deployer". The one that decides how application
> modules and app server interact in some details. In above cases, the
> module that "exports dynamic" some of its types is not always in a
> position to decide what modules it wants its types to export to. It is
> always in a position to decide what packages to export but not to which
> modules. Could these two pieces of information be decoupled so that the
> module would just specify the packages and the "deployer" would specify
> target modules?

I think this is a useful way to look at the problem. At root it rests on
the need to establish load-time linkage from a 'deployment' module which
wants to expose its internal machinery in a controlled way to some
target middleware 'deployer' modules that are the only desired targets.
One implication that follows immediately is that such exposure will
necessarily be effected using indirect linkage i.e. reflection because
the linkage can only really be established at load-time. Another is that
the module system needs to provide mechanism to allow a 'deployer' to
/construct/ the desired module access to a 'deployment' (and hence
enable reflective access) at load-time, rather than having it
/pre-configured/ in the deployed artefact.

There is a wrinkle to this that probably makes it slightly harder to
resolve. Containers generally need to be able to deploy, undeploy and
redeploy deployments and with rapid turn-around to boot -- sorry, pun
intended, but the thing is that they do so without rebooting the server
or, even, services unrelated to the one being bounced. That's a critical
business requirement for many users of middleware.

This is normally achieved by loading each deployment in its own
classloader (well, ok, loading a suite of deployments in a suite of
related classloaders -- hence why JBoss Modules was developed some years
ago). That provided the ability to discard an old instantiation of the
deployed artefact and reload it as some new instantiation.

In some cases a deployment will be unloaded in order for it to be
reloaded in a modified form, possibly only to rejig configuration or
possibly to provide a new version of the code. In other cases it will
merely be unloaded and reloaded as was, not because it needs to be
changed in any way rather because a deployment on which it depends
(either directly or recursively) will have required some modification.

So, what this implies is that any mechanism used to construct the
desired module linkage from deployment to deployer needs to allow that
module structure to be removed and then reconstructed.

> A rough idea:
> 
> Let's extend the qualified export with the ability to specify as targets
> not only module names, but also "labels" or "module groups" - those
> could be names distinguished from module names by using a special
> syntax. For example: this.is.a.module.name vs. @this.is.a.label.name.
> Now we have created a job for the "deployer". What he/she does is
> specifies the mapping from label names to module names (many to many).
> That's all.

I am afraid my JBoss knowledge is not adequate to judge how well this
might work as regards JBoss middleware nor indeed to comment on the
details you mention in the follow-up to this paragraph (sorry, but my
day job is the JVM + JIT). I merely wanted to concur that dynamic module
configuration needs to be part or the solution and point out that it
needs to be flexible enough to cope with reloading. Perhaps Jason Greene
(in cc) might be able to comment on your specific proposal.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander