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.
XGC_ColorProfileUtil.diff
Description: Binary data
FOP_ColorProfileUtil.diff
Description: Binary data
Regards, Andreas ---
