On 09/07/16 22:22, Alan Bateman wrote:
> Hence the `exports dynamic` proposal. There is a lot of confusion in
> this thread and it might be useful if someone could try out a scenario
> with an injectable constructor or method on a type in an otherwise
> non-exported package. That might help get the discussion back on track
> and get on to discussions or proposals on usability (for example).
I don't think there is any confusion here other that that you have
failed to note an important part of what is being asked for and, in
consequence, recognise why that request was made. Jason, Paul and I all
said we would like to see some sort of privileged version of what you
are proposing. 'exports dynamic' is not a privileged relaxation. It is a
wholesale removal of Jigsaw's runtime control from whatever modules
containers might need to operate on (whether in the JDK runtime or in
application deployments).
That option may well be the status quo as of JDK8 but with JDK9 it is
the status quo in a changed world. Firstly, this so-called status quo
significantly undermines the point and utility of Jigsaw since
effectively it negates it's presence at runtime for large parts of the
code base. So, you get compile-time checking but you don't get any
runtime enforcement.
Secondly, in consequence, it constitutes a significant risk because it
makes it very easy for developers to believe they have secured private
information and functionality while requiring the middleware layer many
of them depend on to prejudice that security across the board. A
mechanism enabling restricted relaxation of the constraints on
reflective access would allow trusted tools and libraries to continue to
do what they have always been able to do while still providing the
secure encapsulation that is the main point of having Jigsaw.
You are right in suggesting that the ability to manage layers means that
middleware can actually configure more controlled access to non-public
reflection than is offered by using 'exports dynamic'. I am currently
looking into exactly that same option for my agent code and it may well
be adequate to achieving the desired 'controlled access'. However, like
Paul (to whom your comments above were posted) I'm also not convinced
that this is something that should be pushed onto developers of
middleware or agents.
Implementing module linling via the Layer API is definitely going to be
cumbersome. It is also going to be difficult to do efficiently in a
dynamic environment where deployments are commonly removed and
redeployed while the container continues running, potentially with
different requirements for linkage to container services. Redeployment
will not just require relinking the component immediately redeployed but
also dependent components which need stopping and restarting. If module
rewriting is going to be the only way to do this then it is going to
have to be extremely efficient. Implementing this once, efficiently in
the module system sounds to me like a much better approach.
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
