I've created Value interface:
public interface SomeVal {
void setLevel1Description(@MaxUtf8Length(100) CharSequence level1Description);
CharSequence getLevel1Description();
void setLevel2Description(@MaxUtf8Length(100) CharSequence level2Description);
CharSequence getLevel2Description();
void setLevel3Description(@MaxUtf8Length(100) CharSequence level3Description);
CharSequence getLevel3Description();
}
then I created chronicle map, key for an entry, value for an entry and I put this entry in created map:
ChronicleMap<LongValue, SomeVal> map = ChronicleMap
.of(LongValue.class, SomeVal.class)
.createPersistedTo(new File('cache'));
key = Values.newHeapInstance(LongValue.class);
key.setValue(1);
val = Values.newHeapInstance(SomeVal.class);
val.setLevel1Description("level 1 Desc");
val.setLevel2Description("level 2 Desc");
val.setLevel3Description("level 3 Desc");
map.put(key, val);
and then I triggered couple of times process which attaches to created map, gets value and prints it:
//process starts (...)
ChronicleMap<LongValue, SomeVal> map = ChronicleMap
.of(LongValue.class, SomeVal.class)
.createPersistedTo(new File('cache'));
SomeVal result = map.get(key);
System.out.println(result);
//(...) process ends
For some runs printed entry had correct state. But couple of times I got:
SomeVal{ level3Description=level 3 Desc, level1Description=level 2 Desc, level2Description=level 1 Desc }
values for level1Description and level2Description swapped places.
When I changed names:
level1Description -> l1Description
level2Description -> l2Description
level3Description -> l3Description
printed values of entry were always valid.
I couldn't find exact explanation for this in Chronicle docs. All the hints were related to sizing of values (e.g.: averageValueSize(), constantKeySizeBySample(), etc.), and not method naming in Value interfaces.
I checked this on a different versions of chronicle-map, even on a newest one available on maven repository and I always, eventually had this issue with swapped places.
Which version of Java are you using?
The way the object is laid out assumes that the order methods appear is stable, however the JVM isn't guaranteed to do this and different versions may behave differently (possibly from run to run)
The way around this is to run the code once with -DdumpCode=true
which will show you the generated code used on the console (even in a unit test for example). You can copy this code from the console into your code base and avoid any chance this will change in the future, however if you change the interface you will need to delete this code and repeat it.