Ah, ok. In your message you talked about "unequality" which is not the same as "identity". The first test (!=) test for identity. This can be removed. The second tests for equality (equals()).
On 11.10.2006 11:42:56 Peter wrote: > The test fails on > > assertTrue(col1 != col2); > > Before the change I made that was ok as the Color object was cloned just > before being returned > > The code in ColorUtil was > > // TODO: Check if this is really necessary > return new Color(parsedColor.getRed(), parsedColor.getGreen(), > parsedColor.getBlue(), parsedColor.getAlpha()); > > As a side remark, actually kind of weird to cache the Color objects in the > static colorMap member and then cloning them anyway. > > I removed that clone, because now e.g. an RgbIccColor or CMYK based color > can be returned. Therefore the Color objects can be the same (cached) > objects and the assert fires in the test. > > I can of course make sure that all returned objects, including RgbIccColor > and CMYK based Color objects are unique but I honestly think that in that > case it also makes sense to remove the static colorMap cache. > > > > -----Original Message----- > > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, October 11, 2006 11:33 AM > > To: [email protected] > > Subject: Re: Including an sRGB color profile? > > > > I think the test is fine. Can you tell why the two Color instances > > cannot be compared anymore? Do you have to override the equals() method > > of your Color subclasses? > > > > On 11.10.2006 11:22:13 Peter wrote: > > > I ran the unit tests and I am getting a failure in StandardTestSuite - > > > testEquals. > > > > > > The reason for the failure is a change in ColorUtil (see 4/ lower). > > > > > > Would changing the test to no longer check for unequality between two > > > returned Color objects be an option? > > > > <snip/> > > > > > > Jeremias Maerki Jeremias Maerki
