Visibility of methods in javac.comp.Resolve

[Jonathan Gibbons]

On 02/11/2013 04:46 PM, Werner Dietl wrote:
>>> 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.
>

Because of the Env parameter, this cannot be a provided in
javax.lang.model, so the appropriate package would presumably
be com.sun.source.util.   That provides Scope, which is the Tree API
version of Env<AttrContext> but we don't really have a precedent
for the methods you're asking for.

Given we are past feature freeze (M6) it is hard to see that it is
reasonable to start adding a new family of methods.

If you are already using the methods in Resolve, where are you
getting the Env<AttrContext> from?   Do I want to know?

OK, I read your Resolver.java class. It seems to me your request is
just the top of the tip of the iceberg, since you are using *lots*
of javac internal types and methods. Put another way, what I think
you may be asking for is (implicitly) putting something like the entire
Resolver class into com.sun.source.util. I think the idea has merit
but is Too Late for 8.  One question would be, should any new methods
go on a new Resolver class, or just on Scope?

-- Jon