Visibility of methods in javac.comp.Resolve

Werner Dietl wdietl at
Mon Feb 11 17:19:54 PST 2013

Thanks for these explanations, Jon!

The Checker Framework is definitely using a lot of "private" APIs, but
usually these methods are public and callable without reflection.
Resolve is the only class I remember off the top of my head where we
have to use reflection to get reasonable behavior.
So I'm not really asking for a new feature, just for making the
existing feature easily accessible.

(Of course I agree that it would be nicer if we could write the
Checker Framework without any dependency on javac internals and
thereby also support Eclipse. I do hope that will be possible with
Java 9. :-) )

cu, WMD.

On Mon, Feb 11, 2013 at 5:09 PM, Jonathan Gibbons
<jonathan.gibbons at> wrote:
> 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:
>>>> 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:
>>>> -<AttrContext>, Name,
>>>> int)
>>>> -<AttrContext>, Name)
>>>> -<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?
>>>> 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 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


More information about the type-annotations-dev mailing list