Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Alex Buckley]

On 6/30/2016 2:29 PM, Stephen Colebourne wrote:
> To take one example from OpenGamma Strata:
> https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/named/ExtendedEnum.java#L181

(Line 50: I think "are" should be "as".)

(Line 181: I notice that while "constants" and "lookup" providers are 
specified in the class-level javadoc, "instance" providers are not. 
Admittedly, reflection is used not only for the [unspecified] special 
field of an "instance" provider class but also for the [specified] 
no-args ctor of a "lookup" provider class.)

> ExtendedEnum is a mechanism to provide enum-like behaviour, where the
> set of constants is fixed at startup, but controlled dynamically based
> on what configuration files are present. One of the options it
> provides is for the configuration file to specify a Class name, which
> is then reflected on to find suitable enum-like constants.
>
> When designing this feature, at no stage did I think that the code
> would not work because some of the constants are in a different
> module. (Application users can add their own configuration files and
> constants, ie, in a separate module).
>
> This proposal essentially requires application users to specifically
> expose these types to reflection where they might otherwise lock them
> down in a non-exported package. While in this case, I could document
> that users of extended enums must make sure their code can be accessed
> if in a different module, it would at the very least be a faff, and a
> source of questions.

Counterpoint: the user's module-info.java is a great place to document 
the special relationship between one of their packages and one of their 
dependencies.

module myapp {
   requires opengamma.strata;

   // Classes to drive Strata's ExtendedEnum instances
   exports dynamic com.foo.app.constants.tickers to opengamma.strata;
}

Alex