«

I am looking for a class/program that will scan a .java file for imports
(recursively) to discover which ones need to be rebuilt. This is
close to GNU's makedepend or cook's c_incl.

"Aryeh M. Friedman" <> writes:
>I am looking for a class/program that will scan a .java file for imports
> (recursively) to discover which ones need to be rebuilt. This is
>close to GNU's makedepend or cook's c_incl.

You might try to trace the classes loaded by the JVM.

http://www.md.pp.ru/~eu/jdk6options....oadingPreorder
http://www.md.pp.ru/~eu/jdk6options....ceClassLoading

Aryeh M. Friedman wrote:
> I am looking for a class/program that will scan a .java file for imports
> (recursively) to discover which ones need to be rebuilt. This is close
> to GNU's makedepend or cook's c_incl.

You don't use that type of tools with Java.

The javac compiler itself compiles missing parts.

And the ant tool (which you should use for build) checks what to
rebuild based on dates similar to ant.

Just use ant and javac and forget about dependencies.

If you use maven for build it will even be able to download
external packages you need for you.

Arne

Arne Vajhøj wrote:
> Aryeh M. Friedman wrote:
>> I am looking for a class/program that will scan a .java file for
>> imports (recursively) to discover which ones need to be rebuilt.
>> This is close to GNU's makedepend or cook's c_incl.
>
> You don't use that type of tools with Java.
>
> The javac compiler itself compiles missing parts.
>
> And the ant tool (which you should use for build) checks what to
> rebuild based on dates similar to ant.
>
> Just use ant and javac and forget about dependencies.

And when that's not good enough (like when superclass change, require
subclasses to recompile too), curse a bit, delete all the .class
files, and rebuild the whole thing.

Mike Schilling wrote:
> Arne Vajhøj wrote:
>> Aryeh M. Friedman wrote:
>>> I am looking for a class/program that will scan a .java file for
>>> imports (recursively) to discover which ones need to be rebuilt.
>>> This is close to GNU's makedepend or cook's c_incl.
>> You don't use that type of tools with Java.
>>
>> The javac compiler itself compiles missing parts.
>>
>> And the ant tool (which you should use for build) checks what to
>> rebuild based on dates similar to ant.
>>
>> Just use ant and javac and forget about dependencies.
>
> And when that's not good enough (like when superclass change, require
> subclasses to recompile too), curse a bit, delete all the .class
> files, and rebuild the whole thing.

Many people make a clean target in build.xml !

Arne

> The javac compiler itself compiles missing parts.
>
> And the ant tool (which you should use for build) checks what to
> rebuild based on dates similar to ant.
>
> Just use ant and javac and forget about dependencies.

Compiling based on dates isn't enough. The most anoying problem (but not
the only one) during compilation is inlining constants. The only way to
be 100% sure of proper compilation is to allways recompile all sources.
Fortunatelly recompilation based on dates works often enought to make
ant/maven quite usefull tools.

Arne Vajhøj wrote:
> Mike Schilling wrote:
>> Arne Vajhøj wrote:
>>> Aryeh M. Friedman wrote:
>>>> I am looking for a class/program that will scan a .java file for
>>>> imports (recursively) to discover which ones need to be rebuilt.
>>>> This is close to GNU's makedepend or cook's c_incl.
>>> You don't use that type of tools with Java.
>>>
>>> The javac compiler itself compiles missing parts.
>>>
>>> And the ant tool (which you should use for build) checks what to
>>> rebuild based on dates similar to ant.
>>>
>>> Just use ant and javac and forget about dependencies.
>>
>> And when that's not good enough (like when superclass change,
>> require
>> subclasses to recompile too), curse a bit, delete all the .class
>> files, and rebuild the whole thing.
>
> Many people make a clean target in build.xml !

I always do, for several reasons; the above is one of them. My
comment was a complaint about the fact that the <javac> task is
*almost* good enough to handle dependencies, but not quite. When I,
for instance, get a batch of newer source code from the SCM system, I
always do a clean build, since there's no way to be sure it isn't
necessary, and I don't want to waste time with spurious problems from
not building clean when it was required.

> I am looking for a class/program that will scan a .java file for imports
> (recursively) to discover which ones need to be rebuilt. This is close
> to GNU's makedepend or cook's c_incl.

You didn't consider import x.y.* and classes in the same package. You'll
have to parse the whole source to do this properly (the most popular
tool is javacc) - it may not be much faster that simply recompiling
those sources.

jolz wrote:
>> I am looking for a class/program that will scan a .java file for
>> imports (recursively) to discover which ones need to be rebuilt.
>> This is close to GNU's makedepend or cook's c_incl.
>
> You didn't consider import x.y.* and classes in the same package.

And the use of fully qualified named with no import.

Mike Schilling wrote:
> Arne Vajhøj wrote:
>> Mike Schilling wrote:
>>> Arne Vajhøj wrote:
>>>> Aryeh M. Friedman wrote:
>>>>> I am looking for a class/program that will scan a .java file for
>>>>> imports (recursively) to discover which ones need to be rebuilt.
>>>>> This is close to GNU's makedepend or cook's c_incl.
>>>> You don't use that type of tools with Java.
>>>>
>>>> The javac compiler itself compiles missing parts.
>>>>
>>>> And the ant tool (which you should use for build) checks what to
>>>> rebuild based on dates similar to ant.
>>>>
>>>> Just use ant and javac and forget about dependencies.
>>> And when that's not good enough (like when superclass change,
>>> require
>>> subclasses to recompile too), curse a bit, delete all the .class
>>> files, and rebuild the whole thing.
>> Many people make a clean target in build.xml !
>
> I always do, for several reasons; the above is one of them. My
> comment was a complaint about the fact that the <javac> task is
> *almost* good enough to handle dependencies, but not quite. When I,
> for instance, get a batch of newer source code from the SCM system, I
> always do a clean build, since there's no way to be sure it isn't
> necessary, and I don't want to waste time with spurious problems from
> not building clean when it was required.

And usually Java builds are reasonable fast even when building from
scratch.

Arne