Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Alan Bateman]

On 08/07/2016 13:46, Andrew Dinn wrote:

> :
> 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."
I think the focus on qualified exports has been a bit of a distraction 
in this thread. It might have been clearer if the thread has started out 
without mentioning that possibility.

> :
>
> 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.
>
I don't recall anyone suggesting a simple fix. However, the so-called 
"legacy problem" is a great topic and something that you might want to 
spin off to its own thread. I'm not ignoring the rest of the mail, just 
noting that a lot of appears to be reliable configuration.

-Alan.