Incremental Java Compile
in [Java Programming]
|
From: Lew on 8 May 2010 09:58 Joshua Maurice wrote: >>>>> No, no, and no. Unplonk. Whatever. If I plonked everyone who's rude here I wouldn't be allowed to post either. -- Lew
From: Joshua Maurice on 8 May 2010 16:18 On May 7, 9:08 pm, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: > Joshua Maurice wrote: > > If anyone else cares, I managed to inadvertently stumble across a > > solution. On impulse, I asked a co-worker at lunch. It seems that > > class files do not contain sufficient information with default javac > > options. However, when compiled with -g, it contains a listing of all > > types used in the compile. When combined with Ghost Dependencies, I > > think this can result in a correct incremental build at the file level > > which will not cascade endlessly downstream. I'm working on the > > finishing touches to my prototype now. > > You realize that you're now going to recompile a class when it refers to > another class to which a comment was added. Yes. I'm pretty sure that it would be better than doing a full clean build or a cascading jar-dir-unit incremental build.
From: Mike Schilling on 9 May 2010 04:31 Joshua Maurice wrote: > On May 7, 9:08 pm, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: >> Joshua Maurice wrote: >>> If anyone else cares, I managed to inadvertently stumble across a >>> solution. On impulse, I asked a co-worker at lunch. It seems that >>> class files do not contain sufficient information with default javac >>> options. However, when compiled with -g, it contains a listing of >>> all types used in the compile. When combined with Ghost >>> Dependencies, I think this can result in a correct incremental >>> build at the file level which will not cascade endlessly >>> downstream. I'm working on the finishing touches to my prototype >>> now. >> >> You realize that you're now going to recompile a class when it >> refers to another class to which a comment was added. > > Yes. I'm pretty sure that it would be better than doing a full clean > build or a cascading jar-dir-unit incremental build. No doubt, but the result isn't the minimal amount of recompilation we were discussing earlier.
From: Tom Anderson on 9 May 2010 06:23 On Sat, 8 May 2010, Joshua Maurice wrote: > On May 7, 9:08�pm, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: >> Joshua Maurice wrote: >>> If anyone else cares, I managed to inadvertently stumble across a >>> solution. On impulse, I asked a co-worker at lunch. It seems that >>> class files do not contain sufficient information with default javac >>> options. However, when compiled with -g, it contains a listing of all >>> types used in the compile. Are you sure? $ javac -version javac 1.6.0_16 $ echo "class Foo {public static final int X=23;}" >Foo.java $ echo "class Bar {public static final int Y=Foo.X;}" >Bar.java $ javac -g Foo.java Bar.java $ grep Foo Bar.class $ I can see no sign of Bar.class containing any mention of Foo. >>> When combined with Ghost Dependencies, I think this can result in a >>> correct incremental build at the file level which will not cascade >>> endlessly downstream. I'm working on the finishing touches to my >>> prototype now. >> >> You realize that you're now going to recompile a class when it refers to >> another class to which a comment was added. > > Yes. I'm pretty sure that it would be better than doing a full clean > build or a cascading jar-dir-unit incremental build. The previous time we discussed this, the idea came up of looking at changed class files to see if the changes were consequential - essentially, if the change changed the interface of the class (added a method, changed a method's signature, changed the value of a constant, etc). If you did that, you could filter the changes so that only consequential ones triggerd recompilation of dependents. That would avoid the unnecessary recompilation Mike mentions, wouldn't it? tom -- All roads lead unto death row; who knows what's after?
From: Joshua Maurice on 9 May 2010 07:27
On May 9, 3:23 am, Tom Anderson <t...(a)urchin.earth.li> wrote: > On Sat, 8 May 2010, Joshua Maurice wrote: > > On May 7, 9:08 pm, "Mike Schilling" <mscottschill...(a)hotmail.com> > > wrote: > >> Joshua Maurice wrote: > >>> If anyone else cares, I managed to inadvertently stumble across a > >>> solution. On impulse, I asked a co-worker at lunch. It seems that > >>> class files do not contain sufficient information with default javac > >>> options. However, when compiled with -g, it contains a listing of all > >>> types used in the compile. > > Are you sure? > > $ javac -version > javac 1.6.0_16 > $ echo "class Foo {public static final int X=23;}" >Foo.java > $ echo "class Bar {public static final int Y=Foo.X;}" >Bar.java > $ javac -g Foo.java Bar.java > $ grep Foo Bar.class > $ > > I can see no sign of Bar.class containing any mention of Foo. Apparently I am mistaken. I would suggest looking for "Bar" and not "Bar.class", but the result is the same. static finals might be an exception to the debug information, which is sad. I'm wondering how I'll work around this now. I am still in the process of implementing, so I haven't really been able to test, or I would have caught this eventually. Thanks for letting me catch it earlier. I could still catch this through Ghost Dependency analysis, but it becomes more tricky. I'll have to think about it. At a minimum, I could detect all class files which have static final fields, and force all classes downstream to be out of date. Not very incremental in this case, but at least it's correct. Hopefully this is the only such corner case. I need more tests. |