(reflect) Accessing members of inner annotations types

[Peter Levart]

On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote:
> Hi Peter,
>
> On 2014-01-03, Peter Levart wrote:
>> On 01/03/2014 03:52 PM, Peter Levart wrote:
>>> This is would be all right until such proxy class
>>> (com.sun.proxy.$Proxy1 in our example) has to access some
>>> package-private types in some specific package. This happens in
>>> your Named.List annotation  implementation class. It implements a
>>> member method with the following signature:
>>>
>>> public Named[] value() {...
>>>
>>> ...where the return type is an array of a package-private type
>>> Named. Public class in com.sun.proxy package can not access
>>> package-private types in other packages!
>> Investigating this further, I found that the declaration itself is
>> not problematic. It's the code in the implemented proxy method that
>> tries to access the package-private Named class. Here's how the
>> bytecode looks like for such proxy method:
>> ... I think the error is thrown at the "checkcast" bytecode. The
>> improvement suggested still holds. If the proxy class was generated
>> in the specific package, error would not be thrown. But the
>> requirement to take into account all implemented interfaces and all
>> types encountered in the interface method signatures to calculate
>> the package of proxy class it too strict. Only implemented
>> interfaces and return types of all interface methods need to be
>> taken into consideration. Here's an example of bytecode that
>> illustrates how method parameters are passed to InvocationHandler:
>>
> Perhaps an alternative would be to check if the interface a proxy is
> proxying is nested. In that case use the outermost interface's access
> level for the package calculation.
>
> This would probably lead to a few more proxies being generated into the
> "real" package compared to your proposal. I don't know if that is ok or
> not.

Hi Joel,

The nested public interface need not be referencing the outer 
class/interface. In this case, proxy class can be generated in 
com.sun.proxy. More importantly, even if the outer interface/class was 
public, the nested interface could be referencing some other 
package-private type. For example:


public class Outer {

     @Retention(RUNTIME)
     @interface PkgPrivate {}

     @Retention(RUNTIME)
     public @interface Public {
         PkgPrivate value();
     }


     @Public(@PkgPrivate)
     public void m() {}
}


I think the criteria for package selection should be closely tied to 
requirements of the generated proxy class code. And the generated code 
references the return type of the method.

Regards, Peter

>
> cheers
> /Joel