Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Paul Benedict]

Alan, but that is extra configuration in the module, as I have pointed out.
The whole idea I have to opt someone into fuller reflection is taking
control too far. I'm also advocating this is not the responsibility of the
module to control reflection. What I have proposed using the Security
Manager allows people to restrict the runtime if they do so desire and
allow reflection to continue unhindered as-is otherwise. Trying out
"dynamic" doesn't address the design except confirming it works according
to your intent. I'm complaining (respectfully) about the intent and the
restriction as the default behavior.

On Jul 9, 2016 4:22 PM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:

> On 09/07/2016 21:28, Paul Benedict wrote:
>
> The argument I'm making is not just someone really wants to do this, but
>> that many people won't settle without it. Reflection has always been the
>> tool to dynamically achieve what the Java language can't always express
>> statically. IoC is built on the notion that language boundaries can and
>> should be broken to achieve magic-like behavior like injecting. Look all
>> over the EE spec and see how injection doesn't care what visibility
>> modifier you use... private methods and private fields are just as readable
>> and writable like public counterparts. Nothing wrong here, nothing broken
>> either.
>>
>> 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).
>
> -Alan.
>