Incremental java compile AKA javac print compile dependencies

[Joshua Maurice]

On Tue, May 25, 2010 at 6:01 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> On 05/25/2010 05:11 PM, Joshua Maurice wrote:
>
>> What is relevant is that to get decent levels of incremental, aka skipping
>> unnecessary rebuilds, the build system needs to know for each java X, the
>> full list of class files and java files which will be directly used by javac
>> when compiling X. Whenever any of those direct compile dependencies have an
>> "interface" / "signature" change, X needs to be recompiled.
>>
>
> Stop right there.   There's likely a wrong assumption here, hidden in the
> word "directly".
>
> If you start from scratch, with no classes precompiled, when you compile X,
> javac will pull in from the sourcepath the transitive closure of X and all
> its dependencies.  Thus if X refers to Y, and if the implementation of Y
> refers to Z, then javac will compile X and Y and Z, even though there no
> direct reference in any way from X to Z.   This is why your proposed
> technique of tracking -verbose output will not work.
>

Also, I meant to talk about this earlier. No. Let me repeat my scheme
contained in the aforementioned links in more detail.

Let's consider java files AA.java, BB.java, CC.java in the same "javac
task", aka pom.xml. What I am currently doing is:

If any java file has not been compiled in a previous build, then mark it as
"out of date".
~Insert various other "out of date" rules.
[1] Call javac once on all "out of date" java files, without using
-sourcepath, with putting the output class dir on the -classpath.

After that, [2] call javac -verbose once per java file, passing only that
java file to javac, passing the output class dir on the -classpath.

The javac calls in [2] will compile only that java file, and thus the
verbose output will give me exactly what I want, albeit in a wall clock slow
manner. This thread is about finding a way to get this same dependency
information quicker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100526/6c524d84/attachment.html