Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Alan Bateman]

On 07/07/2016 23:31, Paul Benedict 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.
>
I'm curious why you think you need to do this. If I'm developing a 
library as a module then I'll export the API packages. If I'm using DI, 
or JPA, or making use of other frameworks, and where I'm putting 
annotations or have configuration that includes types in non-API 
packages, then it does mean I need to think about. I would at least 
expect the framework documentation, tutorials, examples, etc. to at 
least show me what I need to do when I'm using these frameworks in a 
module. Better still would be tools, maybe Maven plugins, to catch the 
cases like @Inject on a constructor/method in a non-exported package or 
an entity class in XML configuration where that class is in a 
non-exported package. Tooling that catches the opposite (needless 
exports) would be useful too. If there is cooperation from the 
frameworks, and if useful tooling emerges, then I don't think the 
proposal on the table is too bad.

-Alan