Lew wrote:
> Mike Schilling wrote:
>> Lew wrote:
>>> Mike Schilling wrote:
>>>> jolz wrote:
>>>>>> I am looking for a class/program that will scan a .java file for
>>>>>> im****ts (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 im****t x.y.* and cl***** in the same package.
>>>> And the use of fully qualified named with no im****t.
>>> Given that 'im****t' is just syntactic sugar for FQNs, any dependency
>>> analysis tool would only use FQNs for its analysis, I should think.
>>
>> Certainly. But the OP was suggesting a tool that scanned the .java
>> file lexically for im****ts, and that would fail to find
>>
>> p1.p2.p3.class1 c = null;
>>
>> Personally, I'd build a dependency tool that scanned the .class file,
>> not the .java file. (If there is no .class file, you don't need to
>> know anything about dependencies to realize that the .java file needs
>> to be recompiled.) The bytecode has everything you need, and there is
>> lots of open-source code out there to help you parse it.
>
> Doesn't every existing tool that does dependency scanning work off the
> .class files?
>
> It escaped me that the question restricted the scan to source files. I
> simply figured any dependency tool would simply have to work off the
> .class files, never even dreaming that anyone would try to do it from
> the source.
>
Isn't this a catch-22 though in that if you are in a mixed lang
enviroment and either need the java compiled first (in the case of it
being the backend) or the other lang being done first (JNI) and it is
being compiled by someone who has not developed it then it then follows
there are no .class files. Why did sun get rid of -depend on javac
anyways? I also found JavaDepend
(http://ptolemy.eecs.berkeley.edu/~cxh/java/javadepend/)
but it doesn't
work on anything newer then 1.1 and I am doing 1.5 projects.
Also in an other post in the thread someone mentioned if a compile
doesn't work with say javac `find . -name '*.java'` or javac *.java then
it is time to break it apart into standalone jar's. This too raises a
depend issue in that if oyu have several packages which ones need to be
recompiled when X changes.
In short I am *NOT IMPRESSED* with Java's ability to manage large
projects, In a way this is the same issue recursive make has
http://aegis.sourceforge.net/auug97.pdf
|
