Incremental java compile AKA javac print compile dependencies

[Jonathan Gibbons]

On 05/27/2010 12:20 AM, Joshua Maurice wrote:
>
> 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, 

Each class identifies its direct superclass, and its superinterfaces -- 
look near the head of the class file -- and from that you can infer all 
the supertypes up to java.lang.Object.  If you're not already doing so, 
if you want to process class files, I suggest you use one of the various 
libraries available for reading and analyzing class files. That being 
said, if you want to solve the constant problem as well, I'd recommend 
you continue investigating the AST approach.


> 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.