Review request 8153895 (proxy) redundant read edges to superinterfaces of proxy interfaces

[Peter Levart]

Hi Mandy,

On 04/13/2016 01:55 AM, Mandy Chung wrote:
>> On Apr 12, 2016, at 6:16 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> ...
>>
>> And there's also a question whether referenced types derived from method signatures should be checked for visibility from the specified class loader (in method validateProxyInterfaces). On one hand it is nice to ensure that later usage of the proxy class will not encounter problems of visibility of types in method signatures, but on the other, Java has been known to practice late binding and a normal class implementing an interface is loaded without problems although its method signatures reference types that are not visible from the class' class loader. Only when such method is called does the resolving happen and exception is thrown. So the question is whether such visibility checks are actually beneficial. For example, one could successfully use a proxy class by only invoking methods that reference visible types if this check was not performed.
>>
> I noticed this missing visibility check when updating proxies to work with modules.  I don’t know the history why it only checks of proxy interfaces when the API was defined.  In typical cases, when a proxy interface is visible to the specified class loader, the referenced types are likely visible. On the other hand, I’m cautious of the compatibility risk if the visibility check applies to referenced types as well. I don’t think this check has vast benefits while past proxy changes broke existing libraries that show up the incompatibility risk is somewhat hard to assess.
>
>> The problem is of course with the setup procedure of the dynamic module where you have to add exports from modules/packages of those referenced types and read edges to modules of those references types upfront. But this problem is resolvable. If a type is not visible from the proxy class' class loader, then we don't need an export from its module/package and we don't need a read edge to its module, do we?
> True. If the type is not visible, NCFE will be thrown and this read edge and qualified exports would be redundant. Are you worrying the unused qualified exports causing security concerns?  The proxy classes in a dynamic module are encapsulate and I’m not too concerned of the redundant ones.
>

No, not about security. Mainly about binary compatibility. For example:

- library A v1 defines an interface I with some methods
- library B creates a dynamic proxy implementing I. It depends on 
library A and libraries defining types from method signatures of the 
interface
- program P uses B and depends on the transitive closure

now comes new version of library A v2 which adds a default method to 
interface I with signature that requires additional dependency which is 
tagged as "optional". Program P does not need to call this new method on 
the proxy created by B. Should we force P to bundle the new dependency 
although it is not used?

Regards, Peter