Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Gregg Wonderly]

The practical matter is simply that all of this name visibility business is just entirely the wrong thing to be managing “modules” around.  Instead, modules should be things that are more easily managed with tools that facilitate things that container systems will want to do.   Modularity as a design paradigm has nothing to do with namespace visibility.   Packages already provide name visibility and separation.  Keywords already provide restricted access unless you pry open the door with language features aimed specifically at solving the multiuse/reuse problem that public/internal/private restrictions create.  

For a long time I’ve set back and watched this project inching along with all kinds of people asking all the questions that I thought should be asked about why the EG was doing what they were doing.  I am really afraid i still don’t know why this hiding game is so interesting and valuable.  Is there really a giant problem that a majority of the Java community has now that this is going to just solve, and make developing faster and more readily managed?  Versioning, and dynamic class replacement would be the kind of things that a module system could really provide to help software be more resilient to life cycle management over time.

We already have things like maven to help with dependency management.

We already have things like spring to help with dependency injection so that there are not hard bindings in code against specific versions.

We already have many different container systems that provide many different ways to manage software “pieces”.  The problem is that each one of them has a different paradigm and framework that one must program against.

Shouldn’t modularity really be about helping target more of those container systems implicitly instead of requiring explicit wrapper classes or other properties of the build system to make it possible to use the same module in multiple environments?

Why is this namespace hiding/exporting so important to Java developers?   Which Java developers need that level of isolation and why is it that everyone will have to deal with it, if those developers are not 90% of all developers benefiting?

Gregg Wonderly

> On Jul 8, 2016, at 4:42 PM, Paul Benedict <pbenedict at apache.org> wrote:
> 
> 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
>> 
>>