Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Andrew Dinn]

On 08/07/16 10:16, Alan Bateman wrote:
>
> On 08/07/2016 09:39, Sander Mak wrote:
>> That is, define your module-info's, possibly containing dynamic
>> exports if your framework of choice does its magic through reflection.
>>
> Right and there is nothing in this proposal that is specific to core
> reflection either. The framework that I am using might be spinning
> bytecode or maybe it switches to using method handles when there is a
> waning gibbous moon - that's implementation detail that the user of the
> framework should be oblivious too.

Jason addressed some of this in his post -- the nub (but definitely not
the total) of his points is in this paragraph

"This brings us to the problem with the proposal. The expectation AFAICT
appears to be that the user defining the enhanced code knows the
identity of the module enhancing it (e.g. exports dynamic
com.foo.app.model to jpa). The module is simply not in a position to
know that just “jpa” requires access. There might be more than one
version of jpa which needs to be selected dynamically, or jpa might be
broken into multiple modules itself. It’s effectively bleeding
container/framework implementation details into the user defined code."

There are more complexities at stake here than you seem to recognise.
Jason goes on to point some of them out but I'll draw out one specific
aspect of it.

The major problem is the scale and difficulty of the legacy problem that
you are suggesting such a 'simple' fix for. There are already many, many
deployments which are not built the way you suggest they ought to be
rebuilt. It is very easy to say 'well sort them out' but that fails to
recognise the amount of work involved.

It is not a question of each app developer taking one or two jars and
rebuilding them with a module-info package. First of all there is the
complexity on the app server itself. An app server itself is built from
many components and employs many libraries a lot of them obtained from
3rd parties. In many cases those components allow for many alternative
combinations. The same issue then arises for the deployed applications.
They also frequently need to use many components in many different
combinations. That means it will require a lot of work to identify the
relevant dependencies and configure the necessary linkage without
exposing the wrong components to the wrong clients. But that's not the
worst of it.

The reason JBoss's app server developed its own module system many years
ago was precisely in order to manage the complexity of the combinatorics
involved in establishing this linkage. It's major purpose was to ensure
that most of the necessary linkage was established by the app server at
runtime using whatever services were found to have been configured. On
the deployment side Java EE annotations and legacy deployment
descriptors largely establish what linkage is required both from
application deployments into EE services and from EE services back into
application code (i.e. where IoC is required). The vast majority of this
linkage is established correctly and safely, with constrained access, by
the app server. Users know little or nothing of the details of how it is
established beyond having to employ those standard annotations or legacy
descriptors.

What you are asking for is for users to identify and reconstruct all
this information in advance of deployment in all possible combinations
that might occur at runtime. In many cases they won't even know how to
do this because the whole point of an app server is to reduce the amount
of work they need to do to link in services to simply adding annotations
or dropping an xml file into a deployment. That simplification is there
to allow EE developer to concentrate on business logic.

What you are asking fundamentally undermines one of the major benefits
of using EE servers. You have argued that users ought to take
responsibility for understanding the way their applications are linked
and be grateful that Jigsaw will now verify their choices. That's
completely contradicted by the historical success of app servers which
have done the precise opposite, i.e. taken this responsibility away from
programmers and managed the task on their behalf. Now a module system
which allows that to be done cleanly without exposing every capability
to all and sundry is a great idea and Jigsaw could be that. But your
assumption that end users will want and benefit from taking control of
this task is completely out of touch.

It is very telling that that, unlike Jigsaw, JBoss's module
implementation adopted a flexible model for linkage (export and import)
that prioritised establishment of dynamic linkage. Most importantly this
linkage can be configured external to the deployed artifacts and,
therefore, can be reconfigured without having to rebuild chains of
dependent artifacts. When there are so many links and so many of the
linked items are developed by different projects this is a critical
feature. This is one point where the current Jigsaw implementation is at
its weakest and will be the cause of many problems to come beyond this
immediate one of reflective access.

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