Looks perfect. Thanks! If it's not too much trouble, please "svn copy"
the ColorProfileUtil from FOP Trunk so we retain the history and
document where this came from.

I don't think it makes sense to put a lot of time in trying to test for
a race condition. That's going to be difficult to reproduce. And to
prove that it's no longer there. For me, the important thing is that
this problem is documented in ColorProfileUtil like you did.

For the JAR: just do a clean compile (with Java 1.5, i.e. lowest
possible) and replace the ...1.5svn.jar in FOP's lib directory.

On 01.02.2011 19:40:38 Andreas Delmelle wrote:
> On 01 Feb 2011, at 13:24, Jeremias Maerki wrote:
> > Hmm, I don't see how any cruft can accumulate in there. Main and test
> > classes are properly separated. jar-main only packs build/classes.
> > Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?),
> > we need to update the JAR anyway.
> Sure, I can take care of the migration of ColorProfileUtil in the same go. Do 
> we move it to java2d.color.profile (similar to ColorUtil, which is placed 
> under java2d.color)?
> See attached patch XGC_ColorProfileUtil for the proposal. Just added a method 
> to deal with the getInstance(byte[]) variant used in XGC, and for the sake of 
> completeness, provided one for the String variant as well.
> Additionally, looked up the places where one of the getInstance() methods was 
> being used and replaced them by a corresponding call to 
> ColorProfileUtil.getICC_Profile(). 
> As it turns out, there were only two occurrences: ImageLoaderRawJPEG and 
> ImageLoaderImageIO.
> Are there any special steps to be taken to replace the JAR in FOP, or do I 
> just commit the new '...1.5svn' JAR?
> On FOP's end, after the JAR has been replaced, the changes then become as in 
> attached patch FOP_ColorProfileUtil. For now, I deprecated the class and 
> redirected the existing methods. The calls to getICC_Profile() are done 
> directly against XGC, so no need to add those to FOP's ColorProfileUtil 
> anymore. I also cleaned up the remaining references to other methods (= 
> basically just replaced import statements in the affected classes), so 
> fop.util.ColorProfileUtil is actually unused. To be removed at a later date?
> The harder part would be to come up with some test cases, in order to verify 
> that this actually fixes the behavior... Notoriously difficult in the case of 
> race conditions, especially if they are located in code that is outside of 
> our control.

Jeremias Maerki

Reply via email to