Visibility of methods in javac.comp.Resolve

[Werner Dietl]

>> 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:
>>
>>
>> http://code.google.com/p/checker-framework/source/browse/checkers/src/checkers/util/Resolver.java
>>
>> 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:
>> com.sun.tools.javac.comp.Resolve.findConstructor(DiagnosticPosition,
>> 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?
>>
>> Thanks,
>> 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.

Is there already some existing API to which we could add this feature?
Is there any chance of this happening for Java 8?

cu, WMD.

-- 
http://www.google.com/profiles/wdietl