Fix reloading channel config changes in .items file

[jimtng]

Apply channel config changes in .items file

Changes in channel config weren't applied because ItemChannelLink.equals() include the link configurations in the comparison. This caused the new link not being found in the set lookup, which leads to erroneously calling notifyListenersAboutAddedElement, when it should've called notifyListenersAboutUpdatedElement instead.

The problem that this PR fixes:

Changing channel config in an .items file, e.g. only the function is being changed from:

String Test { channel="foo" [ profile="transform:REGEX", function="moo" ] }

to:

String Test { channel="foo" [ profile="transform:REGEX", function="cow" ] }

This wouldn't take effect unless a more severe measure was taken, e.g. commenting out the item and re-adding it, or in many cases, users would restart openHAB to reload such changes.

Reported here:
https://community.openhab.org/t/problems-at-reducing-item-changes-with-regex/153400/6

Related:
#3235

This problem may have been started / caused by #1794

Note: I've set the initial capacity for the hashmap to 2, because most items only have 1 link, hopefully it saves a bit of memory by not pre-allocating for 16 slots by default.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/problems-at-reducing-item-changes-with-regex/153400/13

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/channel-transformations-not-working-when-using-text-files-for-item-creation/153407/10

[florian-h05]

LGTM, thanks. (I’m no core maintainer though.)

I think I experienced that issue when attempting to set up a JS transformation for a channel link and I wanted to either open an issue or look into that myself, but you have already solved the problem, great!

[J-N-K]

Otherwise LGTM. Nice finding.

[J-N-K]

Suggested change

	itemChannelLinkMap.put(itemName, links = new HashMap<>(2));
	itemChannelLinkMap.put(itemName, links = new HashMap<>(2));

Why 2?

[jimtng]

The default is 16 with .75 load factor. That seems like a waste of memory because most items have just one link.

If I set it to one, as soon as one element is added, it would trigger a rehash and capacity expansion anyway, because it would have exceeded the load factor. So 2 is chosen here.

Tbh this is just a guess based on reading about the description of initial capacity and load factor from hashmap's doc. I haven't done actual memory analysis tests to verify.

[jimtng]

I've added a comment in the code for future reference

[J-N-K]

Suggested change

	for (ItemChannelLink removedItemChannelLink : links.values()) {
	notifyListenersAboutRemovedElement(removedItemChannelLink);
	}
	links.values().forEach(this::notifyListenersAboutRemovedElement);

[J-N-K]

Thanks!