ConfigMapping hashcode does not change with the method value changes

[michalvavrik]

I have following @ConfigMapping https://github.com/quarkusio/quarkus/blob/main/extensions/devservices/keycloak/src/main/java/io/quarkus/devservices/keycloak/KeycloakDevServicesConfig.java, the mapping has property users. I have mentioned that when I used the KeycloakDevServicesConfig#hashCode in my build step, the hash code was same 1310h386370 even though when I called the KeycloakDevServicesConfig#users, users had a different value (you can try it by setting (quarkus.keycloak.devservices.users.michal=michal). https://smallrye.io/smallrye-config/Main/config/mappings/#validation says that the SR Config generates automatically hashCode. I think it is generally believed that when objects are equal, they should have the same hash code. However, it can't be these config mappings are equal, because the users are different.

Please note that I saw the second value on the dev mode restart, which was triggered by changing of the application.properties file (I added the property mentioned above, previously it was unset).

I guess the reason why this happens is due to the fact how default Map hashcode is implemented, so it can be probably reproduced by using Objects.hash() on maps (XOR trap).

[radcortez]

The hashCode config mapping implementation uses Objects.hashCode. Doing something like this:

SmallRyeConfig config = new SmallRyeConfigBuilder()
        .withConverter(MemorySize.class, 100, new MemorySizeConverter())
        .withConverter(Duration.class, 100, new DurationConverter())
        .withValidateUnknown(false)
        .withMapping(KeycloakDevServicesConfig.class)
        .build();
KeycloakDevServicesConfig configMapping = config.getConfigMapping(KeycloakDevServicesConfig.class);
System.out.println(configMapping.hashCode());

config = new SmallRyeConfigBuilder()
        .withConverter(MemorySize.class, 100, new MemorySizeConverter())
        .withConverter(Duration.class, 100, new DurationConverter())
        .withValidateUnknown(false)
        .withMapping(KeycloakDevServicesConfig.class)
        .withDefaultValue("quarkus.keycloak.devservices.users.user", "password")
        .build();
configMapping = config.getConfigMapping(KeycloakDevServicesConfig.class);
System.out.println(configMapping.hashCode());

Outputs:

1310386370
491110770

I wonder if you are getting the updated reference in your build step?

[michalvavrik]

hello @radcortez ,

Doing something like this:

however, your "user" is different to "password", you should test it with user pointing to user (map entry key and value should match to reproduce this):

.withDefaultValue("quarkus.keycloak.devservices.users.user", "user")

I wonder if you are getting the updated reference in your build step?

if I wasn't getting the updated reference, the users wouldn't differ. I did fixed it with custom hash implementation for the map, see https://github.com/quarkusio/quarkus/pull/51829/changes#diff-3e03bcd7ecafec03e4c0ea1fcd4159a2bc37554574b4b04a233255cb0b91085bR219 "safeMapHash".

[michalvavrik]

just FYI @radcortez if it wasn't clear from the context, I have a reproducer in quarkusio/quarkus#51829, but you would have to build that PR and then do some steps. It will be easier to wait till it gets merged. Unless you can reproduce it with the steps mentioned above.

[radcortez]

Yes, I can reproduce it just by setting the key and value to the same value. Interesting...

[radcortez]

I guess we could include the Map size in the mapping hashcode calculation.

[michalvavrik]

I guess we could include the Map size in the mapping hashcode calculation.

yep

[dmlloyd]

Config maps should be sorted by key; if that is the case, then they can use the typical rolling hash function by iterating each map entry in order, multiplying by a small prime, etc. That would be less susceptible to XOR traps and similar problems I would think.