(reflect) Accessing members of inner annotations types

Joel Borggren-Franck joel.franck at oracle.com
Wed Jan 8 12:00:56 UTC 2014


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.

cheers
/Joel



More information about the core-libs-dev mailing list