Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Paul Benedict]

For those who are still supporters of preventing non-exported types from
being reflected, I think a compromise can still be found, but it's not in
this proposal. Here are two other alternatives I hope the EG will consider:

1) Introduce a new permission type to allow non-exported types to be
reflected. I don't find it acceptable the module gets to dictate what can't
be reflected. I believe this should be controlled and configured externally
-- certainly not the module itself.

2) Allow layers to control if non-exported types can be reflected. Perhaps
the JDK sets its own layers to "false", but Containers and what they deploy
can be separately configured, each. For example, maybe WebLogic won't allow
itself to have its non-exported types reflected, but if each EAR gets its
own layers, I could configure WebLogic to allow me to reflect everything
within the EAR.

PS: I don't see #1 and #2 to be mutually exclusive.

Cheers,
Paul

On Fri, Jul 8, 2016 at 4:16 PM, Jason Greene <jason.greene at redhat.com>
wrote:

>
> On Jul 7, 2016, at 5:31 PM, Paul Benedict <pbenedict at apache.org> wrote:
>
> If this restriction stays (and I am really hoping it doesn't), my next
> best hope is for Containers like WildFly, Tomcat, SpringBoot etc. to enable
> me to do this. If the Layer has a hook into amending the Module Descriptor,
> then I am hoping each Container will automatically set "dynamic" to each
> non-exported package. I think this will be a highly requested and
> sought-after feature.
>
>
> That’s probably something we would do if this notion remains.
> Unfortunately it means that you would then have different behavior for
> standalone SE usage and container usage, making it harder to share code. It
> also might introduce a conflict that wasn’t there before (e.g. split
> package)
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>