Avoid relying on item.hashCode() for Map and Collection properties

[vlsi]

Use case

JMeter seems to rely on hashCode uniqueness:

The hashcode violating code is

jmeter/src/core/src/main/java/org/apache/jmeter/testelement/property/AbstractProperty.java

Lines 368 to 381 in c727934

	if (item instanceof Collection<?>) {
	return new CollectionProperty(Integer.toString(item.hashCode()), (Collection<?>) item);
	}
	if (item instanceof Map<?, ?>) {
	return new MapProperty(Integer.toString(item.hashCode()), (Map<?, ?>) item);
	}
	return null;
	}
	protected JMeterProperty convertObject(Object item) {
	JMeterProperty prop = makeProperty(item);
	if (prop == null) {
	prop = getBlankProperty();
	prop.setName(Integer.toString(item.hashCode()));

In other words, it generates property names based on item.hashCode().
One more significant issue is that TestCompiler produces wrong results since TestElement equals is inconsistent with hashCode:

jmeter/src/core/src/main/java/org/apache/jmeter/testelement/AbstractTestElement.java

Lines 116 to 132 in 3128163

	public boolean equals(Object o) {
	if (o instanceof AbstractTestElement) {
	return ((AbstractTestElement) o).propMap.equals(propMap);
	} else {
	return false;
	}
	}
	// TODO temporary hack to avoid unnecessary bug reports for subclasses
	/**
	* {@inheritDoc}
	*/
	@Override
	public int hashCode(){
	return System.identityHashCode(this);
	}

It causes various Map<TestElement, ...>, Map<Sampler, ...> behave wrong. For instance, TestCompiler fails to property associate SamplePackage with the corresponding elements:

jmeter/src/core/src/main/java/org/apache/jmeter/threads/TestCompiler.java

Lines 72 to 75 in b3b2eec

	private final Map<Sampler, SamplePackage> samplerConfigMap = new HashMap<>();
	private final Map<TransactionController, SamplePackage> transactionControllerConfigMap =
	new HashMap<>();

Possible solution

No response

Possible workarounds

No response

JMeter Version

5.5

Java Version

No response

OS Version

No response