[OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods

Phil Race philip.race at oracle.com
Tue May 31 22:31:12 UTC 2016

I don't know of any design intent, so yes, I meant more as a practical 
Unless they subclass then using equals() which I thought unlikely it 
makes no difference here.
But it would be proof against that to use equals, unlikely to matter as 
it might be ..


On 05/31/2016 03:19 PM, Jim Graham wrote:
> On 05/31/2016 02:50 PM, Phil Race wrote:
>> On 05/31/2016 12:20 PM, Jim Graham wrote:
>>> Hi Jay,
>>> You were going to remove hashCode/equals from CCM, but instead you
>>> simply removed it from the patch.  You still need to edit it to remove
>>> the existing methods.
>> Oh yeah ! CCM is gone from the latest webrev. I expect that was not
>> intentional.
>>> Also, I'm not sure == is a good way to compare ColorSpace instances -
>>> Phil?
>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode and
>> all the predefined ones are constructed as singletons so it seems 
>> unlikely
>> to cause problems
> Should it use .equals() on principle, though?  Otherwise we are baking 
> in the assumption that it doesn't implement equals() into our 
> implementation of the CM.equals() method.  Might it some day implement 
> equals (perhaps it isn't a practical issue today, but it might be in 
> the future when we forget that it was omitted in this usage we create 
> today).
> I guess what I'm asking is if it is a design feature that different 
> objects are considered non-equal (such as an object that, for 
> instance, has only predetermined instances that are shared by 
> reference and reused).  I think color spaces are sort of in-between in 
> that we define a few constants that simply get used by reference in 
> 99% of cases, but that isn't a design feature, more like a practical 
> issue...
>             ...jim

More information about the 2d-dev mailing list