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.gre...@redhat.com> wrote: > > On Jul 7, 2016, at 5:31 PM, Paul Benedict <pbened...@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 > >
