Visibility of methods in javac.comp.Resolve
jonathan.gibbons at oracle.com
Mon Feb 11 16:10:15 PST 2013
On 02/11/2013 04:04 PM, Werner Dietl wrote:
> Jon, all,
> in the Checker Framework we allow String-valued annotations that refer
> to variable and method names - e.g. for method post-conditions.
> We currently use reflection to access methods in javac.comp.Resolve
> that allow us to go from such a String to the correct Symbol.
> For the current code, see:
> Would it be acceptable to change the visibility of a few "findXXX"
> methods in javac.comp.Resolve from package-default to public?
> In particular, we currently use:
> - com.sun.tools.javac.comp.Resolve.findIdent(Env<AttrContext>, Name, int)
> - com.sun.tools.javac.comp.Resolve.findType(Env<AttrContext>, Name)
> - com.sun.tools.javac.comp.Resolve.findMethod(Env<AttrContext>, Type,
> Name, List<Type>, List<Type>, boolean, boolean, boolean)
> In the future, we might also want:
> Env<AttrContext>, Type, List<Type>, List<Type>, boolean, boolean)
> The class already provides a few public methods; having these
> additional methods made public would make it much more useful for us.
> What do you think? Do you see a cleaner solution for us?
> cu, WMD.
In general, you should not be relying on any API in a class that
contains the comment:
* <p><b>This is NOT part of any supported API.
* If you write code that depends on this, you do so at your own risk.
* This code and its internal interfaces are subject to change or
* deletion without notice.</b>
It would be more appropriate to provide suitable methods in the
com.sun.source or javax.lang.model API.
More information about the type-annotations-dev