On Apr 23, 2014, at 8:01 AM, Peter <j...@zeus.net.au> wrote: > ----- Original message ----- >> >> On Apr 22, 2014, at 7:47 PM, Peter Firmstone >> <peter.firmst...@zeus.net.au> wrote: >> >>> >>> >>> From: Peter Firmstone <peter.firmst...@zeus.net.au> >>> Subject: Decision process for a Modular build tool >>> Date: April 22, 2014 at 7:40:29 PM EDT >>> To: d...@apache.river.org >>> Reply-To: Peter Firmstone <peter.firmst...@zeus.net.au> >>> >>> >>> I started qa-refactor with the intent of fixing latent bugs, an >>> unintentional benefit is significantly reduced processing times, >>> contention and increased scalability. >>> >>> Changes in timing exposed more bugs. >>> >>> Up until recently an occassional build failure would be experienced >>> due to classdep only partially writing a dep file, resulting in >>> ClassNotFoundException during testing. Knowing that >>> RFC3986URLClassLoader is much faster resolving classes than >>> URLClassLoader, I thought, I'd try using it in ClassDep. >>> >>> Guess what the result was? That's right lot's more >>> ClassNotFoundException's >>> >>> >> >> That seems kind of odd. Since ClassDep is single-threaded (it’s >> basically a command line utility after all), how would faster class path >> resolution have any impact on the output file? > > Ok, fair call, ClassDep has a bug, I'm not sure of the exact cause.
I would suggest just adding a call to System.out.flush() at the end of main() and even System.out.close() just because you may be using a broken library that is not successfully flushing and closing. Look at the size of the files that are output. Are they multiples of some power of 2 that would be like a block write size? That would indicate that blocks are being written as a blocks worth of output is created. Gregg Wonderly
