> On Jul 21, 2016, at 12:01 PM, Jason Greene <jason.gre...@redhat.com> wrote:
>
>
>> On Jul 18, 2016, at 4:30 PM, mark.reinh...@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
