I understand the motivation for this change from the point of view of
normal application operation. It looks to me to be in many ways an
improvement on the previous proposal (dynamic exports). However, I don't
really know whether it is adequate to the needs of middleware. So, I
will leave it up to my colleagues at Red Hat to comment on that.
I am replying merely because I am concerned to ensure that this proposal
does not invalidate the solution proposed for
#ReflectiveAccessByInstrumentationAgents.
The latter solution provided agents with a new method on class
Instrumentation
void redefineModule(Module module,
Set<Module> extraReads,
Map<String, Set<Module>> extraExports,
Set<Class<?>> extraUses,
Map<Class<?>, Set<Class<?>>> extraProvides)
allowing the exports relationship to be extended. So, with that method
in place let us assume module M contains package P, the agent trusts
module M' and M does not currently export P to M' then an agent can use
it method to add an export
M exports P to M'
The immediate question is
1) Will the agent be able add an export relationship
M exports private P to M'
The bonus question is essentially the same as the first but in a
slightly different circumstance. Let us instead assume that module M
contains package P, the agent trusts module M' and M currently exports P
to M' but does not export private P to M' (n.b. this will really only be
of relevance where M exports P to all modules but does not export
private P to all modules)
2) Will the agent be able to upgrade the export relationship from
M exports P to M'
to
M exports private P to M'
If the API method is indeed to be updated so as to enable a yes answer
to these two questions then the existing solution will still stand. If
not then the original problem still needs resolving.
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
