Incremental java compile AKA javac print compile dependencies

[Joshua Maurice]

On Wed, May 26, 2010 at 11:28 PM, Joshua Maurice <joshuamaurice at gmail.com>wrote:

> On Wed, May 26, 2010 at 10:41 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>>  On 05/26/2010 09:09 PM, Joshua Maurice wrote:
>>
>>
>>   Currently the tools.jar API, aka JavacTask, gives access to the parse
>>> tree of function bodies, but it does not give access to the analyzed tree of
>>> function bodies.
>>>
>>>
>> Yes it does.   After you call parse(), call analyze(). Then walk the parse
>> trees returned from parse(), and in conjunction with the various utility
>> APIs you can find the info you need.
>>
>> Look at
>>     com.sun.source.util.Trees
>>     javax.lang.model.util.Elements
>>     javax.lang.model.util.Types
>>
>> If you get desperate, cast types down into the internal javac types, but
>> it should be possible to use just the public APIs in com.sun.source.* and
>> javax.lang.model.**
>>
>
> I shall. Thank you. Ok, so type mirrors can be used on the stuff in the
> CompilationUnitTree, or something? Excellent.
>

Thank you again, but do you know any good examples of those APIs? I am
unable to quickly find some good documentation or examples on Types, type
mirrors, and such.

PS: The above scheme I wrote out involving reading dependencies from class
files does not work. I just implemented it, and ran it against my test
cases. It fails when a class uses ClassName.constantVariableFieldName, where
the constantVariableFieldName is declared in a super. A developer can come
in and add a field with the same name in ClassName, or a super type of
ClassName but before the type declaring the old field, and this new field
with the same name will "hide" the old field. Thus I need to know that this
java file has a compile dependency on ClassName and all of its super types
(or something like that), but the class file does not contain that
information, nor do I see an easy way to "hack it" to work. My above rules
for specially handling constant variable fields did not anticipate that a
constant variable field could be hidden by a not-"constant variable" field.
I'm back to using javac -verbose output and/or figuring out this type mirror
thing to get the compile dependencies that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100527/2eb658db/attachment.html