Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Jason Greene]

> On Jul 21, 2016, at 12:01 PM, Jason Greene <jason.greene at redhat.com> wrote:
> 
> 
>> On Jul 18, 2016, at 4:30 PM, mark.reinhold at oracle.com wrote:
>> 
> 
> Hi Mark, Thanks for the reply. I have snipped out portions to make it easier to follow the thread.
> 
>>> 
>>> I agree they are certainly intermixed elements of a system, but I’d also
>>> argue IoC is pervasive in SE applications as well (e.g. inclusion of 330
>>> and 250 in SE are examples of a desire for SE usage). I can’t refute that
>>> it has greater usage in EE, since its part of the spec, and thus
>>> effectively every EE application.
>> 
>> FYI, JSR 330 (DI annotations) is not in Java SE, though it's certainly
>> used in Java SE applications in combination with various DI frameworks.
>> 
>> JSR 250 ("common" annotations) specifies 14 annotations, but just five
>> of them are in Java SE.  They're really only there to support JAX-WS, a
>> component shared with Java EE.  So far as I know they're not used much
>> in SE applications except in conjunction with JAX-WS.
> 
> Ah yes, of course thanks for the correction. Not sure why I had it in my head that 330 was included.
> 
> -snip-
> 
> 
>>> 
>>> Sorry for the confusion, what I was trying to say on this point was a bit
>>> different. What I was trying to say was:
>>> 
>>> (2') It weakens encapsulation by forcing the introduction of exports
>>>   introducing potential conflicts that break applications.
>>> 
>>> As an example, assume I have three modules with classloader-per-module
>>> isolation (A, B, and Victim)
>>> 
>>> - A exports foo, and has a non-exported package “bar"
>>> 
>>> - B exports bar
>>> 
>>> - Victim has a module-info with requires A; requires B
>>> 
>>> Now A decides to use IoC on some of its classes in bar, so it’s
>>> definition is changed to:
>>> 
>>> { exports foo; exports dynamic bar; }
>>> 
>>> Since exports dynamic is internally a normal export at runtime, module
>>> resolution fails when loading Victim, because its now including a
>>> duplicate package, even though A had no intention of publishing its
>>> internal bar package for linkage.
>> 
>> Got it.  Thanks for clarifying this -- I agree that it's a problem.
>> 
>> Fortunately I think we can address it simply by revising the semantics of
>> `exports dynamic p` to omit the package-conflict constraint.  This would
>> allow split packages to occur more readily at run time, though still
>> really only in fairly obscure situations involving poorly-written class
>> loaders.

-snip -

> Example 2 (Unintentional discovery):
> 
> Victim uses ClassLoader.getResources (plural), looking for a standard configuration file or class name, and receives entries for both A and B. A’s was not intended to be discovered by victim, and leads to a failure state. As an example perhaps the configuration file in B specifies a class name in B’s dependency, which is not visible to Victim. Or, perhaps A’s config leads to duplicate runtime actions being configured (since the file was really only indented for A, which also processes it)

Sorry for the confusion, this should read:

" As an example perhaps the configuration file in [A] specifies a class name in [A]’s dependency, which is not visible to Victim. Or, perhaps A’s config leads to duplicate runtime actions being configured (since the file was really only indented for A, which also processes it)”

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat