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

[Peter Levart]

Hi Mandy,

There's another redundant validation and read edge addition I think. 
When deriving referenced types from methods of interfaces, static 
methods could be skipped as they are not implemented or overridden by 
Proxy class:

http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.noStaticSignatures/webrev.01/

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.

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?

What do you think?

Regards, Peter

On 04/12/2016 02:34 PM, Peter Levart wrote:
> Hi Mandy,
>
> This is OK, but the whole loop could be simplified. No need for 
> Dequeue any more:
>
>             // set up proxy class access to proxy interfaces
>             Set<Class<?>> visited = new HashSet<>(interfaces);
>             for (Class<?> c : visited) {
>                 ensureAccess(target, c);
>             }
>
> Regards, Peter
>
> On 04/12/2016 01:45 AM, Mandy Chung wrote:
>> Peter spots the redundant read edges are added to dynamic module when 
>> creating a proxy class.   Proxy class does not access super 
>> interfaces of proxy interfaces.   I have verified this simple patch 
>> with all core tests and JCK api tests.
>>
>> diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java 
>> b/src/java.base/share/classes/java/lang/reflect/Proxy.java
>> --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java
>> +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java
>> @@ -804,11 +804,6 @@
>>                       continue;
>>                   }
>>                   ensureAccess(target, c);
>> -
>> -                // add all superinterfaces
>> -                for (Class<?> intf : c.getInterfaces()) {
>> -                    deque.add(intf);
>> -                }
>>               }
>>                 // set up proxy class access to types referenced in 
>> the method signature
>