As paul has said, it would be nice to have a dependancy build built
into the JDE. 

Such a feature should not be reliant on any one compiler or any
external system (except perhaps some elisp code).

Sandip posted a very usefull list of pitfalls for dependancy
rebuilding and I've been thinking about it since. Sandip's point 6
says:

>It is not always possible to predict the name of the 
>source file based on the name of .class file in every 
>legal case.
>If one is following a model whereby the .class files 
>are in a different place than the .java file on has to 
>provide the location of .java files  in addition to 
>CLASSPATH.
>Also just based on the name of the .java files one 
>cannot predict the names and locations of all the 
>output .class files that may result from the compilation.
>It requires parsing of the .java file. That is why automated
>make file generation fails for Java. i.e. there is no equivalent
>of .c.o rule for java.

This has been the biggest problem for me trying to implement
dependancy tracking, I've tired various things and they all fall down
with this.

It struck me that there is a possible solution to this. When a class
file is compiled with the -g switch the source file name that is was
compiled from is embedded in the class (this is how the debugger knows
which class file to load).

It wouldn't be hard to adpat the debugger's strategy for finding a
source file based on the class file to a rebuilder.

This is what a rebuilder based on this would do:

- create a list 'classeslist' of all the .class files in the
destination directory
- create an assoc-list 'sourceslist' of all the .source files in the
source path
- for each .class file in 'classeslist' 
    - obtain the source file from the class file
    - get the source file name from the 'sourceslist'
    - compare the .class last modified time with the .java last
modified time
    - add the .java to a list 'recompilelist' if the .class time is
eariler
- for each source file in the 'sourceslist' that isn't in the
'classeslist'
    - add the source file to the 'recompilelist'
- compile all the files in 'recompilelist' with an @ list argument to
the compiler

I think this would work. It could be done in elisp (with a java tool
[use the bsh?] to help extract the source file name for class files).


There are two potential problems:

o Performance
the number of file accesses would be large - each .class file would
have to be opened and examined to establish the name of the
corresponding source file.
Some sort of caching system could be used to alleviate that I
suppose.

o Applicability
this only works when the .class files have been compiled with the -g
switch. Without it there will be no source file attribute in the class
and no way of relating the class to the source file.
Maybe this isn't such a big deal because developers don't tend to
compile without -g. One can always recompile everything with -g after
a release has been made, or compile releases into a seperate
directory.


Does anyone see any merit in this? It's different enough from my
current dependancy system for me to want to see an audience before I
build it.

If enough people are interested though, and think it might work, I'll
develop it and see how it goes.


Nic Ferrier

Reply via email to