Community
Participate
Working Groups
Build Identifier: In my application, I want to maintain three different button styles. For this purpose, I add the .css (attached to this bug) the custom ApplicationConfigurator. If I run the also-attached test application with the nightly of 14th of October, I see two green buttons, although one of them should be red. If I hover over the button that should be red, the button appears red. If I change the order of the css definitions, the green buttons become red while hovering over the button that should be green but is red becomes green. So I suppose that my css definition at least is somewhat correct. But I'm not sure about this. Reproducible: Always
Created attachment 205309 [details] The CSS file for the test
Created attachment 205310 [details] The test application
Created attachment 205311 [details] The configurator
The problem is in QxImage#hashCode, which returns same hashCode for different gradients.
I would say more precisely that the problem is that ImagePropertyAdapter.getKey uses the QxImage.hashCode instead of using a key guaranteed to be unique. The same could be said for all of the adapters in ThemePropertyAdapterRegistry.
Make the multipliers smaller in QxImage#hashCode to avoid out of integers range. Changes are in CVS HEAD.
I don't understand how this fix will _reliably_ solve the issue. Could you explain why the collisions occurred and why the smaller values prevent this? Apart from this, I agree with Cole that ImagePropertyAdapter.getKey methods could be implemented better than using Object#hashCode(). But we should also keep the strings short as they are send over the wire.
(In reply to comment #7) > I don't understand how this fix will _reliably_ solve the issue. Could you > explain why the collisions occurred and why the smaller values prevent this? > > Apart from this, I agree with Cole that ImagePropertyAdapter.getKey methods > could be implemented better than using Object#hashCode(). But we should also > keep the strings short as they are send over the wire. I agree with you that this fix is not 100% reliable - probably with 10 stop colors in the gradient the hash code will exceed the max integer value again. But I don't see such a real use case. I've added a JUnit test with 5 stop colors + start and end color and there is no collision. I agree with Cole too, that we have to find a proper implementation of ImagePropertyAdapter.getKey that guarantee the unique key.
Here is an example of calculation collision: -2104393728 * 31 + 1113587712 + -2104393728 = -1802502144 43089920 * 31 + 1113587712 + 43089920 = -1802502144
Just for the record - QxImage#hashCode now uses CRC32.
One more note for the record: bug 362390 suggests a proper fix.
