Incremental Java Compile
in [Java Programming]
|
From: Lew on 16 May 2010 11:10 Tom Anderson wrote: > Oh please. Lew, this is absurd. Do you use Eclipse, or some other IDE Not by preference, but that has nothing whatsoever in the least at all even a jot to do with my point, which you misrepresented. > with an incremental compiler? If so, would you rather switch to an IDE > that did a full build every time you changed any file? No? Then you are > *already* agreeing through your very actions that incremental > compilation is useful. This discussion is merely about ways to do it > more simply, without having to build, as Eclipse does, a vast database > of cross-references. I use Eclipse when I have to. Its incremental compilation is not appreciably better for me than Ant's, which is plenty good enough for a well-designed project, which excludes the OP's. -- Lew
From: Mike Schilling on 16 May 2010 12:06 Tom Anderson wrote: > I'm starting to think that a better option would be to modify javac to > never inline compile-time constants outside their defining class. Better to modify javac to make constant table entries for these compile-time constants while still inlining them. These constant table entries would never be used, but they'd document the dependency.
From: Tom Anderson on 16 May 2010 12:58 On Sun, 16 May 2010, Lew wrote: > Lew wrote: >>> Defeating inbuilt optimizations of your code because you don't want to >>> correctly design or refactor your code is foolishness. > > Tom Anderson wrote: >> Oh please. Lew, this is absurd. Do you use Eclipse, or some other IDE >> with an incremental compiler? If so, would you rather switch to an IDE >> that did a full build every time you changed any file? No? Then you are >> *already* agreeing through your very actions that incremental >> compilation is useful. This discussion is merely about ways to do it >> more simply, without having to build, as Eclipse does, a vast database >> of cross-references. > > I never said incremental compilation is useless. Straw man. Okay. > I said getting rid of compile-time constants to get it is foolish. I'm saying there is *no* downside to getting rid of compile-time constants (where that's possible!). tom -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better myself. -- Francis Jeffery
From: Tom Anderson on 16 May 2010 13:06 On Sun, 16 May 2010, Mike Schilling wrote: > Tom Anderson wrote: > >> I'm starting to think that a better option would be to modify javac to >> never inline compile-time constants outside their defining class. > > Better to modify javac to make constant table entries for these > compile-time constants while still inlining them. These constant table > entries would never be used, but they'd document the dependency. That's what i had been thinking previously. That information would let you do the dependency tracking that would let you recompile the right classes. But stopping the inlining in the first place would mean that there was no need to do the recompilation at all. If constants weren't inlined, there'd be no need to consider constant values part of a class's signature, and so changes to a class which only changed constant values would not need to trigger any other recompilation. When classes did change more significantly, the set of other classes which needed recompilation would be smaller. That seems like a bigger win. Of course, the switch label problem defeats this idea. If you're inlining some constants, then you still need to track dependencies on constant values in general. tom -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better myself. -- Francis Jeffery
From: Lew on 16 May 2010 13:10
Lew wrote: >> I said getting rid of compile-time constants to get [incremental compilation] >> [rather than to correct the design] is foolish. Tom Anderson wrote: > I'm saying there is *no* downside to getting rid of compile-time > constants (where that's possible!). Okay. -- Lew |