Incremental Java Compile
in [Java Programming]
|
From: Arne Vajhøj on 6 May 2010 20:00 On 06-05-2010 08:58, Tom Anderson wrote: > On Wed, 5 May 2010, Lew wrote: >> Joshua Maurice wrote: >>> No, no, and no. Perhaps you'll listen this time. >> >> And perhaps you won't be so damn rude next time. What the hell? >> >> You have consistently rejected every piece of good advice, given >> complete nonsense excuses for doing so, and thrown mud in the face of >> people who try to help you. What a piece of work! > > He hasn't been given good advice. He's been given advice completely > unrelated to the problem he's explained at great length, and which is > not nonsense. The only mystifying thing is that he's still here, rather > than having long since buggered off in search of people who might engage > with his problem. The advice is not unrelated to his problem (except for Roedys, but that is not special for his questions). He has been giving the correct advice. They need to fix their way of building software. If they do that then their build time problems will disappear. And a lot of other problems. He has gotten explanation of some of the technical difficulties that the tool he asks for will face. He has not gotten such a tool. Because nobody wants to spend lots of time (thousands of hours) developing a tool that is only needed in completely fucked up environments. Arne
From: Arne Vajhøj on 6 May 2010 20:06 On 06-05-2010 02:22, Joshua Maurice wrote: > We recently were handed out this book describing Scrum, a variant of > agile development. I agree with what the author bolds and italicizes, > that interfaces need to be \stable\ (just the word \stable\). > > I would love what you describe. However, my fellow employees and > managers understand little and respect little of what decoupled, > relatively well thought out, well defined interfaces can do for them. > It's always about the new feature. No code cleanup ever really get > done. My only real option to attack that front is to vote with my > feet. (As an example, I remember this one time that an architect at > the company in question said it was perfectly fine to use a finalizer > to manage C standard library heap memory allocated via JNI. I > protested quite vigorously.) You should fix that problem instead of searching for the magic tool that can compensate for those problems. > Also, as a potentially incorrect observation, do you think most java > developers use notepad or some other text editor to do their work? I > would suspect that most people use Eclipse nowadays. Eclipse is almost > exactly what I want from a build system, except it's limited to Java. > It's a nearly fully incrementally correct build system, and is a lot > better than I could ever do on my own as a side project. Would you all > be saying the same straw man arguments if you lost your incremental > IDE and had to use notepad / wordpad / emacs without all your cool > java-specific stuff to do your work? I think not. If you think it is useful, then the Eclipse compiler is open source and you can grab it and hack it to do what you want. Arne
From: Mike Schilling on 7 May 2010 20:27 Arne Vajh�j wrote: > On 06-05-2010 08:58, Tom Anderson wrote: >> On Wed, 5 May 2010, Lew wrote: >>> Joshua Maurice wrote: >>>> No, no, and no. Perhaps you'll listen this time. >>> >>> And perhaps you won't be so damn rude next time. What the hell? >>> >>> You have consistently rejected every piece of good advice, given >>> complete nonsense excuses for doing so, and thrown mud in the face >>> of people who try to help you. What a piece of work! >> >> He hasn't been given good advice. He's been given advice completely >> unrelated to the problem he's explained at great length, and which is >> not nonsense. The only mystifying thing is that he's still here, >> rather than having long since buggered off in search of people who >> might engage with his problem. > > The advice is not unrelated to his problem (except for Roedys, > but that is not special for his questions). > > He has been giving the correct advice. > > They need to fix their way of building software. > > If they do that then their build time problems will > disappear. And a lot of other problems. > > He has gotten explanation of some of the technical > difficulties that the tool he asks for will face. > > He has not gotten such a tool. Because nobody wants > to spend lots of time (thousands of hours) developing > a tool that is only needed in completely fucked up > environments. I'm qoing to quibble. First, it wouldn't take thousands of hours; hundreds at most. (My latest idea is to modify javac to create dependency files. That way you wouldn't need to do a seperate source analysis to find, where, e.g. constants are used.) Second, it would be useful, though not required, in all environments with a big source tree. If I pull down the latest changes from the SCM and see that some are in low-levbel utility routines, I probably don't need to recompile all the code that used them, but I don't know for sure. That's annoying. And if I start to see odd errors, not knowing whether taking the 20 or 30 minutes to build everything clean is the fix or a waste of time is annoying as well. If such a tool existed, I'd use it. But I'll agree that the reason no such tool exists is that almost all opf us we get on well enough without it.
From: Joshua Maurice on 7 May 2010 22:44 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.
From: Mike Schilling on 8 May 2010 00:08
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. |