Incremental Java Compile
in [Java Programming]
|
From: Arne Vajhøj on 3 May 2010 20:40 On 03-05-2010 14:29, Joshua Maurice wrote: > On May 3, 4:38 am, Lew<no...(a)lewscanon.com> wrote: >> The generator can be forced to follow good practices, rather than have bad >> practices use "the generator" as an excuse. > > So, I ask again: what if the generator changes, which it does > "somewhat" frequently? I'd like to do a build in that case. But it should not. The team that maintains that generator should make multiple changes, test them carefully and then release them to the other teams. >> But one can *design* interfaces to be modular. Try it. > > Again, I do not hold sufficient sway, and we're dealing with a product > with a code level published API which wasn't well designed, so we've > coded ourselves into a corner, so to speak. Stuck with certain API's is a very common thing. But that does not necessarily mean that thousands of classes change all the time or that the generator tool change all the time. Arne
From: markspace on 3 May 2010 21:49 Joshua Maurice wrote: > I think they missed the important > part of the memo: that it only works when the code is decoupled, > modular, and relatively stable and well defined interfaces instead of > the ~25,000 source file mess we have now. I've heard that misery loves company, so here you go: <http://en.wikipedia.org/wiki/Big_ball_of_mud> "Programmers in control of a big ball of mud project are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it. Technology shifts � such as client-server to web-based or file-based to database-based � may provide good reasons to start over from scratch."
From: Joshua Cranmer on 3 May 2010 21:51 On 05/03/2010 08:18 PM, Joshua Maurice wrote: > I am fixing it. I am not whining. I was asking for help on how to do > it. I have asked for real solutions to the real problems I am facing > writing it, such as how to get a list of class files per compiled java > file as if I called javac once per java file in the dir. final static int constants (or other constant types that ldc works on) are directly hardcoded into the class file. It is therefore impossible to read a classfile and tell you which Java classes would have to change for it to need to be recompiled. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Arne Vajhøj on 3 May 2010 21:57 On 03-05-2010 02:54, Mike Schilling wrote: > Arne Vajh�j wrote: >> On 02-05-2010 17:11, Joshua Maurice wrote: >>> On May 1, 10:43 am, Lew<no...(a)lewscanon.com> wrote: >>>> Mike Schilling wrote: >>>>> "The most obvious example of these limitations is that the task >>>>> can't tell which classes to recompile when a constant primitive >>>>> data type exported by other classes is changed. For example, a >>>>> change in the definition of something like >>>>> public final class Constants { >>>>> public final static boolean DEBUG=false; >>>>> } >>>> >>>>> will not be picked up by other classes. " >>>> >>>>> That is, it's an incremental (no pun intended) improvement on the >>>>> usual Ant algorithm of "recompile what onviouslt needs >>>>> recompilation; if that doesn't seem to work, do a clean build" >>>> >>>> You can't blame Ant for that one. The class that depends on the >>>> compile-time constant, such as 'DEBUG' in your example, compiles >>>> the constant into its class, not the symbol. Without some external >>>> indication of the dependency, there's not any way for a compiler or >>>> build tool to detect that it exists. With respect to dependencies where >>>> the symbol is stored in the >>>> class rather than its value, even 'javac' handles the situation >>>> pretty well. >>> >>> I'm not blaming anyone in particular. I just want to know how to get >>> a fully correct, aka 100% incremental build under the actions: >>> adding, removing, modifying java files, and adding, removing, or >>> modifying build steps of "take these jars, compile them to class >>> files, then jar them", aka the standard developer actions. >> >> To me the entire idea is rather pointless. >> >> The tool can not be made to work with binaries. > > I think it could. As I recall it then the conclusion was that correct handling of constants (static final) required source- Arne
From: Arne Vajhøj on 3 May 2010 21:59
On 03-05-2010 12:28, Roedy Green wrote: > On Sat, 1 May 2010 04:34:31 -0700 (PDT), Joshua Maurice > <joshuamaurice(a)gmail.com> wrote, quoted or indirectly quoted someone > who said : >> system: A developer should be able to do any combination of the >> following actions and trigger a small / minimal / incremental build, > > IF you use ANT, you don't need to bother with this. The time in a > traditional compile is mostly loading Javac.exe. With ANT it gets > compiled only once. Further JAVAC looks at dates of *.java and > *.class files and avoids most unnecessary recompilation. Well - the safe way is to clean before building. Arne |